Introduzione a OAuth 2.0 con Amazon Cognito

Cos’è OAuth 2.0 e come funziona?

OAuth 2.0 è un protocollo di autorizzazione che consente a un’applicazione di accedere a dati o funzionalità protette per conto di un utente, senza mai dover conoscere direttamente le sue credenziali.

Pensiamo a tutte le volte in cui abbiamo effettuato il login a un sito attraverso il nostro account Google. In quel caso abbiamo utilizzato proprio il protocollo OAuth 2.0: il sito non ha mai visto la nostra password, ma Google gli ha dato un permesso temporaneo per accedere a determinate informazioni.

Questo permesso prende la forma di un token di accesso, che può essere limitato nel tempo e nei privilegi concessi. Si tratta di un approccio moderno, sicuro e scalabile all’autorizzazione.

I ruoli in gioco nel protocollo OAuth 2.0

Proprietario della risorsa: è l’entità che possiede o controlla una risorsa protetta e può autorizzare l’accesso ad essa. Nella maggior parte dei casi, si tratta dell’utente finale.

Server delle risorse: è il server che ospita le risorse protette e le espone tramite un’interfaccia (tipicamente un’API). Accetta richieste solo se accompagnate da un token di accesso valido.

Client: è l’applicazione che vuole accedere alla risorsa protetta per conto del proprietario della risorsa. Deve prima ottenere l’autorizzazione.

Server di autorizzazione è il componente che autentica il proprietario della risorsa e, se l’autorizzazione va a buon fine, emette i token di accesso che il client può usare per accedere alla risorsa.

Supponiamo ad esempio che un’applicazione di analisi dati voglia leggere i dati presenti nel mio database. L’applicazione svolge il ruolo di client, io in quanto titolare dei dati sono il proprietario. Il server delle risorse è il server SQL che gestisce i dati protetti e il server di autorizzazione è Amazon Cognito, che gestisce l’autenticazione e rilascia i token di accesso.

Il grande merito di OAuth sta nell’aver introdotto un livello di autorizzazione e aver separato il ruolo del client da quello del proprietario della risorsa. Invece di utilizzare le credenziali personali dell’utente per accedere alle risorse protette, il client ottiene un access token – una stringa che specifica ambito, durata e altri attributi relativi all’accesso.

Cos’è Amazon Cognito e come funziona

Amazon Cognito è il servizio di AWS pensato per semplificare la gestione degli utenti in applicazioni moderne, sia web che mobile. La sua forza sta nella capacità di integrare in modo nativo i meccanismi di autenticazione e autorizzazione, seguendo lo standard OAuth 2.0, senza costringere gli sviluppatori a costruire da zero sistemi di login o gestione token.

L’autenticazione risponde di base alla domanda: “chi sei?”. E’ il processo attraverso cui un utente dimostra la propria identità.
Cognito gestisce questo tramite le cosiddette User pools: spazi sicuri dove sono registrati e conservati gli utenti delle nostre applicazioni. Possiamo decidere di far accedere gli utenti:

  • Con username e password, gestiti da Amazon Cognito.
  • Con autenticazione multi-fattore tramite app come Authy o Google Authenticator.
  • Tramite provider esterni come Google, Facebook, Apple o Azure AD
  • Con SAML o altri sistemi federati.

Una volta che l’utente si è autenticato con successo, Cognito rilascia un ID Token, contenente le informazioni sull’identità dell’utente e un Access Token, che servirà per accedere alle risorse protette.

L’autorizzazione risponde di base alla domanda “cosa puoi fare?”. E’ ciò che avviene dopo l’autenticazione: stabilisce a quali risorse l’utente ha diritto di accedere. Cognito gestisce questa parte seguendo lo standard OAuth 2.0, rilasciando token di accesso che possono essere usati per:

  • Accedere ad API protette da API Gateway
  • Comunicare con microservizi o backend personalizzati
  • Delegare autorizzazioni tra servizi in un’architettura distribuita

