Authentication and authorization

The reliable AuthN/AuthZ loop is a single point of truth about who you are (authentication) and what you are allowed to do (authorization). In a platform with many brands, regions, integrations and high regulatory requirements, this contour should be modular, observed and managed by politicians, and not a "scattering of if-s by services."

1) Basic terms and roles

Identification (ID): identification (user, service, provider).
Authentication (AuthN): proof of identity (password, MFA, certificate).
Authorization (AuthZ) -Policy and context-based can/can't decide.
PDP/PEP: Policy Decision Point/Policy Enforcement Point.
IdP: Identity Provider (OIDC).
Subject/Resource/Action/Context: who/what/what does/under what conditions.

2) Overall loop architecture

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

Principles: centralization of token and policy generation, local application; "minimal privileges" and explicit delegations.

3) User authentication (OIDC/OAuth 2. 1)

• Authorization Code + PKCE (always for SPA/Mobile).
• SSO: external IdP support (SAML/OIDC) for b2b/operators.
• MFA: TOTP/WebAuthn/SMS (WebAuthn and TOTP recommended; SMS — fallback).
• Risk-based Step-Up: for sensitive actions (withdrawal of funds, change of details) require MFA/pe-Auth.

• Refresh Token Rotation + RT registry with reuse detectorized.
• Nonce/State + PKCE, strict CORS/CSRF for browser streams.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DPoP/mtls-bound tokens) for critical operations.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) Service-service authentication (mTLS, SPIFFE, JWT)

mTLS between services + SPIFFE/SPIRE for stable workload identifiers.
Service JWT with a short period (≤5 minutes), signed by HSM/KMS; audit of issuance.
Audience-scoped: JWT is only suitable for a specific service/domain.
Trust zones: services from another region/tenant - separate PKIs and policies.

5) Authorization models: RBAC, ABAC, ReBAC

RBAC (roles → permissions): simple and transparent (suitable for admin panels, operators).
ABAC (subject/resource/context attributes): flexible for "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (relationships): Useful for complex holdings ("who owns a brand/folder/campaign").

Recommendation: hybrid - basic RBAC + context ABAC conditions + point ReBAC relationships.

6) Policies and Enforcement (PDP/PEP)

PEP on the Gateway and in services: retrieves the context (JWT, tickets, IP/ASN, time, region, KYC layer), forms a request to the PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

and returns'ALLOW/DENY '+ explanation.

PEP's solution cache (TTL 30-120 c) reduces latency; disability by "role/policy change" events.

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) Scopes and resolutions

• Resource: action - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.
• For admins - 'admin:' in a standalone domain.
• For providers - 'provider: report. read`, `provider:events. push`.

The principle of minimum privileges: we assign only the necessary scopes; "escalation" (temporary extensions of rights) - by ticket and with TTL.

8) Multi-tenant and regions (residency)

Tokens contain 'tenant', 'region', 'licence'; The PDP checks the correspondence with the resource.
Roles/policies - namespaces per tenant ('role: brand _ eu/support').
Separation of signature keys and revocation lists by region; cross-regional requests - only through trusted gateways.

9) Session and device management

Server-side session store for web (device/browser binding, identifier rotation).
Idle/Absolute Timeout (e.g. 30 min/24 h); sensitive actions - re-Auth/MFA.

Listing of active devices, "exit from all."

Anomalies: simultaneous inputs from different regions, frequent MFA dips - risk signals.

10) Delegation and consent (consent)

On-behalf-of (OBO): the service acts on behalf of the user (a proxy token with a separate 'sub '/' act').
Consent: explicit screen for partner access to data, log of consent with recall.
Temporary access-mandates: rights for N hours/days automatically expire.

11) Keys, signatures and rotation

JWKS with 'kid', automatic rotation, storage of private keys in KMS/HSM.
Algorithms: ES256/EdDSA for JWT; TLS 1. 2+/mTLS.
Dual-key period: Accept both'kids' before client upgrade is complete.
RT and Token Introspection recalls for critical incidents.

12) Client application security

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, secure RT storage, root/jailbreak protection.
Desktop: system browser for login (no embedded web-views), PKCE.

13) Convenient SDK contracts

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

14) Observability and audit

• `authn_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
• `authz_p95_ms`, `authz_denied_rate{reason}`
• `invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
• Anomalies of inputs (new device, geo-velocity), suspicious scopes.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Export for compliance (regulator/vendor-audit).

15) Perimeter and client protection

Gateway PEP: rate-limit, bot/signature checks, CSRF protection, strict CORS, HSTS.
Internal traffic: mTLS + service JWT + limited networks.
Webhooks/external collbacks: body signatures (HMAC/JWS), time windows, anti-replay.

16) Typical errors

Long-lived access tokens → leaks.
Implicit OAuth flow in SPA.
No key rotation and Dual-Key period.
Hardcore roles instead of policies (it is impossible to audit/explain decisions).
Mixing tenants/regions in one'role 'or'key'.
No step-up MFA on sensitive actions.
AuthZ solutions cache without role change disability.

17) Playbooks (runbooks)

1. JWT signature key compromise

Immediate revoke 'kid', publication of new JWKS, forced RT/sessions disability, audit report.

2. Bulk'invalid _ token'

Check for clock misalignment/lifetime, JWKS relevance, cache crashes.

3. Input anomalies

Enable increased risk scoring, require step-up, notify the user, temporarily limit payments.

4. IdP failed

Switch to the session cache/role-device, limit new logins, hold active sessions to TTL.

18) Pre-sale checklist

• OIDC/OAuth 2. 1 with PKCE, short AT, RT rotation, device binding for critical operations.
• MFA (WebAuthn/TOTP) and step-up for output/change of details/role-escalations.
• Service-to-service: mTLS + SPIFFE, short-lived service JWTs.
• AuthZ policies (RBAC + ABAC/ReBAC) in centralized PDP; PEP on gateway and in services.
• Disability Solutions Cache; audit trail unchangeable.
• Multi-tenant/regions: key/policy/log isolation, license accounting.
• JWKS/keys in KMS/HSM, dual-key rotation, monitoring'kid'.
• CSRF/CORS/HSTS/Rate-limit/bot filters on the perimeter.
• Incident playbooks, revoke/rotate/lockdown run buttons.
• Test suite: unit (policies), contract (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Mini configuration templates

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

Conclusion

The authentication and authorization loop is not a library, but a platform ability: short-lived tokens and managed keys, centralized policies and their local application, multifactor and step-up, strict isolation of tenants/regions, audit and telemetry. This design makes changes safe, explainable to the regulator and transparent to the product - and scaling by market and command becomes a routine operation, not a feat.