OpenId Connect

in Architetture Software

OpenId Connect – Intro

Reading Time: 3 minutes

OpenId Connect è il nuovo standard per lo sviluppo di applicazioni single sign-on. Se abbiamo effettuato almeno una volta il login su un sito utilizzando l’opzione “Accedi con Google”, molto probabilmente abbiamo utilizzato OpenId.

Quando pensiamo ad un sistema di autenticazione (“chi è l’utente?”) e autorizzazione (“cosa può fare l’utente?”) il primo approccio potrebbe essere quello di creare gli utenti all’interno di un database locale ed impostare un meccanismo per la gestione dei ruoli. Questo approccio, sicuramente funzionante, può essere utilizzato in applicazioni medio-piccole, ma non per soluzioni enterprise.

La soluzione per la gestione di utenti e ruoli può essere quella di delegare il tutto ad un singolo servizio che è responsabile per entrambe le fasi: autenticazione e autorizzazione. Questo servizio, prende il nome di Identity Provider (ID Provider). Ovviamente al crescere della complessità del sistema il servizio può essere distribuito all’interno di più nodi, o all’interno del cloud.

Cos’è OpenID Connect

OAuth 2.0 è un framework che consente di impostare un meccanismo di autorizzazione. OpenId Connect consente di aggiungere un layer di autenticazione a Oauth 2.0.

In pratica, OpenId Connect definisce delle API REST che utilizzano un token in formato JSON (Json Web Token o JWT).

In OpenId Connect non viene specificato come l’utente dovrà essere essere autenticato con il provider esterno. Questo significa che l’autenticazione può avvenire tramite username/password, ma anche attraverso ulteriori meccanismi come ad esempio un codice. Anche il livello di sicurezza non viene definito e può essere modificato in base alla tipologia di applicazione.

Esempio di scenario

Supponiamo di voler realizzare un’applicazione che consenta di salvare i dati degli utenti all’interno di un database. Come requisito non tutti gli utenti potranno memorizzare i dati: dobbiamo introdurre un meccanismo di autorizzazione alla nostra applicazione. Inoltre, vogliamo consentire agli utenti la possibilità di effettuare il login tramite un servizio esterno, ad esempio Google. Per il nostro esempio, L’accesso tramite Google sarà ovviamente opzionale.

Una volta autenticato su Google, l’utente otterrà tre token:

  • Identity Token (ID token): il token piu’ importante perchè consente di identificare l’utente
  • Access Token: il token di accesso al provider per ottenere informazioni
  • Refresh Token: il token che dovrà essere utilizzato per effettuare il refresh dell’access token (che viene generato con una scadenza temporale)

Tipicamente le applicazioni sviluppate non salvano alcuna informazione relativa agli utenti, che saranno contenute all’interno del provider, quindi potranno essere estratte tramite ID Token oppure tramite ulteriori richieste effettuate tramite l’access token. Come descritto in precedenza il token viene generato utilizzando un JWT token che è di fatto basato sul formato JSON, firmato digitalmente e url-encodato tramite base64.

Nello scenario OIDC dobbiamo descrivere tre elementi:

  • il client, rappresentato dalla nostra applicazione, che prende il nome di Relying Party
  • Google che è il server di Autorizzazione esterno e denominato OpenID Provider
  • Gli utenti che dovranno utilizzare i due sistemi precedenti e definiti Resource Owners

Una volta definiti gli attori del nostro flusso, vediamo le modalità di funzionamento:

  1. l’utente vuole utilizzare la nostra applicazione pe la prima volta. L’applicazione esegue il redirect verso Google
  2. l’utente effettua il login su google con le proprie credenziali
  3. Google effettua l’autenticazione, creando una one-time password: una sorta di password temporanea
  4. Google effettua il redirect verso il la nostra applicazione, inviando i dati dell’utente e la password temporanea generata al punto precedente
  5. La nostra applicazione riceverà i dati e la one-time password ed eseguirà una chiamata REST verso Google per ottenere
    • Identity Token (ID token)
    • Access Token
    • Refresh Token
  6. A questo punto la nostra applicazione validerà l’ID Token (per controllare eventuali problemi durante la fase di trasporto) ed l’utente sarà effettivamente loggato. Utilizzando l’access token, la nostra applicazione potrà richiedere a Google ulteriori informazioni relative all’utente. Poichè l’access token normalmente ha una durata temporale, quando scadrà dovrà essere rigenerato mediante il refresh token.

In questo post ho introdotto le modalità di funzionamento di OpenId Connect, utilizzato per l’autenticazione degli utenti utilizzando OpenId Provider di terze parti.