Ogni token ha una scadenza, un ambito di accesso richiesto e viene validato facilmente dai servizi che lo ricevono. Questo rende il sistema scalabile e adatto anche a progetti più complessi e articolati.

Cognito fornisce anche una interfaccia di login pronta all’uso chiamata Hosted UI, completamente personalizzabile con logo e tema della nostra azienda. Possiamo usarla per creare un’esperienza di autenticazione in pochi clic, senza sviluppare la logica e la parte di interfaccia grafica da zero.

Ogni applicazione che si collega a Cognito viene registrata come un differente app client. E’ a questo livello che è possibile specificare i diversi flussi di OAuth 2.0 supportati, l’URL di reindirizzamento ed eventuali opzioni extra, come la generazione dei refresh token.

Come abbiamo già detto, nel protocollo OAuth 2.0, Cognito svolge il ruolo di server di autorizzazione: si occupa di verificare l’identità dell’utente e rilasciare i token necessari per accedere alle risorse protette dopo aver ricevuto l’autorizzazione da parte dell’utente.

I principali flussi di OAuth 2.0

OAuth 2.0 è stato progettato per adattarsi a diversi scenari e a tal fine prevede più modalità di concessione (grant types ). Più informalmente si tende a parlare dei flussi di autorizzazione (flows), identificandoli con la modalità di concessione di cui fanno uso. Ciascuna definisce un percorso specifico per ottenere e validare un token di accesso. Vediamoli insieme.

Flusso del codice di autorizzazione (authorization code flow)

Questo flusso viene utilizzato dai client per scambiare in sicurezza un codice di autorizzazione (authorization code, appunto) con un token di accesso. Viene usato sia da applicazioni web che da quelle native per ottenere un token di accesso dopo che un utente si è autenticato.

E’ una modalità che si adatta a numerosi scenari perché prevede un unico flusso di autenticazione, indipendentemente dall’operazione effettuata o dal soggetto che la esegue. Il token di accesso non viene esposto direttamente ma piuttosto viene estrapolato a partire da un codice monouso. Questo contribuisce a evitare che il client possa accedere alle credenziali dell’utente.

Ecco la sequenza dei passaggi:

1 Avvio. Il processo inizia quando il client avvia la sequenza e reindirizza il browser del proprietario della risorsa verso l’endpoint di autorizzazione. In questa fase, il client specifica una serie di informazioni: il proprio identificativo,  l’ambito di accesso richiesto (in inglese scope) e una URL di reindirizzamento.

2 Autenticazione. Il server di autorizzazione, nel nostro caso Amazon Cognito, autentica il proprietario della risorsa (tramite il browser) e determina se l’utente autorizza o meno la richiesta di accesso da parte del client, utilizzando il meccanismo di autenticazione delle user pool.

3 Reindirizzamento. Cognito reindirizza il browser dell’utente verso il client, utilizzando l’URL di reindirizzamento fornita nel punto 1. In questo processo, Cognito include un codice di autorizzazione (da cui il nome del flusso) come parametro nelle query string dell’URL.

4 Scambio tra codice e token. Il client richiede un token di accesso chiamando l’endpoint dei token di Cognito, includendo il codice di autorizzazione ricevuto al punto 3. Durante questa richiesta il client si autentica presso Cognito usando il client ID e una password (client secret). Inoltre, riutilizza la stessa URL di reindirizzamento del punto 1, per consentire a Cognito di verificarne la corrispondenza.

5 Verifica. Cognito autentica il client, valida il codice di autorizzazione e verifica che l’ URL di reindirizzamento fornita coincida con quella usata nei passaggi precedenti. Se tutto è corretto Cognito restituisce un token di accesso, che il client potrà poi utilizzare per accedere alle risorse protette.

Flusso del codice di autorizzazione con PKCE

