Conectați OAuth2/OpenID în kernel

OIDC over OAuth2 este o modalitate standard de a dovedi cine este utilizatorul/clientul și de a oferi acces API de scurtă durată. În centrul platformei, devine o capacitate centrală: un singur sign-on pentru clienți, operatori și servicii; privilegii minime; risc măsurabil; respectarea reglementărilor regionale și de licențiere.

1) Obiective și principii

Separarea „implementare vs activare”: introduceți codul separat, permiteți accesul cu steaguri/politici.
Jetoane cu durată scurtă de viață + actualizare sigură: reduceți daunele cauzate de scurgeri.
Multi-chiriaș/regiune: toate artefactele sunt etichetate „chiriaș/regiune/licență”.
Politici pe partea de sus a jetoane: soluții sunt făcute de PDP (RBAC/ABAC), PEP pe gateway/servicii.
Protecția link-ului: TLS1. 2 +, mTLS/DPoP dacă este posibil, CORS strict/CSRF.
Observabilitate și audit: vizibilitate pe flux, pe client, pe regiune.

2) Fluxurile și când să le aplicați

Codul de autorizare + PKCE (SPA/Mobile/Web) - implicit pentru autentificarea utilizatorilor.
Autorizație dispozitiv (console/TV/CLI) - atunci când nu există nici un browser.
Acreditări client (machine-to-machine) - integrări de servicii fără utilizator.
Token Exchange (RFC 8693, OBO) - serviciul acționează în numele utilizatorului.
CIBA/Back-channel (opțional) - autentificare push fără redirecționare.

• PAR (cereri de autorizare împinse) - parametrii de autorizare sunt transmiși pe un canal securizat de server.
• JWT Securizat Autorization - Parametrii cererii sunt semnați/criptați.
• JARM - răspuns de autorizare protejat (JWT), rezistent la spoofing.
• RAR (cereri bogate de autorizare) - cereri bogate de drepturi de acces (permisiuni detaliate).

3) Jetoane și timbre

• ID Token (OIDC) - cine a intrat (arată numai clientului/față).
• Access Token (AT) - dreptul la acțiune (viață scurtă).
• Refresh Token (RT) - actualizări AT; este stocat numai într-un mediu de încredere.

• AT: 5-15 min (web/mobil), 2-5 min (service-to-service).
• RT: 7-30 дней (web/mobil) с rotație + reutilizare detectare.
• 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
}

Semnarea: ES256/EdDSA, chei publice - în JWKS cu „copil” și rotație.

4) Schița sesiunii și deconectarea

Sesiune pe server для web (cookie 'SameSite = Lax/Strict',' HttpOnly ',' Secure ').
Back-Channel Logout + Front-Channel Logout (OIDC) - terminarea sincronă a tuturor clienților.
Etapa-Up MFA: cu acțiuni sensibile - verificare repetată („acr” crește).
Revocare și introspecție: dezactivarea imediată a RT/AT prin incident.

5) Securitatea clientului

Web/SPA: Cod de autorizare + PKCE, fără implicit; strict CORS/Content-Security-Policy.
Mobil: browser de sistem (AppAuth), verificare integritate (App Attestation/DeviceCheck), stocare RT securizată.
Desktop/CLI/TV: Fluxul dispozitivului; stocați RT în magazinele secrete OS.
DPoP sau mTLS-legat jetoane pentru a lega AT la dispozitiv/conexiune.

6) Service-to-service

mTLS + serviciu scurt JWT (aud-scoped), probleme STS cu KMS/HSM.
Identitatea volumelor de lucru: SPIFFE/SPIRE.

Politica restrânsă la scară largă: publicul specific și domeniile de aplicare în schimb "

7) Domeniul de aplicare-registru și consimțământul

Denumire: "resursă: acțiune" - "portofel: citit", "portofel: transfer", "pariuri: loc", "kyc: stare. citește ".

Configurați vizibilitatea și sensibilitatea scopurilor.
Ecranul de consimțământ este asamblat din RAR/Scopes; păstrați un istoric de consimțământ și permiteți 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) Integrarea autorizațiilor (PDP/PEP)

PEP pe API Gateway validează AT/DPoP/mTLS, îmbogățește contextul (IP/ASN/regiune/chiriaș), face o cerere către PDP.
PDP (OPA/cedru) aplică politici RBAC/ABAC/ReBAC și returnează „PERMITE/DENY” cu explicații și TTL.
Soluția cache la PEP (TTL 30-120 s) cu handicap după eveniment (schimbare de rol/regulă).

9) Multi-chiriaș și regiuni

Toate jetoanele și sesiunile sunt etichetate „chiriaș/regiune/licență”; PDP validează conformitatea resurselor.
Separați JWKS/chei și liste de rechemare pe regiuni; cross-region - prin gateway-uri de încredere.
Limitări de rezidență de date: Introspecția/revocarea se efectuează în regiunea de origine.

