OAuth2/OpenID Connect nel nucleo

OIDC sopra OAuth2 è un modo standard per dimostrare chi è l'utente/cliente e dare accesso breve all'API. Nel core della piattaforma diventa una capacità centrale: accesso unico per clienti, operatori e servizi; privilegi minimi; Rischio misurabile; rispetto delle regole regionali e delle licenze.

1) Obiettivi e principi

Separazione «deploy vs enable»: estraiamo il codice separatamente, includiamo l'accesso con bandiere/regole.
Token a breve vita + aggiornamento sicuro per ridurre i danni durante le perdite.
Multi tenant/regione - Tutti i manufatti sono lanciati «tenant/region/licence».
Regole sopra i token: PDP (RBAC/ABAC), PEP su gateway/servizi.
Protezione canali: TLS1. 2 +, se possibile, CORS/CSRF rigoroso.
Osservazione e verifica: visibilità per flusso, per client, per regione.

2) Flussi e quando applicarli

Authorization Code + PKCE (SPA/Mobile/Web) - Default per login personalizzati.
Device Authorization (console/TV/CLI) - Quando non c'è un browser.
Client Credentials (machine-to-machine) - Integrazioni di servizi senza utente.
Token Exchange (RFC 8693, OBO) - Il servizio funziona per conto dell'utente.
CIBA/Back-Channel (opzionale) - Autenticazione con task senza reading.

• PER (Pushed Authorization Recests) - I parametri di autorizzazione vengono trasferiti in un canale server protetto.
• JAR (JWT Secured Authorization) - Le impostazioni della query sono state firmate/criptate.
• JARM - La risposta di autorizzazione protetta (JWT) è resistente ai sottomenu.
• RAR (Rich Authorization Recests) - Una ricca richiesta di diritti di accesso (autorizzazioni dettagliate).

3) Token e marchi

• ID Token (OIDC) - Chi è entrato (mostra solo client/fronte).
• Access Token (AT) - Diritto all'azione (vita breve).
• Refresh Token (RT) - Aggiorna AT; memorizzato solo in un ambiente affidabile.

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

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
}

Firma: ES256/EdDSA, chiavi pubbliche: JWKS con «kid» e rotazione.

4) Tracciato delle sessioni e logout

Server-side session для web (cookie `SameSite=Lax/Strict`, `HttpOnly`, `Secure`).
Back-Channel Logout + Front-Channel Logout (OIDC) - Completamento sincrono di tutti i client.
Step-Up MFA - In caso di attività sensibili, la convalida («acr» aumenta).
Revocation & Introspection: disattivazione immediata di RT/AT per incidente.

5) Protezione dei clienti

Web/ s: Authorization Code + PKCE, nessun influenzit; CORS/Content-Security-Policy rigoroso.
Mobile: browser di sistema ( ), verifica integrità (App), archivio RT protetto.
Desktop/CLI/TV: Device Flow; memorizzare RT in sistemi di storage OS.
DPoP o mTLS-bound tokens per mappare AT al dispositivo/connessione.

6) Servizio-a-servizio

mTLS + Servizio JWT (aud-scoped), rilascia STS con KMS/HSM.
Identità workload a: SPIFFE/SPIRE.
Criteri "da stretto a largo": visibilità e scopes specifiche al posto di ".

7) Registro e consenso Scope (consent)

Nome: "risorsa" - "wallet: read", "wallet: transfer", "bets: place", "kyc: status. read`.

Configurare la visibilità e la sensibilità degli insiemi.
Consent screen viene raccolto da RAR/Scopes; Conserva la storia dei consensi e permetta la recensione.

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

8) Integrazione autorizzata (PDP/PEP)

PEP dell'API Gateway valuta il AT/DPoP/mTLS, arricchisce il contesto (IP/ASN/region/tenant), esegue la richiesta di PDP.
PDP (OPA/cedar) applica RBAC/ABAC/ReBAC e restituisce ALLOW/DENY con spiegazioni e TTL.
Cache PEP (TTL 30-120 s) con disabilità per eventi (cambio di ruoli/regole).