Il rischio nella procedura descritta è che qualcuno possa intercettare il codice di autorizzazione e utilizzarlo per ottenere un token di accesso.
Il ruolo del client secret è proprio quello di impedire che ciò accada. Tuttavia, nelle applicazioni pubbliche come le app mobile, non è sicuro né praticabile usare un client secret, perché il codice dell’app può essere analizzato da un utente malintenzionato.

Per risolvere questa falla di sicurezza, è stato creato il sistema PKCE, proof of key code exchange: esso aggiunge un ulteriore livello di protezione assicurandosi che solo il client che ha avviato il processo possa scambiare il codice di autorizzazione con un token di accesso.

Viene introdotto un segreto chiamato code verifier, ovvero un valore casuale creato dal client per ogni richiesta di autorizzazione. Questo valore segreto viene poi trasformato in un secondo codice chiamato code challenge, usando una tecnica che ne ricava una sorta di impronta digitale univoca (algoritmo SHA256). Il resto del flusso segue gli stessi passaggi descritti in precedenza con la differenza che la code challenge viene aggiunta nella richiesta al server di autorizzazione, cioè ad Amazon Cognito.

Di fatto:

  1. Cognito memorizza la code challenge associata alla sessione.
  2. Cognito reindirizza l’utente e restituisce un codice di autorizzazione.
  3. il client richiede il token di accesso e invia il codice di autorizzazione insieme al code verifier.
  4. Cognito ricalcola la code challenge a partire dal code verifier ricevuto e la confronta con quella memorizzata.

Solo se le due corrispondono, Cognito rilascia il token di accesso.

Flusso implicito (implicit flow)

Questo flusso è stato deprecato e oggi si raccomanda di utilizzare il grant con codice di autorizzazione e PKCE al suo posto.

Permetteva a client come applicazioni a pagina singola (single-page application) e app mobile di ottenere direttamente i token di accesso dell’utente dall’endpoint di autorizzazione. E’ stato chiamato implicito perché non prevedeva il rilascio di credenziali intermedie come il codice di autorizzazione, ma passava direttamente il token di accesso.

Lo svantaggio principale è che i token di accesso venivano esposti direttamente in un frammento dell’URL, il che comporta un enorme rischio di sicurezza: il token poteva essere memorizzato nella cronologia del browser, intercettato da script malevoli o reso accessibile ad altre applicazioni installate sullo stesso dispositivo.

Non esiste un modo robusto per verificare che la richiesta arrivi effettivamente dall’app giusta. Questo rende più facile a un malintenzionato impersonare un’app e rubare l’accesso.

Flusso delle credenziali client (client credentials flow)

Si tratta di un flusso pensato per l’autenticazione macchina-macchina (machine-to-machine, M2M) Ad esempio, supponiamo che un’applicazione di terze parti debba verificare la propria identità prima di poter accedere al tuo sistema. In questo caso, il client può richiedere un token di accesso utilizzando solo le proprie credenziali, quando sta cercando di accedere a risorse protette che sono sotto il controllo proprio o di un altro proprietario, previo accordo con il server di autorizzazione.

Si tratta di una modalità che deve essere utilizzata solo da client riservati, a volte detti client confidenziali: devono essere in grado di proteggere un segreto (una stringa privata) dagli utenti.
È importante notare che, per utilizzare questo flusso, il client associato al user pool deve avere configurato un client secret.

Quando usare i differenti flussi di OAuth

Per le caratteristiche presentate, ciascuno dei flussi va utilizzato per casi di uso specifici:

  • Applicazioni web classiche che fanno girare il codice su server > authorization code flow
  • Applicazioni pubbliche, come app mobile o single-page applications eseguite nel browser > authorization code flow con PKCE
  • Sistemi che si autenticano senza l’intervento di un utente umano, come i casi di comunicazione macchina-macchina. In questo caso il client e il proprietario della risorsa coincidono > client credentials flow
  • Solo se non è possibile avere un backend, ad esempio in applicazioni browser-based o pagine statiche JavaScript molto semplici: > implicit flow.

