GH GambleHub

API authentication: OAuth2, JWT, HMAC

TL; DR

OAuth2/OIDC + JWT is a standard for client applications and server integrations with complex authorization (scopes/roles/tenants), SSO and short TTL tokens.
HMAC signatures are the best choice for webhooks and simple partner calls "server→server" with deterministic verification and strong protection against replay.
Strengthen security: mTLS or DPoP (sender-constrained tokens), short TTL (5-15 min), key rotation (JWKS), refresh tokens with rotation/anti-reuse, strict validation'aud/iss/exp/nbf/kid'and policy-as-code on the gateway.

1) Solution map: what to apply where

ScenarioWe recommend
External clients (Web/iOS/Android), SSOOAuth2/OIDC: Authorization Code + PKCE
Server↔server (machine integrations)OAuth2 Client Credentials (mTLS/DPoP if possible)
Fixed-route partner callsOAuth2 or HMAC (if scopes are simple)
Webhooks (PSP/anti-fraud/payments)HMAC signature + timestamp + idempotency
Inner East-West TrafficmTLS + short JWT (or opaque + introspection)
Very sensitive transactions (payments)OAuth2 + mTLS/DPoP, if possible step-up (SCA/3DS)

2) OAuth2/OIDC: flows and clients

2. 1 Flows

Authorization Code + PKCE (Web/Mobile) - Protects the authorization code from interception.
Client Credentials: server↔server without user; scopes - minimum required.
Device Code: for devices without a browser.
Refresh Token: for trusted clients only; rotate and enable reuse detection.

2. 2 Client types

Confidential (servers, BFF): keep secrets; use mTLS.
Public (SPA/mobile): the secret cannot be stored → PKCE, DPoP, short TTL and limited scopes.

3) JWT: structure, timing, verification

3. 1 Fields (claims)

Mandatory: 'iss', 'sub', 'aud', 'exp', 'iat', 'nbf', 'jti', 'scope '/' permissions', 'tenant' (if multi-lease), 'kid'.

3. 2 Lifetimes

Access token: 5-15 minutes.
Refresh token: days/weeks, rotate with each exchange; when re-submitting the old one, we block the session.

Clock skew: tolerance ≤ 60 s

3. 3 JWKS and keys

Storing keys in KMS/Vault, 'kid' is required.
Two active keys (rolling), reissued once every 60-90 days or in an incident.
JWKS cache on gateway ≤ 5 minutes, with auto-disability.

3. 4 Verification on gateway/services

Check: signature, 'aud' (approved services), 'iss', 'exp/nbf', list of locks (revocation).
Do not trust fields from the body without verifying the signature; ignore'alg = none '.

Example of a request header:

Authorization: Bearer <JWT>
X-Trace-Id: <uuid>

4) Binding token to client: mTLS, DPoP

mTLS (TLS client certificates): the token is issued and validated only if there is a client certificate → the token is useless outside the key + certificate combination.
DPoP (Demonstration of Proof-of-Possession): the client signs each request with a one-time key → protection against replay and token theft in public clients.
For critical routes (payment mutations) - require one of the mechanisms.

5) Authorization: scopes, roles, ABAC

Scopes - minimum actions ('payments: write', 'payments: status: read').
Roles - units for admins; do not use them directly without scopes.
ABAC - attributes in the token ('tenant', 'country', 'kyc _ level', 'risk _ flags') → policies on gateway/OPA.
Policy at the route/field level (GraphQL) and at the domain operation level (REST/gRPC).

6) HMAC signatures: webhooks and partners

6. 1 Concept

Each integration has its own secret.

Caption above canonical line: 'timestamp + "\n "+ method + "\n" + path + "\n "+ sha256 (body)'

Titles:

X-Signature: v1=base64(hmac_sha256(secret, canonical_string))
X-Timestamp: 2025-11-03T12:34:56Z
X-Event-Id: 01HF...

Time window: ≤ 300 seconds; Reject requests with expired/future'X-Timestamp '.
Idempotence: Store 'X-Event-Id' on TTL (24h) - discard duplicates.

6. 2 Best practices

Secrets in KMS/Vault, rotating every 90 days.
For public clients, HMAC is not suitable (the secret leaks); use OAuth2/DPoP.

7) Protection against replay, brute force and leaks

Nonce/' jti 'for sensitive operations; blacklist of used identifiers.
Rate/quotas: by key/client/tenant/route; "expensive" operations are separate quotas.
IP/ASN/Geo allow-lists for partners and webhooks.
Content-type allow ('application/json'), body size limit.
PII masking in logs; prohibition to log tokens/secrets.

8) Errors and answers (single format)

