Uso di OpenID Connect per estendere OAuth 2.0

Un token di identità è un token autonomo protetto dall'integrità (in formato JWT (JSON Web Token) definito nello standard OpenID Connect contenente le richieste relative all'utente finale. Il token di identità è l'estensione primaria che OpenID Connect crea in 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 in Base64URL e separate da punti.

OpenID Connect 1.0 è un livello di identità semplice al di sopra del 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 quello REST. OpenID Connect consente ai client di tutti i tipi, inclusi i 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é convalidiamo i token? Quando l'applicazione Web controlla direttamente le credenziali, verifica che il nome utente e la password presentati corrispondano a ciò che si mantiene. Quando si utilizza un'identità basata su richieste di rimborso, tale mansione viene affidata 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.

OpenID Documento di ricerca automatica

Il protocollo OpenID Connect 1.0 è un livello di identità semplice al di sopra del 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 facilitare la ricerca automatica degli endpoint da utilizzare, OpenID Connect consente di utilizzare un documento di ricerca automatica, ovvero 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, informazioni utente e chiavi pubbliche. È possibile recuperare il documento di ricerca automatica per il servizio OpenID Connect del dominio di Identity IAM dal seguente indirizzo: 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 informazioni sul profilo, preferenze e altre informazioni specifiche dell'utente.

Il profilo OpenID Connect è composto da due componenti:

• Richieste che descrivono l'utente

• Endpoint UserInfo che fornisce un meccanismo per recuperare queste richieste

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

Richieste di risarcimento profilo utente

L'endpoint UserInfo fornisce un set di richieste in base agli 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 di esempio

Dopo che l'applicazione client ha autenticato un utente e ha il 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 di 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 Codice di autorizzazione restituisce un codice di autorizzazione al client, che può quindi scambiare direttamente il codice per un token ID e un token di accesso.

Ciò offre il vantaggio di non esporre alcun token all'agente utente (ad esempio un browser Web) ed 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 Codice di autorizzazione funziona sia con i clienti riservati che con i clienti pubblici.

Clienti riservati

Clienti pubblici

I client pubblici non dispongono di credenziali, ma di un identificativo client. Il flusso Codice autorizzazione prevede due passi. Le richieste riguardano una richiesta GET basata su browser e quindi una richiesta POST back-channel 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 alla richiesta 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 Client riservato in cui l'ID client e il segreto client sono specificati nell'intestazione Autenticazione di base. Nel flusso client pubblico non è presente alcuna intestazione di autenticazione di base. L'ID client viene 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, ad esempio 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'user agent dell'utente (ad esempio un browser Web).

I seguenti valori response_type sono supportati con il flusso implicito:

Come ottenere un token ID

Come ottenere un token di accesso

Il flusso implicito prevede 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 effettua l'accesso 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

Come ottenere un token ID e 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 del browser ottiene il codice di autorizzazione e il token ID e quindi può personalizzare il contenuto dell'interfaccia utente. Il componente backend ottiene il token di accesso per eseguire le chiamate API business.

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

Come ottenere un token ID

Come ottenere un token di accesso

Il flusso ibrido prevede quattro passi 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 effettua l'accesso 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
   }

Come ottenere un token ID e un token di accesso

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

Sono disponibili due modi per richiedere il logout mediante OpenID Connect: