Autenticazione e autorizzazione

Un tracciato affidabile è un unico punto di verità su chi sei (autenticazione) e cosa sei autorizzato (autorizzazione). In una piattaforma con molteplici marchi, regioni, integrazioni e requisiti regolatori elevati, questo tracciato deve essere modulare, monitorato e gestito da policy piuttosto che «if-ov per servizi».

1) Termini e ruoli di base

ID - Identificazione (user, service, provider).
Autenticazione (AuthN): prova di identità (password, MFA, certificato).
Autorizzazione (AuthZ) - La decisione «possibile/non» basata su criteri e contesti.
PDP/PEP: Policy Decection Point (decisa )/Policy Enforcement Point (applicato).
IdP: provider di identificazione (OIDC).
Subject/Resource/Action/Text: chi/cosa/cosa fa/a quali condizioni.

2) Architettura generale del tracciato

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

Principi: centralizzazione della generazione di token e regole, applicazione locale; «privilegi minimi» e deleghe esplicite.

3) Autenticazione utente (OIDC/OAuth 2. 1)

• Authorization Code + PKCE (sempre per SPA/Mobile).
• Supporto SSO (SAML/OIDC) per b2b/operatori.
• MFA: (raccomandati) e TOTP; SMS — fallback).
• Risk-based Step-Up - In caso di attività sensibili (prelievo, modifica delle identità), richiedere MFA/pe-Auth.

• Refresh Token Rotation + Registro RT con dettaglio di riutilizzo.
• Nonce/State + PKCE, CORS/CSRF rigoroso per i flussi di browser.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DPoP/mtls-bound tokens) per le operazioni critiche.

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) Autenticazione servizio (mTLS, SPIFFE, JWT)

mTLS tra i servizi + SPIFFE/SPIRE per gli identificatori di workload resistenti.
Servizio JWT a breve scadenza (≤5 min) firmato HSM/KMS; Controllo del rilascio.
Audience-scoped: JWT è valido solo per un particolare servizio/dominio.
Aree di fiducia: servizi provenienti da un'altra regione/tenante - PKI e politiche separate.

5) Modelli di autorizzazione: RBAC, ABAC, ReBAC

RBAC (ruoli di risoluzione →): semplice e trasparente (adatto per pannelli admine, operatori).
ABAC (attributi soggetto/risorsa/contesto) - flessibile per le regole "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (relazione) è utile per proprietà complesse («chi possiede un marchio/cartella/campagna»).

Raccomandazione: ibrido - RBAC base + condizioni ABAC contestuali + relazioni REBAC puntuali.

6) Criteri e loro esecuzione (PDP/PEP)

PEP su Gateway e nei servizi: recupera il contesto (JWT, mandati, IP/ASN, tempo, regione, livello KYC) e crea una richiesta 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" }
}

e restituisce ALLOW/DENY + spiegazione.

La cache PEP (TTL 30-120 c) riduce la latitudine invalidazione per eventi di modifica di ruoli/regole.

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) Scorciatoie e autorizzazioni

• Risorsa: "wallet: read", "wallet: transfer", "bets: place", "kyc: status. read`.
• Per gli ammiragli, 'ammin:' in un dominio isolato.
• Per i provider - 'provider: report. read`, `provider:events. push`.

Principio di privilegio minimo: assegniamo solo le scorciatoie necessarie; «escalation» (estensioni temporanee dei diritti) - ticket e TTL.

8) Multi-tenente e regioni (residency)

I token contengono tenant, region, licence; PDP verifica la corrispondenza della risorsa.
Ruoli/criteri - Spazi per nomi per tenant ('rolle: brand _ eu/support').
Separazione delle chiavi di firma e degli elenchi di richiamo per regione Richieste crocifissionali solo tramite gateway affidabili.

9) Gestione di sessioni e dispositivi

Server-side position store per il web (collegamento al dispositivo/browser, rotazione dell'ID).
Idle/Assolute Timeout (ad esempio, 30 min/24 h); azioni sensibili - re-Auth/MFA.
Listing dei dispositivi attivi, «uscita da tutti».
Anomalie: entrate simultanee da diverse regioni, frequenti fallimenti MFA - segnali di rischio.

10) Delega e consenso (consent)