Error structure:
json
{
"error": "invalid_token",
"error_description": "expired",
"trace_id": "4e3f-..."
}
Statuses:
  • '401 '- no/invalid token (WWW-Authenticate).
  • '403 '- insufficient rights (scope/ABAC).
  • '429 '- limits/quotas.
  • gRPC: `UNAUTHENTICATED`/`PERMISSION_DENIED`/`RESOURCE_EXHAUSTED`.

9) Term and session policies

Access ≤ 15 min; Refresh - rotation + reuse detection (submitted old - session recall).
Webhooks HMAC: TTL signatures ≤ 5 min; repeated delivery with exponential backoff.
Session/key revocation → immediate entry into the revocation list (cache on the gateway ≤ 1 min).

10) Observability and audit

Correlation by 'trace _ id '/' span _ id'.
Metrics: auth success rate, '401/403/429', OIDC/JWKS latency, rotation frequency, reuse refresh, share of DPoP/mTLS traffic.
Audit log: "who, when, with which 'sub/tenant/scope' caused what," key/secret changes, failed HMAC signatures.

11) Embedding in the Gateway API

JWT validation (JWKS cache) and OPA/ABAC on the gateway.
mTLS profiles for trusted clients/partners.
HMAC verification of webhooks on edge (before internal services).
Rate/Quota policies, circuit-breaker on OIDC provider (cache JWK).
Feature-flags: quick disconnection of the client/key, change of the signature algorithm.

12) Mini snippets

Pseudo: JWT verification

pseudo jwks = cache. getOrFetch(iss + "/.well-known/jwks. json")
key = jwks[kid]
assert verify_signature(jwt, key)
assert aud in ALLOWED_AUDIENCES and iss in TRUSTED_ISSUERS assert now in [nbf-60s, exp+60s]

Pseudo: checking HMAC webhook

pseudo canonical = timestamp + "\n" + method + "\n" + path + "\n" + sha256(body)
sig = base64(hmac_sha256(secret, canonical))
assert abs(now - timestamp) <= 300 assert not seen(event_id)
assert timingSafeEqual(sig, header["X-Signature"].split("v1=")[1])
markSeen(event_id, ttl=86400)

Example scope-policy (OPA/Rego idea)

rego allow {
input. jwt. scope[_] == "payments:write"
input. jwt. tenant == input. route. tenant
}

13) Incident playbooks

Private key leak/JWT-signer: key reissue, JWKS update, immediate disabling of the old ('kid' → deny), disability refresh, forced logout.
Substitution of webhooks: rotation of secrets, IP allow-list, amplification of the 'X-Timestamp' window, repeated delivery of missed events.
Replay/brute-force: enable DPoP/mTLS on critical routes, narrow quotas, temporary blocks by IP/ASN, enable 'jti '-block list.
Outage OIDC: degradation of cached tokens (grace), circuit-breaker provider, customer notification.

14) Implementation checklists

Authentication (minimum):
  • OAuth2: Code+PKCE (Web/Mobile), Client Credentials (server-to-server)
  • TTL: Access ≤ 15 min, Refresh with rotation and reuse detection
  • JWKS: two active keys, 'kid', cache ≤ 5 min
  • Webhooks: HMAC v1, 'X-Timestamp', 'X-Event-Id', window ≤ 300 sec, idempotency
  • Sender-constrained: mTLS/DPoP on critical routes
  • ABAC/OPA: scopes + tenant/risk in gateway policies
  • Rate/Quota и 429; IP/ASN allow-lists for partners
  • Audit and alerts (401/403/429, reuse refresh, HMAC signatures)
Privacy/logging:
  • Do not log tokens/secrets/full card bodies
  • PII masking; DSAR support; the shelf life of logs is limited

15) Anti-patterns

'alg = none'or trust a token without signature verification/JWKS.
Long-lived access tokens (hours/day).
One common HMAC secret for all partners.
Webhooks without timestamp/idempotency.
Refresh tokens without rotation and without reuse detection.
Lack of 'aud '/' iss' validation and 'kid' rotation.
Storing secrets in environment variables without KMS/Vault.

16) NFT/SLO (landmarks)

OIDC/JWKS availability ≥ 99. 95% (edge cache reduces dependency).
JWT validation additive on gateway ≤ 2-5 ms p95.
Authentication errors ('401') ≤ 0. 5% of total traffic (excluding bots).
Signed webhooks: share of successfully verified ≥ 99. 9%, average delivery delay ≤ 3 s.

Summary

Combine mechanisms: OAuth2/OIDC + JWT for users and rich server scripts, HMAC for webhooks/simple partners, and for critical operations - mTLS/DPoP. Keep short TTLs, key rotations (JWKS), strict ABAC/OPA policies, protect loops from replay and leaks, and automate everything at the API Gateway level. So authentication will become predictable, scalable and secure - without compromises for UX and monetization.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Telegram
@Gamble_GC
Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.