9) Multi-tenente e regioni

Tutti i token e le sessioni sono etichettati «tenant/region/licence»; PDP valuta la corrispondenza della risorsa.
JWKS separati/chiavi e elenchi di richiamo per regione; Regione di cross - attraverso gateway affidabili.
Restrizioni di residenza dati: introspezione/ricezione vengono eseguite nella regione di origine.

10) Rinforzi protocolli

POR + JAR + JARM - Protegge le impostazioni e le risposte di autorizzazione.
Nonce/State/PKCE è per tutti i clienti pubblici.
Purhed Device Authorization (ad alto rischio).
JWT Access Tokens con marchi minimi + opache per le integrazioni esterne tramite introspezione.
Pratiche FAPI simili: algoritmi di firma rigorosi, requisiti TLS/redict _ uri/PKCE.

11) Errori e criteri di restituzione

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 per endpoint sensibili ('/token ', '/introspect', '/revoke '), backoff esponenziale.

12) Osservazione e verifica

• `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`.
Controllo (invariato) - Rilascio di token, aumento dei diritti, revoca dei consensi, rotazione delle chiavi.

13) Gestione delle chiavi e rotazione

Firma JWT: KMS/HSM, pubblicazione JWKS con'kid '.
Periodo dual-key: il IdP firma i nuovi tester che accettano il vecchio + nuovo prima del cambio.
Rotazione regolare e revoke di emergenza; Monitoraggio del consumò kid ".

14) Playbooks (runbooks)

1. Compromettere la chiave di firma

Subito revoke 'kid', rilasciare nuovo, forza-invalidità RT/sessioni, report di verifica.

2. Massiccia'invalid _ token '/altezza 401

Controllare le ore di Rashincron scadute AT, crash JWKS rotto; ingrandire temporaneamente il toleran'clock _ skew '.

3. Riutilizzo RT

Blocca sessione ('sid'), avvisa l'utente, richiede step-up per un nuovo accesso, indagine.

4. Caduta del IdP

Attiva la modalità «read-only autorizzazioni» - Mantiene l'AT attivo fino a TTL, limita i nuovi login, scaglia la cache di introspezione.

5. Attacco à/token "

Rinforza i filtri rate-limit/bot, abilita i filtri per i clienti sensibili, porta RT «freddo» in un segmento separato.

15) Test

Contract: OIDC discovery, JWKS, OpenID provider config.
Sicurezza: PKCE/nonce/state sono obbligatori; set negative (rimpiazzi redict _ uri, reuse RT).
Interoperability: client (web/mobile/CLI), fuso orario diverso/locale.
Chaos: errore PER/JARM, ritardi JWKS, rotated 'kid'.
E2E: step-up MFA, OBO (token exchange), logout (front/back-channel), revoke/rotate.

16) Esempi di configurazione

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) Foglio di assegno prima della vendita

• PKCE/nonce/state abilitate; POR/JAR/JARM sono attivi.
• AT/RT/ID TTL impostati; RT rotation + reuse detection sono inclusi.
• DPoP o mTLS-binding per i clienti/operazioni sensibili.
• JWKS c `kid`; rotazione automatica e monitoraggio del consumo di chiavi.
• Consent/RAR e Registro scorie; step-up MFA per azioni sensibili.
• PDP/PEP integrati, cache di soluzioni disabili.
• I token contengono «tenant/region/licence»; La residency è rispettata.
• Osservabilità: metriche, fogli, tracciabilità; alert in'invalid _ token ',' rt _ reuse ',' jwks _ skew '.
• playbook su revoke/rotate/lockdown; Pulsante logout di emergenza.
• Il set di test E2E/chaos/interop è stato completato negli stand.

Conclusione

Integrando OAuth2/OIDC come platea, si ottengono flussi di autorizzazione prevedibili, token gestiti, regole di accesso unificate e rischi misurabili. AT brevi protetti da RT, rotazione delle chiavi, PAR/JARM/DPoP, consenso e step-up sono pratiche che rendono la sicurezza predefinita e l'evoluzione veloce e indolore per team e partner.