On-behalf-of (OBO) - Il servizio agisce per conto dell'utente (proxy-token con «sub »/« act»).
Consenso: schermata esplicita per l'accesso ai dati da parte del partner, registro di accettazione della recensione.
Access-mandates temporanei - I diritti N ore/giorni scadono automaticamente.

11) Chiavi, firme e rotazione

JWKS con'kid ', rotazione automatica, archiviazione delle chiavi private in KMS/HSM.
Algoritmi: ES256/EdDSA per JWT; TLS 1. 2+/mTLS.
Periodo dual-key: accetta entrambi i kid fino al completamento dell'aggiornamento client.
Recensione di RT e Token Introspection per incidenti critici.

12) Protezione delle applicazioni client

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, archivio RT protetto, protezione da rut/jailbrake.
Desktop: browser di sistema per login (no embedded web-views), PKCE.

13) Contratti SDK convenienti

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) Osservazione e verifica

• `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`
• Anomalie di ingresso (new device, geo-velocity), scoop sospetti.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Esporta per la compilazione (controllo/controllo vendor).

15) Protezione del perimetro e del cliente

Gateway PEP: rate-limit, bot/firma checks, protezione CSRF, CORS rigoroso, HSTS.
Traffico interno: mTLS + servizi JWT + reti limitate.
Webhook/colleback esterni: firme del corpo (HMAC/JWS), finestre del tempo, anti-repliche.

16) Errori tipici

Token access a lunga durata per la fuga.
Flusso implicito di OAuth in SPA.
Nessuna rotazione delle chiavi e periodo Dual-Key.
Ruoli zoccati al posto delle regole (impossibile verificare o spiegare le soluzioni).
Mescolare tenenti/regioni in un singolo «role» o «key».
Niente step-up MFA su azioni sensibili.
La cache delle soluzioni non è invalidata dalle modifiche dei ruoli.

17) Playbooks (runbooks)

1. Compromettere la chiave di firma JWT

Revoke «kid» immediato, pubblicazione di un nuovo JWKS, disabilità forzata RT/sessioni, report di verifica.

2. Massiccia'invalid _ token'

Controlla le ore/orari di rashincron, l'attualità di JWKS, i guasti di cache.

3. Anomalie degli ingressi

Attivare un aumento del rischio-scorrimento, richiedere step-up, avvisare l'utente, limitare temporaneamente i pagamenti.

4. Errore di IdP

Passare alla cache delle sessioni/ruolo-apparecchio, limitare i nuovi login, mantenere le sessioni attive fino a TTL.

18) Foglio di assegno prima della vendita

• OIDC/OAuth 2. 1 con PKCE, AT corto, rotazione RT, device binding per operazioni critiche.
• MFA (WebAuthn/TOTP) e step-up per le conclusioni/cambi di identità/ruolo-escalation.
• Servizio-to-service: JWT di breve durata.
• Criteri di AuthZ (RBAC+ABAC/ReBAC) in PDP centralizzato; PEP su gateway e nei servizi.
• Cache di soluzioni invalidanti audittrail non modificabile.
• Multi-tenant/regioni: isolamento chiavi/regole/logi, registrazione licenze.
• JWKS/chiavi in KMS/HSM, rotazione dual-key, monitoraggio «kid».
• CSRF/CORS/HSTS/Rate-limit/bot-filtri nel perimetro.
• playbook incidenti, run-pulsanti revoke/rotate/lockdown.
• Set di test: unit (policies), contract (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Mini modelli di configurazione

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

Conclusione

Il tracciato di autenticazione e autorizzazione non è una libreria, ma una TPM: token a breve durata e chiavi controllate, regole centralizzate e loro applicazione locale, multifattore e step-up, isolamento rigoroso dei tenanti/regioni, controllo e telemetria. Questo design rende i cambiamenti sicuri, spiegabili per il regolatore e trasparenti per il prodotto - e scalare i mercati e i team diventa un'operazione di routine, non un exploit.