Autentificare și autorizare

Bucla de încredere AuthN/AuthZ este un singur punct de adevăr despre cine ești (autentificare) și ce ți se permite să faci (autorizare). Într-o platformă cu multe mărci, regiuni, integrări și cerințe de reglementare ridicate, acest contur ar trebui să fie modular, observat și gestionat de politicieni, și nu o „împrăștiere a if-urilor prin servicii”.

1) Termeni și roluri de bază

Identificare (ID): identificare (utilizator, serviciu, furnizor).
Autentificare (AuthN): dovada identității (parolă, MFA, certificat).
Autorizare (AuthZ) -Policy și pe bază de context poate/nu poate decide.
PDP/PEP: Punct de decizie politică/Punct de aplicare a politicilor.
IdP: Furnizor de identitate (OIDC).
Subiect/Resursă/Acțiune/Context: cine/ce/ce face/în ce condiții.

2) Arhitectura buclei generale

[ 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)

Principii: centralizarea generării de token și politici, aplicarea locală; „privilegii minime” și delegații explicite.

3) Autentificarea utilizatorului (OIDC/OAuth 2. 1)

• Codul de autorizare + PKCE (întotdeauna pentru SPA/Mobile).
• SSO: suport IdP extern (SAML/OIDC) pentru b2b/operatori.
• MFA: TOTP/WebAuthn/SMS (WebAuthn și TOTP recomandat; SMS - rezervă).
• Pas-up bazat pe risc: pentru acțiuni sensibile (retragerea fondurilor, schimbarea detaliilor) necesită MFA/pe-Auth.

• Refresh Token Rotation + RT registry cu reutilizare detectată.
• Nonce/State + PKCE, CORS/CSRF strict pentru fluxurile de browser.
• Jetoane de acces de scurtă durată (5-15 мин) + reîmprospătare silențioasă/RT.
• Legare dispozitiv (DPoP/mtls-legat token-uri) pentru operațiuni critice.

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) Autentificare serviciu-serviciu (mTLS, SPIFFE, JWT)

mTLS între servicii + SPIFFE/SPIRE pentru identificatori stabili ai volumului de lucru.
Service JWT cu o perioadă scurtă (≤5 minute), semnat de HSM/KMS; auditul emisiunii.
Public-scoped: JWT este potrivit numai pentru un anumit serviciu/domeniu.
Zone de încredere: servicii din altă regiune/chiriaș - PKI-uri și politici separate.

5) Modele de autorizare: RBAC, ABAC, ReBAC

RBAC (roluri → permisiuni): simplu și transparent (potrivit pentru panouri admin, operatori).

ABAC (atribute subiect/resursă/context): flexibil pentru "chiriaș =... ȘI regiune =... ȘI kyc_tier≥2"

ReBAC (relații): Util pentru exploatații complexe („care deține un brand/dosar/campanie”).

Recomandare: hibrid - RBAC de bază + condiții context ABAC + relații punct ReBAC.

6) Politici și executare (PDP/PEP)

PEP pe Gateway și în servicii: recuperează contextul (JWT, bilete, IP/ASN, timp, regiune, strat KYC), formează o cerere la 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" }
}

și returnează explicația 'ALLOW/DENY' +.

Cache-ul soluției PEP (TTL 30-120 c) reduce latența; handicap prin evenimente de tip „schimbare de rol/politică”.

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) Scopuri și rezoluții

• Resursă: acțiune - 'portofel: citit', 'portofel: transfer', 'pariuri: loc', 'kyc: stare. citește ".
• Pentru administratori - 'admin:' într-un domeniu independent.
• Pentru furnizori - "furnizor: raport. citiți „,” furnizor: evenimente. împinge ".

Principiul privilegiilor minime: atribuim doar domeniile necesare; „escaladare” (prelungirea temporară a drepturilor) - prin bilet și cu TTL.

8) Multi-chiriaș și regiuni (rezidență)

Jetoanele conțin „chiriaș”, „regiune”, „licență”; PDP verifică corespondența cu resursa.
Roluri/politici - namespaces per chiriaș („rol: brand _ eu/support”).
Separarea cheilor de semnătură și a listelor de revocare pe regiuni; cereri transregionale - numai prin gateway-uri de încredere.

9) Gestionarea sesiunilor și a dispozitivelor

Server-side session store pentru web (dispozitiv/browser de legare, rotație identificator).
Timeout inactiv/absolut (de ex. 30 min/24 h); acțiuni sensibile - re-Auth/MFA.
Listarea dispozitivelor active, „ieșire din toate”.
Anomalii: intrări simultane din diferite regiuni, căderi frecvente ale MFA - semnale de risc.

10) Delegare și consimțământ (consimțământ)

