Nota del traduttore.: In questo fantastico articolo di Okta, vengono spiegati in modo semplice e chiaro i principi di funzionamento di OAuth e OIDC (OpenID Connect). Queste informazioni saranno utili per sviluppatori, amministratori di sistema e persino per 'utenti comuni' di popolari applicazioni web, che probabilmente scambiano anche dati sensibili con altri servizi.
Nell'età della pietra di Internet, condividere informazioni tra i servizi era semplice. Bastava fornire il proprio nome utente e password da un servizio all'altro affinché quest'ultimo accedesse al proprio account e ottenesse qualsiasi informazione necessaria.
«Fornisci il tuo conto bancario». — «Promettiamo che con la password e i soldi andrà tutto bene. Proprio onestamente!» *ihi-ihi*
Terribile! Nessuno dovrebbe mai e poi mai chiedere a un utente di condividere il proprio nome utente e password, le sue credenziali, con un altro servizio. Non c'è alcuna garanzia che l'organizzazione dietro questo servizio manterrà i dati al sicuro e non raccoglierà più informazioni personali del necessario. Può sembrare folle, ma alcune applicazioni continuano a utilizzare pratiche simili!
Oggi esiste uno standard unico che consente a un servizio di utilizzare in sicurezza i dati di un altro. Sfortunatamente, tali standard usano un sacco di gergo e terminologie, rendendo difficile la loro comprensione. L'obiettivo di questo materiale è spiegare come funzionano, attraverso semplici illustrazioni (Pensate che i miei disegni sembrino scarabocchi di bambini? E va bene!).
A proposito, questa guida è disponibile anche in formato video:
Signore e signori, ecco a voi: OAuth 2.0
— è uno standard di sicurezza che consente a un'applicazione di ottenere autorizzazione per accedere alle informazioni in un'altra applicazione. La sequenza di operazioni per fornire l'autorizzazione [permission] (o consenso [consent]) è spesso chiamata autorizzazione [authorization] o addirittura autorizzazione delegata [delegated authorization]Con questo standard permetti all'app di leggere i dati o utilizzare le funzioni di un'altra app a tuo nome, senza rivelare la tua password. Fantastico!
Immagina di aver trovato un sito chiamato "Terribile Calembour del Giorno" [Terrible Pun of the Day] e hai deciso di iscriverti per ricevere quotidianamente calembour via messaggi di testo sul tuo telefono. Ti è piaciuto molto il sito, e hai deciso di condividerlo con tutti i tuoi amici. Dopotutto, a tutti piacciono i calembour terribili, vero?
"Terribile calembour del giorno: Hai sentito parlare del tipo che ha perso la metà sinistra del corpo? Ora ha sempre ragione!" (traduzione approssimativa, poiché nell'originale c'è un gioco di parole — nota del traduttore)
È chiaro che scrivere a ciascuna persona della tua lista di contatti non è un'opzione. E se sei almeno un po' simile a me, farai di tutto per evitare lavoro extra. Fortunatamente, il Terrible Pun of the Day può invitare automaticamente tutti i tuoi amici! Basta dare accesso alla sua email — il sito invierà automaticamente gli inviti (OAuth è fantastico)!
«Tutti amano i giochi di parole! — Sei già loggato? — Vuoi consentire al sito Terrible Pun of the Day di accedere alla tua lista di contatti? — Grazie! Ora ti invieremo ogni giorno dei promemoria a tutti quelli che conosci, fino alla fine dei tempi! Sei il miglior amico!»
- Scegli il tuo servizio di posta elettronica.
- Se necessario, vai sul sito di posta e accedi al tuo account.
- Concedi al sito Terrible Pun of the Day l'accesso ai contatti.
- Torna sul sito Terrible Pun of the Day.
Se cambi idea, le applicazioni che utilizzano OAuth offrono anche un modo per revocare l'accesso. Se decidi di non voler più condividere i tuoi contatti con Terrible Pun of the Day, puoi andare sul sito di posta e rimuovere il sito di giochi di parole dall'elenco delle applicazioni autorizzate.
Flusso OAuth
Appena abbiamo attraversato ciò che di solito viene chiamato flusso [flow] OAuth. Nel nostro esempio, questo flusso è composto da passi visibili, così come da alcuni passi invisibili, durante i quali i due servizi concordano su uno scambio sicuro di informazioni. Nell'esempio precedente di Terrible Pun of the Day, viene utilizzato il flusso OAuth 2.0 più comune, noto come flusso «con codice di autorizzazione». [«authorization code» flow].
Prima di addentrarci nei dettagli del funzionamento di OAuth, parliamo del significato di alcuni termini:
- Proprietario della Risorsa:
Sei tu! Possiedi le tue credenziali e i tuoi dati, e hai il controllo su tutte le azioni che possono essere effettuate con i tuoi account. - Client:
Un'applicazione (ad esempio, il servizio Terrible Pun of the Day) che desidera accedere o compiere determinate azioni per conto di Proprietario della Risorsal'utente. - Server di Autorizzazione:
L'applicazione che conosce Proprietario della Risorsal'utente e in cui Proprietario della Risorsal'utente ha già un account. - Server di Risorse:
Un'API (interfaccia di programmazione delle applicazioni) o servizio di cui Client vuole avvalersi per conto di Proprietario della Risorsal'utente. - URI di Redirect:
Il link a cui Server di Autorizzazione verrà reindirizzato Proprietario della Risorsal'utente dopo aver concesso l'autorizzazione Clientall'applicazione. A volte è chiamato "Return URL" ("Callback URL"). - Tipo di Risposta:
Il tipo di informazione che ci si aspetta di ricevere Client. Il più comune Tipo di Rispostaè il codice, cioè Client si prevede di ricevere Codice di Autorizzazione. - Ambito:
Questa è una descrizione dettagliata dei permessi richiesti Clientdall'utente, come l'accesso ai dati o l'esecuzione di determinate azioni. - Consenso:
Server di Autorizzazione richiede Ambiti, richiesti Clientdall'utente, e chiede a Proprietario della Risorsal'utente se è disposto a fornire Clientall'applicazione i permessi corrispondenti. - ID del Client:
Questo ID viene utilizzato per l'identificazione Client‘a su Server di Autorizzazione‘e. - Client Secret:
Questa è una password nota solo a Client‘e e Server di Autorizzazione‘e. Permette loro di scambiare informazioni in modo riservato. - Codice di Autorizzazione:
Codice temporaneo con una breve durata di validità che Client offre Server di Autorizzazione‘e in cambio di Access Token. - Access Token:
Chiave che il cliente utilizzerà per comunicare con Server di Risorse‘e. Una sorta di badge o chiave che fornisce Client‘e autorizzazione per richiedere dati o eseguire azioni su Server di Risorse‘e a nome vostro.
Nota: a volte il Authorization Server e il Resource Server sono lo stesso server. Tuttavia, in alcuni casi possono essere server diversi, che non appartengono nemmeno alla stessa organizzazione. Ad esempio, l'Authorization Server potrebbe essere un servizio di terze parti di fiducia per il Resource Server.
Ora che abbiamo esaminato i concetti principali dell'OAuth 2.0, torniamo al nostro esempio e vediamo in dettaglio cosa succede nel flusso OAuth.
- Tu, Proprietario della Risorsa, desideri fornire al servizio Terrible Pun of the Day (Client‘e) accesso ai tuoi contatti, in modo che possa inviare inviti a tutti i tuoi amici.
- Client reindirizza il browser alla pagina Server di Autorizzazione‘e e include nella richiesta ID del Client, URI di Redirect, Tipo di Risposta e uno o più Ambiti (permessi) di cui ha bisogno.
- Server di Autorizzazione controlla se è necessario richiedere nome utente e password.
- Server di Autorizzazione visualizza il modulo Consenso (di conferma) con l'elenco di tutti Ambiti, richiesti Clientda ‘. Accetti o rifiuti.
- Server di Autorizzazione ti reindirizza al sito di Clientutilizzando URI di Redirect insieme a Codice di Autorizzazione (codice di autorizzazione).
- Client si collega direttamente a Server di Autorizzazione‘ (saltando il browser Proprietario della Risorsa‘) e invia in modo sicuro ID del Client, Client Secret e Codice di Autorizzazione.
- Server di Autorizzazione controlla i dati e risponde con Access Token‘ (token di accesso).
- Ora Client può utilizzare Access Token per inviare una richiesta a Server di Risorse per ottenere un elenco di contatti.
Client ID e Secret
Molto tempo prima che tu permetta a Terrible Pun of the Day di accedere ai contatti, il Client e il Server di Autorizzazione hanno stabilito una relazione di lavoro. Il Server di Autorizzazione ha generato il Client ID e il Client Secret (a volte chiamati App ID e App Secret) e li ha inviati al Client per ulteriori interazioni nell'ambito di OAuth.
«— Ciao! Vorrei lavorare con te! — Nessun problema! Ecco il tuo Client ID e Secret!»
Il nome suggerisce che il Client Secret dovrebbe rimanere segreto, noto solo al Client e al Server di Autorizzazione. Infatti, è proprio grazie a lui che il Server di Autorizzazione verifica l'autenticità del Client.
Ma non è tutto… Vi prego di dare il benvenuto a OpenID Connect!
OAuth 2.0 è stato progettato esclusivamente per autenticazione — per fornire accesso ai dati e alle funzionalità da un'applicazione a un'altra. (OIDC) è uno strato sottile sopra OAuth 2.0, che aggiunge informazioni di accesso e profilo dell'utente che ha effettuato il login. Il processo di login è spesso chiamato autenticazione [authentication], e le informazioni sull'utente che ha effettuato l'accesso (ovvero Proprietario della Risorsa‘è), — dati personali [identity]. Se il Server di Autorizzazione supporta OIDC, a volte è chiamato fornitore di identità [identity provider], poiché fornisce Client‘a informazioni su Proprietario della Risorsa‘e.
OpenID Connect consente di implementare scenari in cui un'unica autenticazione può essere utilizzata in diverse applicazioni, — questo approccio è anche noto come single sign-on (SSO). Ad esempio, un'applicazione può supportare l'integrazione SSO con i social network come Facebook o Twitter, permettendo agli utenti di utilizzare un account che già possiedono e che preferiscono utilizzare.
Il flusso (flow) di OpenID Connect appare come nel caso di OAuth. L'unica differenza è che nella richiesta iniziale, l'ambito specifico utilizzato è openid, — e Client riceve infine come Access Token, sia ID Token.
Proprio come nel flusso OAuth, Access Token In OpenID Connect, there is a value that is not clear. ClientFrom the perspective of Clientit Access Token represents a string of characters that is sent with each request to Server di Risorsewhich determines whether the token is valid. ID Token is something entirely different.
ID Token is a JWT
ID Token which is a specially formatted string of characters known as JSON Web Token or JWT (sometimes JWT tokens are pronounced as 'jots'). To third-party observers, JWT may seem like incomprehensible gibberish, however, Client can extract various information from a JWT, such as ID, username, login time, expiration time ID Token, and flag attempts to tamper with the JWT. The data inside ID Tokenis referred to as claims [claims].
In the case of OIDC, there is also a standard way for Client to request additional identity information [identity] da Server di Autorizzazione, such as the email address, using Access Token.
More information about OAuth and OIDC
So, we have briefly outlined the principles of OAuth and OIDC. Ready to dig deeper? Here are additional resources to help you learn more about OAuth 2.0 and OpenID Connect:
Come al solito, non esitate a commentare. Per rimanere aggiornati sulle nostre ultime novità, iscrivetevi a e Okta per gli sviluppatori!
P.S. dal traduttore
Leggete anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
