Utilizzo di OpenID Connect per estendere OAuth 2.0

Un token di identità è un token protetto dall'integrità e autonomo (in formato JWT (JSON Web Token) definito nello standard OpenID Connect contenente le richieste di risarcimento relative all'utente finale. Il token di identità è l'estensione primaria che OpenID Connect effettua a OAuth 2.0 per abilitare l'autenticazione in un dominio di Identity.

Il token di identità JWT è composto da tre componenti, un'intestazione, un payload e la firma digitale. Seguendo lo standard JWT, queste tre sezioni sono codificate Base64URL e separate da punti.

OpenID Connect 1.0 è un semplice livello di identità sopra il protocollo OAuth 2.0. Consente a un'applicazione client del dominio di Identity IAM (registrata come client OAuth 2 con ID client e segreto client) di verificare l'identità dell'utente finale in base all'autenticazione eseguita da un server di autorizzazione (AS) e di ottenere informazioni di profilo di base sull'utente finale in modo interoperabile, simile a REST. OpenID Connect consente ai client di tutti i tipi, inclusi client basati su Web, mobile e JavaScript di richiedere e ricevere informazioni sulle sessioni autenticate e sugli utenti finali. Per ulteriori informazioni, vedere OpenID Connect.

Perché convalidare i token? Quando l'applicazione Web controlla le credenziali direttamente, verifica che il nome utente e la password presentati corrispondano a quanto gestito. Quando si utilizza l'identità basata su richieste di rimborso, la mansione viene affidata in outsourcing a un provider di identità.

La responsabilità passa dalla verifica delle credenziali raw alla verifica che il richiedente sia passato attraverso il provider di identità preferito e sia stato autenticato correttamente. Il provider di identità rappresenta l'autenticazione riuscita mediante l'emissione di un token. Prima di poter utilizzare le informazioni o fare affidamento su di esse come asserzione che l'utente ha autenticato, è necessario convalidarle.

Documento di ricerca automatica OpenID

Il protocollo OpenID Connect 1.0 è un semplice livello di identità sopra il protocollo OAuth 2.0 che richiede l'uso di più endpoint per l'autenticazione degli utenti e per la richiesta di risorse che includono informazioni utente, token e chiavi pubbliche. Per aiutarti a scoprire quali sono questi endpoint che devi utilizzare, OpenID Connect ti consente di utilizzare un documento di ricerca automatica, che è un documento JSON trovato in una posizione ben nota. Questo documento di ricerca automatica contiene coppie chiave/valore che forniscono dettagli sulla configurazione del provider OpenID Connect, inclusi gli URI degli endpoint di autorizzazione, token, userinfo e chiavi pubbliche. È possibile recuperare il documento di ricerca automatica per il servizio OpenID Connect del dominio di Identity IAM da: https://<domainURL>/.well-known/openid-configuration.

L'endpoint UserInfo di OpenID Connect viene utilizzato da un'applicazione per recuperare le informazioni sul profilo relative all'identità autenticata. Le applicazioni possono utilizzare questo endpoint per recuperare le informazioni sul profilo, le preferenze e altre informazioni specifiche dell'utente.

Il profilo OpenID Connect è composto da due componenti:

• Richieste di risarcimento che descrivono l'utente

• Endpoint UserInfo che fornisce un meccanismo per recuperare queste richieste

  Nota
  
  Le richieste di rimborso utente possono essere presentate anche all'interno del token ID per eliminare un callback durante il tempo di autenticazione.

Profilo utente - Richieste di risarcimento

L'endpoint UserInfo fornisce un set di richieste basate sugli ambiti OAuth2 presentati nella richiesta di autenticazione. OpenID Connect definisce cinque valori di ambito mappati a un set specifico di richieste predefinite:

Il client deve presentare le proprie credenziali e un token di accesso. Il token di accesso presentato deve contenere l'ambito openid.

