Un login per ogni prodotto che la vostra azienda usa.

OIDC standard, con discovery

La piattaforma pubblica un documento di discovery in /.well-known/openid-configuration e un set di chiavi pubbliche in /.well-known/jwks.json, ed espone un endpoint userinfo.

Pubblicare il JWKS è ciò che permette agli altri vostri sistemi di verificare un token in modo indipendente. Recuperano la chiave pubblica e controllano la firma da soli: non detengono mai un segreto condiviso nostro, e una compromissione dalla loro parte non diventa una compromissione dalla nostra.

Authorization code flow con PKCE

Il login usa l’authorization code flow con PKCE, accettando un code challenge e un metodo nella richiesta di autorizzazione e richiedendo il verifier allo scambio del token.

PKCE chiude la finestra di intercettazione del codice di autorizzazione, l’attacco che ha reso obsoleto l’implicit flow. È la raccomandazione attuale per ogni tipo di client, non solo per il mobile.

I token sono RS256 e di breve durata

I token di accesso e ID sono firmati in RS256 contro il set di chiavi pubblicato, con un id di chiave così che una chiave possa ruotare senza invalidare ogni token in circolazione. I token di accesso sono tipizzati at+jwt.

La firma asimmetrica è il motivo per cui un prodotto delegante può verificare un token offline. La firma simmetrica richiederebbe di distribuire il segreto di firma a ogni relying party, il che rende ognuna di esse un posto da cui il vostro sistema di identità può essere falsificato.

Rotazione dei refresh token con rilevamento del riutilizzo

I refresh token ruotano a ogni utilizzo, e il riutilizzo è trattato come furto. Presentare un refresh token già riscattato revoca l’intera famiglia di token invece del solo token presentato.

È il comportamento che rende contenibile un refresh token rubato. Senza rotazione, un refresh token trapelato è una credenziale durevole. Con rotazione e rilevamento del riutilizzo, l’attaccante e il vero utente non possono continuare entrambi a usare la sessione, e il secondo tentativo la termina per chiunque detenga quella linea.

Password e segreti conservati

argon2id

L’hashing delle password usa argon2id, vincitore della Password Hashing Competition. I vecchi hash di un sistema precedente vengono rilevati e aggiornati in modo trasparente al successivo login riuscito.

AES-256-GCM

Le chiavi dei provider sono sigillate a riposo con cifratura autenticata e supportano la rotazione: la chiave di cifratura può cambiare senza ricifrare in anticipo ogni segreto conservato. Le risposte API espongono solo gli ultimi quattro caratteri di una chiave.

Chiuso per impostazione predefinita

L’autenticazione è un guard globale, e una route è pubblica solo se esplicitamente marcata. Un guard dimenticato quindi chiude invece di esporre silenziosamente un endpoint.

Ruoli e accesso per prodotto

L’accesso è basato sui ruoli, e le autorizzazioni controllano quali prodotti un membro può usare. Rimuovere qualcuno una volta lo rimuove da tutto ciò che sta a valle, che è la ragione operativa per centralizzare l’identità.