Connect OAuth2/OpenID in the kernel

OIDC over OAuth2 is a standard way to prove who the user/client is and give short-lived API access. At the core of the platform, it becomes a central capability: single sign-on for customers, operators and services; minimum privileges; measurable risk; compliance with regional and licensing regulations.

1) Goals and principles

Separation "deploy vs enable": roll out the code separately, enable access with flags/policies.
Short-lived tokens + secure update: reduce damage from leaks.
Multi-tenant/region: all artifacts are labeled 'tenant/region/license'.
Policies on top of tokens: solutions are made by PDP (RBAC/ABAC), PEP on gateway/services.
Link protection: TLS1. 2 +, mTLS/DPoP if possible, strict CORS/CSRF.
Observability and audit: visibility by stream, by customer, by region.

2) Flows and when to apply them

Authorization Code + PKCE (SPA/Mobile/Web) - default for user logins.
Device Authorization (consoles/TV/CLI) - when there is no browser.
Client Credentials (machine-to-machine) - service integrations without a user.
Token Exchange (RFC 8693, OBO) - the service acts on behalf of the user.
CIBA/Back-channel (optional) - push authentication without redirect.

• PAR (Pushed Authorization Requests) - authorization parameters are transmitted over a secure server channel.
• JWT Secured Authorization - Request parameters are signed/encrypted.
• JARM - protected authorization response (JWT), resistant to spoofing.
• RAR (Rich Authorization Requests) - rich access rights requests (detailed permissions).

3) Tokens and stamps

• ID Token (OIDC) - who entered (show only to the client/front).
• Access Token (AT) - right to action (short life).
• Refresh Token (RT) - updates AT; is only stored in a trusted environment.

• AT: 5-15 min (web/mobile), 2-5 min (service-to-service).
• RT: 7–30 дней (web/mobile) с rotation + reuse detection.
• ID: ≤ 5 min.

json
{
"iss":"https://auth. core",
"sub":"user_42",
"aud":["wallet","catalog"],
"exp":1730388600,"iat":1730388000,
"tenant":"brand_eu","region":"EE","licence":"EE-A1",
"scp":["wallet:read","bets:place"],     // scopes
"sid ": "sess _ abcd, ""amr": [" pwd,"" webauthn"] ,//login methods
"act":{"sub":"svc. catalog" }//if OBO
}

Signing: ES256/EdDSA, public keys - in JWKS with 'kid' and rotation.

4) Session outline and logout

Server-side session для web (cookie `SameSite=Lax/Strict`, `HttpOnly`, `Secure`).
Back-Channel Logout + Front-Channel Logout (OIDC) - synchronous termination of all clients.
Step-Up MFA: with sensitive actions - repeated check ('acr' increases).
Revocation & Introspection: immediately disabling RT/AT by incident.

5) Customer security

Web/SPAs: Authorization Code + PKCE, no implicit; strict CORS/Content-Security-Policy.
Mobile: system browser (AppAuth), integrity check (App Attestation/DeviceCheck), secure RT storage.
Desktop/CLI/TV: Device Flow; store RT in OS secret stores.
DPoP or mTLS-bound tokens to bind the AT to the device/connection.

6) Service-to-service

mTLS + short Service JWT (aud-scoped), issues STS with KMS/HSM.
Identities of workloads: SPIFFE/SPIRE.

Narrow-to-broad policy: specific audience and scopes instead. "

7) Scope-registry and consent

Naming: 'resource: action' - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.

Configure the visibility and sensitivity of the scopes.
Consent screen is assembled from RAR/Scopes; keep a consent history and allow feedback.

json
{
"type":"wallet. transfer",
"actions":["create"],
"locations":["https://api. core/wallet"],
"datatypes":["payment"],
"resources":[{"wallet_id":"w_123","currency":"EUR","amount_max":1000}]
}

8) Authorization Integration (PDP/PEP)

PEP on the Gateway API validates AT/DPoP/mTLS, enriches context (IP/ASN/region/tenant), makes a request to the PDP.
PDP (OPA/cedar) applies RBAC/ABAC/ReBAC policies and returns' ALLOW/DENY'with explanation and TTL.
The solution cache at PEP (TTL 30-120 s) with disability by event (role/rule change).

9) Multi-tenant and regions

All tokens and sessions are labeled 'tenant/region/license'; PDP validates resource compliance.
Separate JWKS/keys and recall lists by region; cross-region - through trusted gateways.
Data residency limitations: Introspection/revocation is performed in the region of origin.