Se un ambito viene omesso (ad esempio, l'ambito email non viene utilizzato), la richiesta (email) non sarà presente nelle richieste restituite.

Esempio di richiesta endpoint UserInfo

Dopo che l'applicazione client ha autenticato un utente e dispone del token di accesso, il client può quindi effettuare una richiesta all'endpoint UserInfo per recuperare gli attributi richiesti relativi a un utente. L'esempio riportato di seguito mostra un esempio di richiesta.

   curl -i
   -H 'Content-Type: application/x-www-form-urlencoded'
   -H 'Authorization: Bearer eyJ4NXQjUzI1....rtApFw'-H 'Accept: */*'
   -H 'Content_Language: en-US'--request GET https://<domainURL>/oauth2/v1/userinfo

Esempio di risposta

Una risposta riuscita restituisce una risposta HTTP 200 OK e le richieste dell'utente in formato JSON:

{
"birthdate":"",
"email":"user@example.com",
"email_verified":false,
"family_name":"user",
"gender":"",
"given_name":"user",
"appRoles":[],
"name":"alice alice",
"preferred_username":"user@example.com",
"sub":"user@example.com",
"updated_at":1495136783,"website":""
}

Prima che l'applicazione client possa considerare attendibili i valori restituiti dall'endpoint UserInfo (ad esempio, come controllo dell'attacco di sostituzione del token), il client deve verificare che la richiesta sub restituita dalla richiesta dell'endpoint UserInfo corrisponda all'oggetto del token ID.

Utilizzare il flusso Codice autorizzazione quando si dispone di client in grado di gestire in modo sicuro un segreto client tra se stessi e il server di autorizzazione. Il flusso del codice di autorizzazione restituisce un codice di autorizzazione al client, che può quindi scambiare il codice per un token ID e un token di accesso direttamente.

Ciò offre il vantaggio di non esporre alcun token all'agente utente (ad esempio un browser Web) e, eventualmente, ad altre applicazioni dannose con accesso all'agente utente. Il server di autorizzazione può anche autenticare il client prima di scambiare il codice di autorizzazione per un token di accesso. Il flusso del codice di autorizzazione funziona sia con i clienti riservati che con i clienti pubblici.

Client riservati

Clienti pubblici

I client pubblici non dispongono di credenziali, ma di un identificativo client. Nel flusso Codice autorizzazione sono disponibili due passi. Le richieste comportano una richiesta GET basata su browser, quindi una richiesta POST multicanale per ottenere il token di accesso.

1. Richiedere il codice di autorizzazione.

   Esempio di richiesta

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

   Esempio di risposta

   Nota
   
   Questi esempi di richiesta e risposta sono simili alle richieste e alle risposte del client riservato discusse in precedenza.

   https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

2. Richiedere il token.

   Esempio di richiesta

   Nota
   
   Questa richiesta è diversa dalla richiesta del client riservato in cui l'ID client e il segreto client sono specificati nell'intestazione dell'autenticazione di base. Nel flusso client pubblico non è presente alcuna intestazione di autenticazione Basic. L'ID client è specificato come parte del payload della richiesta.

      curl -i
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'   
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-code>&reidrect_uri=<client-redirect-uri>&client_id=<client-id>'

   Esempio di risposta

   {
   "access_token":"eyJ4NXQjUzI1???.xhtnbw",
   "token_type":"Bearer",
   "expires_in":27261,
   "id_token":"eyJ4NXQjUzI1???.._XLqUw"
   }
   

Utilizzare il flusso implicito quando è stato implementato un client basato su browser utilizzando un linguaggio di script come JavaScript. Il token di accesso e il token ID vengono restituiti direttamente al client, che può esporre questi token all'utente e alle applicazioni che hanno accesso all'agente utente dell'utente (ad esempio un browser Web).

Con il flusso implicito sono supportati i seguenti valori response_type:

Recupero di un token ID

Recupero di un token di accesso

Nel flusso implicito sono disponibili tre passi per ottenere un token di accesso:

1. Richiedere il token di accesso.

   Esempio di richiesta

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile

2. L'utente esegue il login e fornisce il consenso (in base agli ambiti richiesti).

3. Risposta con token di accesso

   Esempio di risposta

   Nota
   
   Tutti i parametri di risposta vengono aggiunti al componente frammento dell'URI di reindirizzamento.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1...4WGvJQ&token_type=Bearer&expires_in=3600

Recupero di un token ID e di un token di accesso

Utilizzare il flusso ibrido quando si desidera ottenere i token separatamente sia dal canale anteriore che dal canale posteriore. Ad esempio, si dispone di un componente del browser come JavaScript e di un componente del server backend come Node.js. Il componente browser ottiene il codice di autorizzazione e il token ID e può quindi personalizzare il contenuto dell'interfaccia utente. Il componente backend ottiene il token di accesso per eseguire chiamate API business.

I clienti devono supportare sia richieste e risposte basate su browser sia richieste e risposte programmatiche/back-channel per utilizzare il flusso ibrido. Il flusso ibrido funziona sia con i clienti riservati che con i clienti pubblici. Con il flusso ibrido sono supportati i seguenti valori response_type:

Recupero di un token ID

Recupero di un token di accesso

Nel flusso ibrido sono disponibili quattro passaggi per ottenere il codice di autorizzazione e il token di accesso:

1. Richiedere il codice di autorizzazione e il token di accesso.

   Esempio di richiesta

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test

2. L'utente esegue il login e fornisce il consenso (in base agli ambiti richiesti).

3. Risposta con token ID e codice di autorizzazione.

   Esempio di risposta

   Nota
   
   Tutti i parametri di risposta vengono aggiunti al componente frammento dell'URI di reindirizzamento.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1....Pudw9A&code=AQIDBAU6d6Ae....F9NCA=&token_type=Bearer&expires_in=3600

4. L'applicazione client utilizza il codice di autorizzazione ed effettua una richiesta di canale secondario per ottenere un nuovo token di accesso.

   Esempio di richiesta

      curl -i
     -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
      -H 'Accept: */*''
      --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAU6d6Ae...NCA%3D'

   Esempio di risposta

   {
   "access_token":"eyJ4NXQjUzI1....Tgs9LA",
   "token_type":"Bearer",
   "expires_in":3600
   }

Recupero di un token ID e di un token di accesso

È possibile utilizzare OpenID Connect per le richieste di logout basate su browser.

È possibile richiedere un logout mediante OpenID Connect in due modi: