AWS Cognito: gestione degli utenti e dell'autenticazione
AWS Cognito offre una soluzione affidabile e scalabile per la gestione degli utenti e dell'autenticazione per applicazioni web e mobili, senza dover gestire un proprio backend di identità. Il servizio integra fornitori di identità esterni e fornisce token conformi agli standard per le API. Inoltre permette lo scambio di token di identità con credenziali temporanee di AWS per l'accesso diretto ai servizi AWS come S3 e DynamoDB.
Quelle: Rappresentazione personalizzata
Fondamenti di AWS Cognito
AWS Cognito è composto da due componenti principali: User Pools e Identity Pools.
Pool di utenti sono un registro utenti e un fornitore di identità. OpenID-Connect-kompatibler Identity Provider. Essi autenticano gli utenti, rilasciano token ID, token di accesso e token di aggiornamento e integrano fornitori di identità sociali o aziendali tramite OIDC o SAML.
Pool di identità (conosciuti anche come Identità federate) forniscono sulla base di queste identità kurzlebige AWS-Credentials. Questo è possibile anche per gli ospiti che non hanno ancora effettuato l'accesso.
La pagina di accesso gestita, precedentemente nota come Hosted UI e oggi chiamata Managed Login, è disponibile
standardkonforme OAuth-Endpunkte tra cui
/oauth2/authorize, /oauth2/token, /logout nonché la scoperta OIDC- OIDC Discovery- e JWKS-Ressourcen.
Per le Single Page Applications (SPAs) è di fondamentale importanza,
Authorization-Code-Flow mit PKCE poiché previene che i codici intercettati possano essere sfruttati.
I token emessi sono JSON Web Tokens (JWTs). I token di accesso trasportano ambiti e gruppi per l'autorizzazione API, mentre i token ID contengono informazioni sul profilo. Le firme di questi token possono essere verificate contro l'URL JWKS del pool di appartenenza.
Stato attuale e funzionalità
I tempi di validità dei token possono essere impostati per ciascun client dell'app in modo preciso. 5 Minuten und 1 Tag I tempi di validità dei token possono essere configurati. I token di refresh hanno una validità predefinita di 30 giorni, che può variare. 60 Minuten und 10 Jahren può variare.
Le pagine di accesso gestite supportano PKCE standardmäßig. Il Logout-Endpunkt termina la sessione del browser e reindirizza alle URL di logout configurate.
Quelle: aws.amazon.com
Panoramica delle funzionalità principali di Amazon Cognito.
Per un branding personalizzato e l'uso di domini propri, è possibile configurare una Custom Domain mit einem ACM-Zertifikat configurata (è richiesto il certificato in us-east-1). Dopo di che l'accesso avviene tramite il proprio sottodominio.
Le API possono essere protette direttamente all'API Gateway con un issuer OIDC accettato da Cognito, oppure JWT-Authorizer tramite un proprio autorizzatore (Lambda).
La adaptive/risikobasierte Anmeldung („Threat Protection“) può classificare tentativi di accesso sospetti, imporre l'autenticazione a più fattori (MFA) o bloccare l'accesso.
Per applicazioni multi-tenant AWS documenta diversi modelli, tra cui Single-Pool-Ansatz bis hin zu einem Pool pro Tenant, inclusi isolamento tramite gruppi/ruoli e ambiti.
L'integrazione nelle applicazioni Next.js è facilitata da Cognito-Provider von NextAuth semplificata. Le sessioni sono gestite tramite JWT e cookie, e Edge Middleware protegge le rotte.
Contesto e motivazioni
Le applicazioni moderne necessitano di uno strato di identità centrale che supporti standard industriali come OIDC/OAuth2/SAML supporta, affronta i rischi tramite MFA e autenticazione adattiva e, allo stesso tempo, consente l'integrazione di fornitori di identità propri. Per le SPA è necessario PKCE unverzichtbar, poiché i secret dei client non possono essere conservati in modo sicuro nel browser; Cognito implementa PKCE completamente.
Sul lato API, l'accesso diretto JWT-Abgleich am API Gateway è attraente. Offre latenze basse, una chiara separazione tra autenticazione (AuthN) e autorizzazione (AuthZ) e evita un ulteriore roundtrip al deposito degli utenti.
La conformità e la residenza dei dati sono ulteriori aspetti importanti. I pool di utenti memorizzano i dati di profilo a livello regionale. Caratteristiche opzionali come Pinpoint-Analytics possono inviare dati in altre regioni, il che è rilevante per i team UE/CH e besondere Beachtung erfordert.
Quelle: YouTube
Questo video mostra SAML-Föderation mit Cognito, che è utile per comprendere visivamente scenari basati su IdP e il Single Logout.
Applicazioni pratiche e consigli
Chi sviluppa una SPA o un'app Next.js dovrebbe scegliere Authorization Code Flow mit PKCE scegliere. I token dovrebbero essere memorizzati sul lato server in cookie httpOnly o utilizzare la meccanica di sessione del framework. JWKS-Endpunkt des Pools avvenga.
Quelle: economize.cloud
Flusso di autenticazione tipico con AWS Cognito.
Le API dovrebbero verificare gli ambiti e utilizzare uno meccanismo per JWT-Authorizer disaccoppiare autenticazione e autorizzazione e mantenere bassa la latenza.
Per applicazioni multi-tenant, è consigliabile iniziare con un Single-Pool-Ansatz soluzione che includa attributi del tenant o ambiti. In caso di requisiti di isolamento severi, potrebbe essere considerato un pool per tenant.
Nell'ambito delle operations è consigliabile, CloudTrail und CloudWatch-Metriken attivare, monitorare quote e modelli di accesso e, facoltativamente, utilizzare il Threat Protection per utilizzarlo.
In termini di conformità, i flussi di dati regionali (ad es. tramite Analytics) devono essere verificati e documentati per i team UE/CH, in particolare tenendo conto di regionalen Datenüberlegungen.
Quelle: YouTube
Questo walkthrough aiuta Authorization-Code-Flow mit PKCE a capire end-to-end.
Domande aperte e sfide
La progettazione dei TTL dei token e della rotazione deve essere attentamente bilanciata per trovare un equilibrio tra UX e livello di sicurezza, evitando che le applicazioni siano costrette a continui aggiornamenti. AWS consiglia di utilizzare i token solo per circa 75 Prozent ihrer Lebenszeit e rinnovarli solo in seguito.
Sorge la domanda fino a che punto l'isolamento tra tenant tramite gruppi/ambiti sia sufficiente prima che sia necessario dividere i pool per motivi organizzativi e di costi. anwendungsabhängig.
Quelle: aws.amazon.com
Integrazione di Cognito con fornitori di identità esterni e servizi AWS.
Quali dati, in base alle norme di conformità applicabili, possono lasciare la regione quando sono attive funzionalità opzionali come Pinpoint? Qui è necessario verificare e documentare le opt-in. regionalen Hinweise da verificare e documentare gli opt-in.
La coerenza del Single Logout tra tutti gli IdP collegati è un'altra sfida. Per SAML esistono SLO-Unterstützung, tuttavia i dettagli di implementazione variano a seconda dell'IdP.
Conclusione: AWS Cognito offre un solido nucleo di autenticazione basato su standard con chiari punti di estensione: gestione dell'accesso con PKCE, verifica pulita dei JWT e federazione opzionale verso provider di identità sociali o aziendali. In pratica è cruciale scegliere il flusso adatto all'applicazione, limitare consapevolmente i token e autorizzare rigorosamente lo strato API tramite gli scope. Nella pianificazione di architetture multi-tenant bisogna prendere decisioni sui confini di isolamento e sulle metriche operative fin dall'inizio. I mattoni esistono; la decisione di progettazione spetta all'utente.