10) Protocol amplifications

PAR + JAR + JARM - Protect authorization parameters and responses.
Nonce/State/PKCE - for all public customers.
Pushed Device Authorization (at high risk).
JWT Access Tokens with minimal stamps + opaque option for external integrations via introspection.
FAPI-like practices: strict signature algorithms, TLS/redirect_uri/PKCE requirements.

11) Errors and return policy

json
{ "error":"invalid_grant", "error_description":"refresh token reused", "error_code":"RT_REUSE" }

Критичные коды: `invalid_request`, `invalid_client`, `invalid_grant`, `invalid_scope`, `unauthorized_client`, `access_denied`, `temporarily_unavailable`.
Rate-limit for sensitive endpoints ('/token ', '/introspect', '/revoke '), exponential backoff.

12) Observability and audit

• `auth_code_success_rate`, `pkce_missing_rate`, `mfa_challenge/fail_rate`,
• `token_issuance_p95_ms`, `jwks_skew_ms`, `invalid_token_rate`, `rt_reuse_detected`,
• по API: `authz_p95_ms`, `deny_rate{reason}`, `dpop_mismatch_rate`, `mtls_fail_rate`.

Логи/трейсы: `client_id`, `grant_type`, `kid`, `acr/amr`, `tenant/region`, `decision`, `policy_version`, `aud`, `scp`, `sid`, `trace_id`.
Audit (unchangeable): issuance of tokens, escalation of rights, withdrawal of consents, key rotation.

13) Key management and rotation

JWT signature: KMS/HSM, JWKS publication with 'kid'.
Dual-key period: IdP signs new, reviewers accept old + new before switching.
Regular rotation and emergency revoke; monitoring of 'kid' consumption.

14) Playbooks (runbooks)

1. Signature key compromise

Immediately revoke 'kid', issue a new, force-disabled RT/sessions, audit report.

2. Mass' invalid _ token '/growth 401

Check clock misalignment, expired AT, broken JWKS cache; temporarily increase the 'clock _ skew' tolerant.

3. RT reuse

Block the session ('sid'), notify the user, demand a step-up for a new login, investigate.

4. IdP drop

Enable "read-only authorization" mode: keep active ATs up to TTL, restrict new logins, scale the introspection cache.

5. Attack on '/token'

Strengthen rate-limit/bot filters, enable mTLS/DPoP for sensitive clients, move cold RTs to a separate segment.

15) Testing

Contract: OIDC discovery, JWKS, OpenID provider config.
Security: PKCE/nonce/state are required; negative-sets (substitutions' redirect _ uri ', reuse RT).
Interoperability: clients (web/mobile/CLI), different time zones/locales.
Chaos: PAR/JARM failure, JWKS delay, rotated 'kid' on the fly.
E2E: step-up MFA, OBO (token exchange), logout (front/back-channel), revoke/rotate.

16) Configuration examples

yaml issuer: https://auth. core jwks:
rotation_days: 30 alg: ES256 tokens:
access_ttl: 10m refresh_ttl: 14d id_ttl: 5m policies:
require_pkce: true require_par: true require_jarm: true dpop_enabled: true mfa_step_up:
actions: ["wallet:transfer","payout:initiate"]
tenancy:
include_claims: ["tenant","region","licence"]
jwks_per_region: true

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

17) Pre-sale checklist

• PKCE/nonce/state enabled; PAR/JAR/JARM are active.
• AT/RT/TTL ID set; RT rotation + reuse detection enabled.
• DPoP or mTLS-binding for sensitive clients/operations.
• JWKS c `kid`; automatic rotation and key consumption monitoring.
• Consent/RAR and scope registry; step-up MFA for sensitive activities.
• PDP/PEP integrated, disability solutions cache.
• Tokens contain 'tenant/region/license'; residency is observed.
• Observability: metrics, logs, tracing; alerts to 'invalid _ token', 'rt _ reuse', 'jwks _ skew'.
• Playbooks on revoke/rotate/lockdown; emergency logout button.
• A set of E2E/chaos/interop tests was passed on the stands.

Conclusion

By embedding OAuth2/OIDC as a platform capability, you get predictable authorization flows, managed tokens, uniform access policies, and measurable risk. Short ATs protected by RT, key rotation, PAR/JARM/DPoP, consent, and step-up are practices that make security the default, and evolution fast and painless for teams and partners.