În numele (OBO): serviciul acționează în numele utilizatorului (un token proxy cu un „sub ”/„ act” separat).
Consimțământ: ecran explicit pentru accesul partenerilor la date, jurnal de consimțământ cu rechemare.
Mandate de acces temporare: drepturile pentru N ore/zile expiră automat.

11) Chei, semnături și rotație

JWKS cu „kid”, rotație automată, stocarea cheilor private în KMS/HSM.
Algoritmi: ES256/EdDSA pentru JWT; TLS 1. 2 +/mTLS.
Perioada cu două taste: Acceptați ambele 'kids' înainte de a finaliza upgrade-ul clientului.
RT și Token Introspection recheamă pentru incidente critice.

12) Securitatea aplicației clientului

SPA: Cod de autorizare + PKCE, fără „implicit”, строгий CORS/Content-Security-Policy.
Mobil: App Attestation/Device Check, stocare RT securizată, protecție root/jailbreak.
Desktop: browser de sistem pentru conectare (fără vizualizări web încorporate), PKCE.

13) Contracte SDK convenabile

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) Observabilitate și audit

• 'authn _ success _ rate '/' mfa _ challenge _ rate '/' mfa _ fail _ ratee'
• 'authz _ p95 _ ms',' authz _ neged _ rate {reason} '
• 'invalid _ token _ rate', 'jwks _ skew _ ms',' rt _ reutilizare _ detected '
• Anomalii ale intrărilor (dispozitiv nou, geo-viteză), scopuri suspecte.

• 'who/who/when/where/where/where/where/why', 'decizie', 'policy _ version', 'token _ kid', 'client _ id'.
• Export pentru conformitate (regulator/furnizor-audit).

15) Perimetrul și protecția clienților

Gateway PEP: limită de rată, verificări bot/semnătură, protecție CSRF, CORS strict, HSTS.
Trafic intern: mTLS + service JWT + rețele limitate.
Webhooks/ciocniri externe: semnături corporale (HMAC/JWS), ferestre de timp, anti-reluare.

16) Erori tipice

Jetoane de acces → scurgeri de informaţii.
Implicit fluxul OAuth în SPA.
Nici o rotație cheie și perioada Dual-Key.
Roluri hardcore în loc de politici (este imposibil de auditat/explicat deciziile).
Amestecarea chiriașilor/regiunilor într-un singur „rol” sau „cheie”.
Nici un MAE pas-up pe acțiuni sensibile.
Soluțiile AuthZ cache fără dizabilitate de schimbare a rolului.

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

1. Compromis cheie semnătură JWT

Revocarea imediată a „copilului”, publicarea noului JWKS, dizabilitatea forțată RT/sesiuni, raportul de audit.

2. Vrac 'invalid _ token'

Verificați alinierea greșită a ceasului/durata de viață, relevanța JWKS, accidentele cache.

3. Anomalii de intrare

Activați un scor de risc crescut, solicitați un pas înainte, notificați utilizatorul, limitați temporar plățile.

4. IdP-ul a eșuat

Comutați la cache-ul de sesiune/dispozitivul de rol, limitați conectările noi, țineți sesiunile active la TTL.

18) Lista de verificare pre-vânzare

• OIDC/OAuth 2. 1 cu PKCE, scurt AT, rotație RT, dispozitiv de legare pentru operațiuni critice.
• MFA (WebAuthn/TOTP) și pas-up pentru ieșire/schimbare de detalii/rol-escaladări.
• Service-to-service: mTLS + SPIFFE, JWT de serviciu de scurtă durată.
• Politicile AuthZ (RBAC + ABAC/ReBAC) în PDP centralizat; PEP pe gateway și în servicii.
• Soluții pentru persoanele cu handicap Cache; pista de audit neschimbabilă.
• Multi-chiriaș/regiuni: cheie/politică/izolare jurnal, contabilitate licență.
• JWKS/chei în KMS/HSM, rotație cu două taste, monitorizare 'kid'.
• CSRF/CORS/HSTS/Rate-limit/bot filtre pe perimetru.
• Playbook-uri incidente, revocați/rotiți/blocați butoanele de rulare.
• Suită de testare: unitate (politici), contract (SDK/fluxuri), haos (IdP, JWKS), e2e (pas-up, OBO, revoca).

19) Mini șabloane de configurare

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."]

Concluzie

Bucla de autentificare și autorizare nu este o bibliotecă, ci o capacitate de platformă: jetoane de scurtă durată și chei gestionate, politici centralizate și aplicarea lor locală, multifactor și step-up, izolarea strictă a chiriașilor/regiunilor, audit și telemetrie. Acest design face ca modificările să fie sigure, explicabile regulatorului și transparente pentru produs - iar scalarea prin piață și comandă devine o operațiune de rutină, nu o realizare.