IdentityServer4. Concetti fondamentali. OpenID Connect, OAuth 2.0 e JWT

Con questo post voglio aprire una serie di articoli dedicati a IdentityServer4. Iniziamo dai concetti fondamentali.

Il protocollo di autenticazione più promettente al momento è OpenID Connect, mentre il protocollo di autorizzazione (accesso) è OAuth 2.0. IdentityServer4 implementa questi due protocolli. È ottimizzato per risolvere problematiche tipiche di sicurezza.

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

JWT (JSON Web Token) è uno standard web che definisce il modo di trasmettere dati sull'utente in formato JSON in forma crittografata.

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

Diamo un'occhiata al diagramma di accesso alla risorsa protetta e analizziamo i passaggi principali e la terminologia accettata:

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

2. L'utente permette all'applicazione client di autorizzarsi a suo nome, ad esempio, inserendo il nome utente e la password. Nome utente e password fungeranno da autorizzazione per l'applicazione client. Utente (proprietario della risorsa) — programma o persona che può concedere accesso a risorse protette, ad esempio, inserendo nome utente (username) e password (password);

3. L'applicazione client richiede un token di accesso a IdentityServer4 fornendo informazioni su se stessa (client_id, client_secret), fornendo l'autorizzazione per l'autorizzazione da parte dell'utente (username, password) e fornendo grant_type e scope. Quindi, 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 autentica non solo l'utente, ma anche l'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'app cliente e viene utilizzato per autenticare l'app cliente su IdentityServer4. Il segreto del cliente deve essere noto solo all'applicazione e all'API. Da quanto sopra, concludiamo che IdentityServer4 deve conoscere i suoi clienti.

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

5. L'app cliente richiede i dati a 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, 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

Ai clienti registrati è consentito richiedere IdentityServer4 -token, IdentityServer4 identity-token, access-token e aggiorna-token.

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

Introduciamo altri due concetti:

Url del server di autenticazione — endpoint per ottenere il token di accesso. Tutte le richieste per fornire e rinnovare i token di accesso saranno indirizzate a questo URL.

Url delle risorse — l'URL della risorsa protetta a cui deve essere effettuato l'accesso, 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 la seguente intestazione

'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 esaminati sopra. Vediamo gli altri parametri:

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

Protocollo OAuth 2.0 determina i seguenti tipi di grant che richiedono una interazione obbligatoria con gli utenti:

• codice di autorizzazione (authorization code). È uno dei tipi di autorizzazione più diffusi, poiché si adatta bene alle applicazioni server-side, dove il codice sorgente dell'applicazione e il segreto del cliente non sono accessibili a terzi;
• implicito (implicit). Il tipo di autorizzazione implicita è utilizzato da applicazioni mobili e web, dove la riservatezza del segreto del cliente 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 è degna di fiducia e l'utente è a proprio agio nell'inserire le proprie credenziali. Questo tipo di autorizzazione deve essere impiegato solo quando non sono disponibili altre opzioni. È particolarmente utile per i clienti aziendali che, all'interno del proprio sistema, hanno già utilizzato le credenziali dell'utente e desiderano passare a OAuth 2.0.
• credenziali del cliente. Vengono utilizzate quando l'applicazione accede all'API. Può rivelarsi 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.

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. Cioè, possiamo raggruppare più servizi sotto un unico ambito e, se un cliente ottiene una chiave di accesso per questo ambito, ha accesso a tutti questi servizi. Inoltre, l'ambito può essere utilizzato per limitare i diritti di autorizzazione (ad esempio, accesso in sola lettura o scrittura).

Fonte: habr.com