Come implementare i flussi di OAuth 2.0 in Amazon Cognito

Creazione della user pool

La prima cosa da fare è accedere al nostro account AWS e in particolare alla sezione dedicata ad Amazon Cognito tramite il seguente link: https://eu-south-1.console.aws.amazon.com/cognito
Una volta qui, creiamo la nostra user pool cliccando sul pulsante arancione:

Nella schermata che si apre, le opzioni che ci vengono proposte sono relative non tanto alla user pool ma all’app client che stiamo registrando presso di essa. Ci viene chiesto di specificare il tipo di applicazione: potrebbe trattarsi di una web app tradizionale, un’applicazione a pagina singola, un’applicazione nativa per mobile o una applicazione macchina-macchina. Questa scelta va a determinare i flussi di autorizzazione disponibili di default presso questa user pool; in seguito vedremo come modificare questa opzione.

Manteniamo per ora l’impostazione di default, scegliamo il nome dell’app client che vogliamo registrare e subito dopo abbiamo gli attributi da configurare per eseguire la registrazione (sign-up) e il login (sign-in). Infine è molto consigliato di scegliere l’url di reindirizzamento per quel specifico app client: come già visto, è l’url a cui reindirizza Cognito dopo che l’utente si è loggato correttamente. Un esempio che si usa spesso in letteratura è https://example.com/callback

Clicchiamo sul pulsante arancione Create user directory per finalizzare la creazione. Veniamo reindirizzati alla pagina con l’elenco delle user pool attive e dovremmo vedere quella appena creata. Dopo aver cliccato su di essa, scegliamo app clients nella barra laterale per verificare che il client sia stato effettivamente registrato. Cliccando su MyClient1, accedo al dettaglio di quel client, dove posso vedere una serie di informazioni che mi saranno utili.

Ancora nella barra laterale della user pool appena creata, clicchiamo sulla voce Domain, verso il basso. Qui dovremmo vedere un dominio di questa formato: https://eu-south-1e24l0wcyo.auth.eu-south-1.amazoncognito.com

Viene creato di default in seguito alla creazione della user pool e corrisponde al dominio pubblico per l’intera user pool, condiviso da tutti gli app client registrati presso di essa. Non ci sono problemi di confusione in quanto tutte le richieste come vedremo si basano su parametri che permettono di identificare univocamente il client come il client ID.

Flusso del codice di autorizzazione

Il primo passo che dà il via al flusso è una chiamata http GET al seguente endpoint: cognitoDomain/oauth2/authorize, dove cognitoDomain è il dominio di cui abbiamo appena parlato.

La chiamata includerà i seguenti parametri, specificati come query parameters nell’endpoint e non nel body, visto che si tratta di una GET:
– response_type: va settato a code
– client_id: va settato con il valore del client ID, che si trova nella schermata di dettaglio del nostro app client.
– redirect_uri: va settato all’url di reindirizzamento che abbiamo specificato in fase di creazione della user pool.
– state: si tratta di un valore random da generare lato client che serve a prevenire attacchi da malintenzionati.
– scope: una lista di parametri separati da uno spazio, corrispondono alle informazioni che l’app desidera ottenere. Ad esempio lo scope openid autorizza l’app a sapere chi sono e a staccare correttamente un id token; lo scope email autorizza l’app a leggere la mia email; lo scope profile autorizza l’app a leggere il mio nome e cognome ecc…

Prima di effettuare la chiamata tuttavia è importante verificare che le impostazioni lo consentano!

Dalla schermata di dettaglio dell’app client, visitiamo la tab login pages e nella sezione Managed login pages configuration clicchiamo su Edit. Ci sono due cose da verificare qui:
– deve essere presente Authorization grant sotto OAuth 2.0 grant types
– deve essere presente openid sotto OpenID Connect scopes
Se una di queste condizioni non è verificata, la chiamata non può andare a buon fine.

