IdentityServer4. Concetti di base. OpenID Connect, OAuth 2.0 e JWT

Con questo post voglio aprire una serie di articoli dedicati a IdentityServer4. Iniziamo con i concetti di base.

Attualmente, il protocollo di autenticazione più promettente è OpenID Connect, mentre il protocollo di autorizzazione (per concessione di accesso) è OAuth 2.0. IdentityServer4 implementa questi due protocolli. È ottimizzato per risolvere problemi tipici di sicurezza.

OpenID Connect — è un protocollo e uno standard di autenticazione, non fornisce accesso alle risorse (Web API), ma poiché è stato sviluppato sopra il protocollo di autorizzazione OAuth 2.0, consente di ottenere i parametri del profilo utente come se si fosse ottenuto accesso alla risorsa UserInfo.

JWT (JSON Web Token) è uno standard web che definisce il modo di trasmettere i dati dell'utente in formato JSON in modo crittografato.

OAuth 2.0 (RFC 6749) — è un protocollo e uno standard di autorizzazione. Permette alle applicazioni di accedere a risorse protette, come le Web API.

Esaminiamo il diagramma di accesso a una risorsa protetta e compiamo i principali passaggi e la terminologia accettata:

1. Il client richiede all'utente il permesso di eseguire l'autenticazione per suo conto. Cliente — è un'applicazione client che accede alle risorse protette a nome del proprietario delle risorse. La risorsa — sono tutti i nostri servizi protetti Web API.

2. L'utente consente all'applicazione client di eseguire l'autenticazione per suo conto, ad esempio inserendo nome utente e password. Il nome utente e la password fungeranno da concessione di autorizzazione per l'applicazione client. Utente (proprietario della risorsa) — è il programma o l'individuo che può concedere accesso a risorse protette, ad esempio, tramite l'inserimento del nome utente (username) e della password (password);

3. L'applicazione client richiede un token di accesso a IdentityServer4 fornendo informazioni su se stessa (client_id, client_secret), concedendo l'autorizzazione per l'autenticazione da parte dell'utente (username, password) e fornendo grant_type e scope. Poi il server di autorizzazione verifica l'autenticità del client e le credenziali del proprietario della risorsa (nome utente e password).

   Il protocollo OAuth 2.0 esegue l'autenticazione non solo dell'utente, ma anche dell'applicazione client che accede alle risorse. A tal fine, il protocollo prevede parametri come client_id e client_secret.
   client_id — è l'identificativo dell'applicazione client, utilizzato IdentityServer4 per cercare informazioni sul client.
   client_secret è l'equivalente della password per l'applicazione client e viene utilizzato per l'autenticazione dell'applicazione client su IdentityServer4. Il segreto del cliente deve essere conosciuto solo dall'applicazione e dall'API. Da quanto detto in precedenza, possiamo concludere che IdentityServer4 deve sapere dei suoi clienti.

4. Se l'autenticità dell'applicazione è confermata e il permesso per l'autorizzazione è valido, IdentiryServer4 crea access-token (token di accesso) per l'applicazione e un optional refresh token (refresh-token). Il processo di autorizzazione è completato. Se la richiesta è invalida o non autorizzata, il server di autorizzazione restituisce un codice con il relativo messaggio di errore.

5. L'applicazione client richiede dati da un API Web protetta, fornendo nel contempo il token di accesso per l'autorizzazione. Se il codice di risposta del server delle risorse 401, 403 o 498, allora il token di accesso utilizzato per l'autenticazione è non valido o scaduto.

6. Se il token è valido, Web API fornisce i dati all'applicazione.

Tipi di token

I clienti registrati in IdentityServer4 possono richiedere IdentityServer4 identity-token, access-token e aggiorna-token.

• identity-token (token di identità) — è il risultato del processo di autenticazione. Contiene l'identificativo dell'utente e informazioni su come e quando l'utente completa l'autenticazione. Può essere esteso con i propri dati.
• access-token (token di accesso) — viene passato all'API protetta e utilizzato per l'autorizzazione (permesso di accesso) ai propri dati.
• refresh-token (token di aggiornamento) — è un parametro opzionale che il server di autorizzazione può restituire in risposta alla richiesta di un token di accesso.

Introduciamo altri due concetti:

Authenticatation Server Url — è l'endpoint per ottenere il token di accesso. Tutte le richieste per l'emissione e il rinnovo dei token di accesso verranno indirizzate a questo URL.

Resource Url — è l'URL della risorsa protetta alla quale bisogna accedere, passando il token di accesso nell'intestazione di autorizzazione.

Richiesta di token di accesso

Per richiedere il token di accesso, il client effettua POST una richiesta all'endpoint IdentityServer4 con il seguente header

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

e passando i seguenti parametri:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id e client_secret sono stati discussi sopra. Analizziamo gli altri parametri:

grant_type — tipo di grant o tipo di autorizzazione. Il tipo di autorizzazione dipende dal metodo di richiesta di autorizzazione utilizzato dall'applicazione e dai tipi di autorizzazione supportati dall'API. Nel nostro caso avrà il valore password, che secondo la specifica OAuth 2.0 corrisponde al grant delle credenziali di accesso del proprietario della risorsa (autorizzazione tramite nome utente e password).

Protocollo OAuth 2.0 definisce i seguenti tipi di grant che richiedono l'interazione obbligatoria con gli utenti:

• codice di autorizzazione (authorization code). È uno dei tipi di autorizzazione più comuni, poiché si adatta bene alle applicazioni server-side, dove il codice sorgente dell'applicazione e il segreto del client non sono accessibili a terzi;
• implicito (implicit). Il tipo di autorizzazione implicito è utilizzato da applicazioni mobili e web, dove la riservatezza del segreto del client non può essere garantita;

E i tipi di grant che possono essere eseguiti senza interazione interattiva con gli utenti:

• credenziali del proprietario della risorsa (resource owner). Questo tipo di autorizzazione deve essere utilizzato solo quando l'applicazione client gode della fiducia dell'utente e l'utente è a proprio agio nell'inserire il proprio nome utente e la propria password. Questo tipo di autorizzazione dovrebbe essere utilizzato solo quando non ci sono altre opzioni disponibili. Questo tipo di autorizzazione è comodo per i clienti aziendali che all'interno del loro sistema hanno già utilizzato le credenziali dell'utente e desiderano passare a OAuth 2.0.
• credenziali del client. Sono utilizzate quando l'applicazione accede all'API. Questo può essere utile, ad esempio, quando l'applicazione desidera aggiornare le proprie informazioni di registrazione sul servizio o l'URI di reindirizzamento, oppure accedere ad altre informazioni memorizzate nell'account dell'applicazione sul servizio, tramite l'API del servizio.

scope — è un parametro facoltativo. Definisce l'ambito di visibilità. Il token di accesso restituito dal server garantirà l'accesso solo ai servizi che rientrano in questo ambito. In altre parole, possiamo raggruppare diversi servizi sotto un unico scope e se il cliente riceve una chiave di accesso per questo scope, ottiene accesso a tutti questi servizi. Inoltre, lo scope può essere utilizzato per limitare i diritti di autorizzazione (ad esempio, accesso in lettura o scrittura).

Fonte: habr.com