10) Amplificări de protocol

PAR + JAR + JARM - Protejați parametrii de autorizare și răspunsurile.
Nonce/State/PKCE - pentru toți clienții publici.
Autorizarea dispozitivului împins (cu risc ridicat).
Jetoane de acces JWT cu timbre minime + opțiune opacă pentru integrări externe prin introspecție.
Practici asemănătoare FAPI: algoritmi stricți de semnătură, cerințe TLS/redirect_uri/PKCE.

11) Erori și politica de returnare

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

Критичные коды: 'invalid _ request', 'nevalid _ client', 'nevalid _ grant', 'invalid _ scope', 'neautorizat _ client', 'access _ neged', 'temporar _ indisponibil'.
Limita ratei pentru criteriile finale sensibile ('/token ', '/introspect', '/revoce '), backoff exponențial.

12) Observabilitate și audit

• 'auth _ code _ success _ rate', 'pkce _ missing _ rate', 'mfa _ challenge/fail _ rate',
• 'token _ issuance _ p95 _ ms',' jwks _ skew _ ms', 'invalid _ token _ rate', 'rt _ reutilizare _ detected',
• по API: 'authz _ p95 _ ms',' deny _ rate {reason} ',' dpop _ match _ rate ',' mtls _ fail _ rate '.

Логи/трейсы: 'client _ id',' grant _ type ',' kid ',' acr/amr ',' chiriaş/regiune ',' decizie ',' policy _ version ',' aud ',' scp ',' sid ',' trace _ id'.
Audit (neschimbabil): emiterea de token-uri, escaladarea drepturilor, retragerea consimțământului, rotația cheie.

13) Managementul și rotația cheilor

Semnătura JWT: KMS/HSM, publicația JWKS cu „copil”.
Perioada cu două taste: IdP semnează nou, revizorii acceptă vechi + nou înainte de comutare.
Rotație regulată și revocare de urgență; monitorizarea consumului de „copil”.

14) Cărți de joc (runbooks)

1. Compromisul cheii de semnătură

Revocați imediat „copil”, emiteți un nou raport de audit RT/sesiuni cu handicap forțat.

2. Masa „invalid _ token ”/creștere 401

Verificați alinierea greșită a ceasului, expirat AT, cache JWKS rupt; creșteți temporar toleranța 'clock _ skew'.

3. Reutilizare RT

Blocați sesiunea ('sid'), notificați utilizatorul, solicitați un pas-up pentru o nouă conectare, investigați.

4. Cădere IdP

Activați modul „autorizare numai pentru citire”: păstrați AT-urile active până la TTL, restricționați conectările noi, scalați memoria cache pentru introspecție.

5. Atac asupra '/token '

Consolidați filtrele limită de rată/bot, activați mTLS/DPoP pentru clienții sensibili, mutați RT-urile reci într-un segment separat.

15) Testarea

Contract: OIDC discovery, JWKS, OpenID provider config.
Securitate: sunt necesare PKCE/nonce/state; seturi negative (substituții „redirect _ uri”, reutilizare RT).
Interoperabilitate: clienti (web/mobile/CLI), diferite fusuri orare/localizari.
Haos: eșec PAR/JARM, întârziere JWKS, rotit „copil” pe zbor.
E2E: pas-up MFA, OBO (token exchange), logout (față/back-channel), revocare/rotire.

16) Exemple de configurare

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) Lista de verificare pre-vânzare

• PKCE/nonce/stare activată; PAR/JAR/JARM sunt active.
• AT/RT/TTL ID set; RT rotație + reutilizare detectare activată.
• DPoP sau mTLS-obligatoriu pentru clienții/operațiunile sensibile.
• JWKS c „copil”; rotație automată și monitorizarea consumului cheie.
• Consimțământul/RAR și registrul domeniului de aplicare; intensificarea MAE pentru activități sensibile.
• PDP/PEP integrat, soluții de handicap cache.
• Jetoanele conțin 'chiriaș/regiune/licență'; se observă rezidența.
• Observabilitate: valori, busteni, trasare; alerte la 'invalid _ token', 'rt _ reutilizare', 'jwks _ skew'.
• Registrele de redare privind revocarea/rotirea/blocarea; butonul de deconectare de urgență.
• Un set de teste E2E/chaos/interop a fost trecut pe standuri.

Concluzie

Prin încorporarea OAuth2/OIDC ca o capacitate de platformă, obțineți fluxuri de autorizare previzibile, token-uri gestionate, politici de acces uniforme și risc măsurabil. AT-urile scurte protejate de RT, rotația cheilor, PAR/JARM/DPoP, consimțământul și pasul sunt practici care fac securitatea implicită și evoluția rapidă și nedureroasă pentru echipe și parteneri.