In mancanza di un’applicazione vera e propria che svolga il ruolo di client, per illustrare il funzionamento dei flussi ci serviremo del client per antonomasia per testare API: il buon vecchio Postman.
Ma quindi, a cosa serve questa chiamata e cosa restituisce? Eseguendola da Postman, vediamo che la risposta è una pagina html:

Ed è giusto così: la chiamata /authorize ci reindirizza alla pagina di login, corrispondente all’endpoint cognitoDomain/login,  dove gli utenti possono inserire le proprie credenziali e autenticarsi presso Amazon Cognito. Notare che l’url contiene ancora i query string parameters specificati nella /authorize.

Il passo successivo è eseguire il login cliccando su Next oppure, in mancanza di un utenza attiva presso la pool, la registrazione cliccando su Create account. In entrambi i casi verrà chiesto di inserire gli attributi specificati in fase di creazione della user pool, nel nostro caso solo l’email.

Dopo l’autenticazione, Cognito reindirizza al l’url di reindirizzamento specificato prima, nel nostro caso https://example.com/callback . Possiamo notare la presenza di due query string parameters: intanto c’è lo state che abbiamo specificato nella chiamata /authorize ma soprattutto c’è un parametro code: il suo valore è esattamente l’authorization code che dà il nome al flusso!

Come spiegato nella parte teorica dell’articolo, è il valore che viene scambiato per ottenere i token di accesso veri e propri. Questo scambio avviene grazie a un’ulteriore chiamata che simuliamo anche in questo caso da Postman.
La chiamata http è una POST a cognitoDomain/oauth2/token, dove cognitoDomain è il dominio associato alla nostra user pool.

La chiamata include i seguenti parametri in un body di tipo x-www-form-urlencoded:

– grant_type: va settato a authorization_code
– code: va settato al valore estrapolato dall’url dopo il login.
– client_id: va settato con il valore del client ID, che si trova nella schermata di dettaglio del nostro app client.
– redirect_uri: va settato all’url di reindirizzamento che abbiamo specificato in fase di creazione della user pool.

Se il nostro app client presenta un client secret, è fondamentale includerlo nella chiamata ma non va inserito nel body; va inserito nell’header Authorization come se fosse una Basic Auth con username corrispondente al client ID e password corrispondente al client secret.

Se tutto è stato configurato correttamente, la response in formato JSON contiene i seguenti parametri:

–access_token: un token per l’accesso alle risorse protette.
– refresh_token: un token per ricevere nuovi token di accesso dopo che questi sono scaduti.
– token_type: è settato a Bearer.
– expires_in: il periodo di validità del token di accesso, misurato in secondi.
– id_token: un token che contiene informazioni sull’identità del chiamante.

Così abbiamo ottenuto il token di accesso come desiderato. Questo determina la fine del flusso. Può essere utile vedere del codice javascript per implementare questi passaggi.
La prima immagine consiste nella chiamata ad /authorize, che in realtà si può implementare tramite un semplice redirect una volta specificati i corretti query string parameters:

La seconda invece consiste nell’estrapolazione del codice di autorizzazione a partire dalla url di reindirizzamento, qui corrispondente a window.location. Una volta fatto ciò inviamo in maniera programmatica il body: new UrlSearchParams serve a inviarlo in formato x-www-form-urlencoded come richiesto.

Flusso del codice di autorizzazione con PKCE

Anche in questo caso il flusso inizia con una chiamata http GET al seguente endpoint: cognitoDomain/oauth2/authorize, dove cognitoDomain è il dominio associato alla nostra user pool.

La chiamata includerà tutti i parametri elencati nel normale authorization flow e in più due parametri aggiuntivi:
– code_challenge_method: va settato alla stringa S256 e corrisponde all’algoritmo SHA-256.
– code_challenge: è una stringa alfanumerica generata random che serve a garantire un livello extra di sicurezza.
Per capirne il funzionamento ci basiamo su un tool online:  https://tonyxu-io.github.io/pkce-generator/ . Questo sito ci permette di generare sia il code verifier cioè la stringa random originale, sia la versione “hashata”, ovvero il risultato dell’algoritmo SHA-256 applicato a quella originale. Quest’ultima è proprio la code_challenge.

Esattamente come nel flusso normale:
– deve essere presente Authorization grant sotto OAuth 2.0 grant types
– deve essere presente openid sotto OpenID Connect scopes
Se una di queste condizioni non è verificata, la chiamata non può andare a buon fine.

La chiamata /authorize ci reindirizza alla pagina di login, corrispondente all’endpoint cognitoDomain/login,  dove gli utenti possono inserire le proprie credenziali e autenticarsi presso Amazon Cognito. Notare che l’url contiene ancora i query string parameters specificati nella /authorize.

Il passo successivo è eseguire il login cliccando su Next oppure, in mancanza di un utenza attiva presso la pool, la registrazione cliccando su Create account. Di nuovo veniamo reindirizzati a https://example.com/callback e tra query parameters c’è l’authorization code che useremo nella chiamata successiva.

Anche qui la chiamata per scambiare il codice con il token è una POST a cognitoDomain/oauth2/token. Nel body di tipo x-www-form-urlencoded ci saranno tutti i parametri specificati nel flusso normale e in aggiunta ci sarà:

–code_verifier: inviamo la stringa random originale. Cognito andrà a calcolare la versione hashata e verificherà che il risultato corrisponde al parametro inviato nella /authorize. Questo è l’ulteriore livello di conferma dell’identità introdotto da PKCE.

Se tutto è stato configurato correttamente, otteniamo una response con gli stessi identici parametri del flusso normale, tra cui il token di accesso.
Vediamo ora del codice javascript per implementare questi passaggi.

La prima immagine mostra come implementare in maniera programmatica la generazione di codeVerifier e codeChallenge mentre la seconda consiste nella chiamata ad /authorize, che in realtà si può implementare tramite un semplice redirect una volta specificati i corretti query string parameters.

Segue qui l’estrapolazione del codice di autorizzazione a partire dalla url di reindirizzamento, qui corrispondente a window.location. Una volta fatto ciò inviamo in maniera programmatica il body.

Flusso delle credenziali client

A differenza dei flussi precedenti, questo non presuppone la chiamata /authorize né la /login! In effetti non avrebbe senso perché viene utilizzato proprio quando non c’è un utente umano ma è il client stesso ad autenticarsi.
Le credenziali vengono usate direttamente nella chiamata all’endpoint /token.

Andiamo con ordine. Nel dettaglio del client, visitiamo la tab login pages e nella sezione Managed login pages configuration clicchiamo su Edit. Qui:
– deve essere presente Client credentials sotto OAuth 2.0 grant types
– deve essere compilato il campo Custom scopes
Tuttavia nel menù a tendina inizialmente non c’è uno scope tra cui scegliere…

Dobbiamo visitare la voce Domain nella barra laterale della user pool: in basso vediamo la sezione Resource server: clicchiamo su Create resource server.

Ricordiamo che quest’ultimo rappresenta l’API protetta a cui si vuole accedere con l’access token. Inoltre Cognito necessita sapere quali permessi assegnare a questo specifico token ed è qui che entrano in gioco gli scopes: limitarne la portata e le operazioni consentite.

Compiliamo i campi sullo stesso modello indicato nella figura seguente.

La chiamata http è una POST a cognitoDomain/oauth2/token, dove cognitoDomain è il dominio associato alla nostra user pool.

La chiamata include i seguenti parametri in un body di tipo x-www-form-urlencoded:

– grant_type: va settato a client_credentials
– client_id: va settato con il valore del client ID, che si trova nella schermata di dettaglio del nostro app client.
– scope: il valore da inserire è resourceServerIdentifier/scope, dove i parametri corrispondono a quelli inseriti in fase di creazione del resource server.

Se il nostro app client presenta un client secret, è fondamentale includerlo nella nell’header Authorization come se fosse una Basic Auth con username corrispondente al client ID e password corrispondente al client secret.

La response in formato JSON questa volta non contiene né il refresh token, né l’id token ma semplicemente:

–access_token: un token per l’accesso alle risorse protette.
– token_type: è settato a Bearer.
– expires_in: il periodo di validità del token di accesso, misurato in secondi.

Per concludere vediamo il codice javascript per implementare il flusso. Non essendoci la chiamata /authorize vediamo solo quello per ottenere il token:

Flusso implicito

Il flusso inizia con una chiamata http GET al seguente endpoint: cognitoDomain/oauth2/authorize, dove cognitoDomain è il dominio della nostra user pool.

La chiamata includerà gli stessi parametri del semplice authorization flow ma con una differenza chiave:
– response_type: va settato a token, non a code.

Dalla schermata di dettaglio dell’app client, visitiamo la tab login pages e nella sezione Managed login pages configuration clicchiamo su Edit. Ci sono due cose da verificare qui:
– deve essere presente Implicit grant sotto OAuth 2.0 grant types
– deve essere presente openid sotto OpenID Connect scopes

La chiamata /authorize ci reindirizza alla pagina di login, corrispondente all’endpoint cognitoDomain/login,  dove gli utenti possono inserire le proprie credenziali e autenticarsi presso Amazon Cognito. Notare che l’url contiene ancora i query string parameters specificati nella /authorize.

Il passo successivo è eseguire il login cliccando su Next oppure, in mancanza di un utenza attiva presso la pool, la registrazione cliccando su Create account.
Di nuovo veniamo reindirizzati a https://example.com/callback ma con una grande differenza rispetto agli altri flussi: nell’url questa volta è già presente il token di accesso!

Questo rende di fatto inutili ulteriori chiamate! Non serve la chiamata POST! I parametri che possiamo estrapolare dall’url (non dai query parameters ma dai fragments) sono:

–access_token: un token per l’accesso alle risorse protette.
– token_type: è settato a Bearer.
– expires_in: il periodo di validità del token di accesso, misurato in secondi.
– id_token: un token che contiene informazioni sull’identità del chiamante.

Per concludere vediamo un’implementazione del codice javascript per la chiamata /authorize in questo caso:

Seguire le best practice nei flussi OAuth

Per concludere parliamo di una serie di prassi da seguire quando si lavora con i flussi di OAuth e Amazon Cognito. Alcune di esse si applicano a differenti flussi, mentre altre sono più specifiche.

-ruotare regolarmente i client secret delle nostre applicazioni: questo aiuta a minimizzare il rischio che quel segreto venga compromesso e usato per accessi da parte di terzi.

– nelle applicazioni, è importante implementare meccanismi per limitare l’uso dei token. Ad esempio, è consigliabile definire una durata appropriata per il token di accesso. Anche i refresh token andrebbero gestiti con attenzione: poiché permettono di ottenere nuovi access token, non dovrebbero avere durata indefinita, e andrebbero ruotati ad ogni utilizzo, invalidando il precedente. Infine, è fondamentale prevedere la revoca dei token, ad esempio in caso di logout o cambio password, per impedire accessi non autorizzati.

– il flusso di autorizzazione è più sicuro se decidiamo di utilizzare l’approccio con PKCE. Non è obbligatorio sempre, ma lo è per client pubblici che non hanno modo di usare un secret.

– nel flusso implicito, la validità dei token non può essere revocata, di conseguenza l’unico modo per limitarli e dare loro un breve periodo di scadenza. Ma ancora una volta, questo flusso andrebbe usato solo in casi estremi.

Vuoi integrare i servizi AWS nelle tue soluzioni?

Affidati ai nostri esperti e compila i campi qui sotto, ti ricontatteremo quanto prima.