🥇Una guida illustrata a OAuth e OpenID Connect

Nota. trad.: Questo fantastico articolo di Okta spiega come funzionano OAuth e OIDC (OpenID Connect) in modo semplice e chiaro. Questa conoscenza sarà utile a sviluppatori, amministratori di sistema e persino "utenti regolari" di applicazioni Web popolari, che molto probabilmente scambiano anche dati riservati con altri servizi.

Nell'età della pietra di Internet, condividere le informazioni tra i servizi era facile. Hai semplicemente fornito login e password da un servizio all'altro, in modo che entrasse nel tuo account e ricevesse tutte le informazioni di cui aveva bisogno.

"Dammi il tuo conto in banca." “Promettiamo che andrà tutto bene con la password e il denaro. Questo è onesto, onesto!" *ih ih*

Orrore! Nessuno dovrebbe mai richiedere a un utente di condividere un nome utente e una password, credenziali, con un altro servizio. Non vi è 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 app usano ancora questa pratica!

Oggi esiste un unico standard che consente a un servizio di utilizzare in modo sicuro i dati di un altro. Sfortunatamente, tali standard usano molto gergo e termini, il che ne complica la comprensione. Lo scopo di questo materiale è spiegare come funzionano usando semplici illustrazioni (Pensi che i miei disegni assomiglino alle imbrattature dei bambini? Vabbè!).

A proposito, questa guida è disponibile anche in formato video:

Signore e signori, benvenuti: OAuth 2.0

OAuth2.0 è uno standard di sicurezza che consente a un'applicazione di ottenere l'autorizzazione ad accedere alle informazioni in un'altra applicazione. Sequenza di passaggi per il rilascio di un permesso [autorizzazione] (o consenso [consenso]) spesso chiamano autorizzazione [autorizzazione] o autorizzazione delegata [autorizzazione delegata]. Con questo standard, consenti a un'applicazione di leggere i dati o utilizzare le funzioni di un'altra applicazione per tuo conto senza fornirle la tua password. Classe!

Ad esempio, supponiamo che tu scopra un sito chiamato "Unlucky Pun of the Day" [Terribile gioco di parole del giorno] e ha deciso di registrarsi per ricevere giochi di parole giornalieri sotto forma di messaggi di testo sul telefono. Ti è piaciuto molto il sito e hai deciso di condividerlo con tutti i tuoi amici. Dopotutto, a tutti piacciono i giochi di parole raccapriccianti, giusto?

“Sfortunato gioco di parole del giorno: sentito parlare del ragazzo che ha perso la metà sinistra del suo corpo? Adesso ha sempre ragione!” (traduzione approssimativa, perché l'originale ha il suo gioco di parole - ca. trad.)

È chiaro che scrivere a ciascuna persona dall'elenco dei contatti non è un'opzione. E, se sei anche solo un po' come me, allora farai di tutto per evitare lavori inutili. Fortunatamente, Terrible Pun of the Day può invitare tutti i tuoi amici da solo! Per fare ciò, devi solo aprire l'accesso all'email dei tuoi contatti: il sito stesso invierà loro gli inviti (regole OAuth)!

“Tutti amano i giochi di parole! - Ha già effettuato il login? “Vuoi consentire al sito Web Terrible Pun of the Day di accedere al tuo elenco di contatti? - Grazie! D'ora in poi, invieremo promemoria ogni giorno a tutti quelli che conosci, fino alla fine dei tempi! Sei il migliore amico!"

Scegli il tuo servizio di posta elettronica.
Se necessario, vai al sito di posta e accedi al tuo account.
Concedi a Terrible Pun of the Day il permesso di accedere ai tuoi contatti.
Ritorna al sito del Terribile gioco di parole del giorno.

Nel caso in cui cambi idea, le applicazioni che utilizzano OAuth forniscono anche un modo per revocare l'accesso. Una volta deciso che non desideri più condividere i contatti con Terrible Pun of the Day, puoi andare al sito di posta e rimuovere il sito di gioco di parole dall'elenco delle applicazioni autorizzate.

Flusso OAuth

Abbiamo appena attraversato quello che di solito viene chiamato fluire [fluire] OAut. Nel nostro esempio, questo flusso è costituito da passaggi visibili, oltre a diversi passaggi invisibili, in cui due servizi concordano su uno scambio sicuro di informazioni. L'esempio precedente di Terrible Pun of the Day utilizza il flusso OAuth 2.0 più comune, noto come flusso "codice di autorizzazione". [flusso "codice di autorizzazione"].

Prima di entrare nei dettagli di come funziona OAuth, parliamo del significato di alcuni termini:

Proprietario delle risorse:

Sei tu! Possiedi le tue credenziali, i tuoi dati e controlli tutte le attività che possono essere eseguite sui tuoi account.
.:

Un'applicazione (ad esempio, il servizio Terrible Pun of the Day) che desidera accedere o eseguire determinate azioni per conto di Proprietario delle risorse'A.
Server di autorizzazione:

L'app che sa Proprietario delle risorse'a e in cui u Proprietario delle risorse'ho già un account.
Server di risorse:

Interfaccia di programmazione dell'applicazione (API) o servizio che . desidera utilizzare per conto di Proprietario delle risorse'A.
Reindirizzamento URI:

Il collegamento che Server di autorizzazione reindirizzerà Proprietario delle risorse'e dopo aver concesso il permesso .'A. A volte viene indicato come "URL di richiamata".
Tipo di risposta:

Il tipo di informazioni che si prevede di ricevere .. Il più comune Tipo di risposta'ohm è il codice, cioè . si aspetta di ricevere codice di autorizzazione.
Obbiettivo:

Questa è una descrizione dettagliata delle autorizzazioni necessarie .'y, come l'accesso ai dati o l'esecuzione di determinate azioni.
Consenso:

Server di autorizzazione берет Scopesrichiesto .'om, e chiede Proprietario delle risorse'a, è pronto a fornire .'avere le autorizzazioni appropriate.
ID cliente:

Questo ID viene utilizzato per identificare .'un su Server di autorizzazione'e.
Client Secret:

Questa è la password che è solo conosciuta .tu e Server di autorizzazione'A. Consente loro di condividere le informazioni in privato.
codice di autorizzazione:

Codice temporaneo con un breve periodo di validità, che . fornisce Server di autorizzazione'y in cambio di Token di accesso.
Token di accesso:

La chiave che il client utilizzerà per comunicare Server di risorse'om. Una sorta di badge o chiave magnetica che fornisce .'avere il permesso di richiedere dati o eseguire azioni su Server di risorse'e per tuo conto.

Nota: a volte il server di autorizzazione e il server di risorse sono lo stesso server. Tuttavia, in alcuni casi, questi possono essere server diversi, anche se non appartengono alla stessa organizzazione. Ad esempio, il server di autorizzazione potrebbe essere un servizio di terze parti ritenuto attendibile dal server di risorse.

Ora che abbiamo coperto i concetti fondamentali di OAuth 2.0, torniamo al nostro esempio e diamo un'occhiata più da vicino a ciò che accade nel flusso OAuth.

Voi, Proprietario delle risorse, vuoi fornire il servizio Il terribile gioco di parole del giorno (.y) accedere ai tuoi contatti in modo che possano inviare inviti a tutti i tuoi amici.
. reindirizza il browser alla pagina Server di autorizzazione'a e includi nella query ID cliente, Reindirizzamento URI, Tipo di risposta e uno o più Scopes (autorizzazioni) di cui ha bisogno.
Server di autorizzazione ti verifica, chiedendo un nome utente e una password se necessario.
Server di autorizzazione visualizza un modulo Consenso (conferme) con un elenco di tutti Scopesrichiesto .'om. Accetti o rifiuti.
Server di autorizzazione ti reindirizza al sito .'a, usando Reindirizzamento URI con codice di autorizzazione (codice di autorizzazione).
. comunica direttamente con Server di autorizzazione'ohm (bypassando il browser Proprietario delle risorse'a) e invia in modo sicuro ID cliente, Client Secret и codice di autorizzazione.
Server di autorizzazione controlla i dati e risponde con Token di accesso'om (token di accesso).
Ora . poter usare Token di accesso a cui inviare una richiesta Server di risorse per ottenere un elenco di contatti.

ID cliente e segreto

Molto prima che tu permettessi a Terrible Pun of the Day di accedere ai tuoi contatti, il client e il server di autorizzazione avevano stabilito un rapporto di lavoro. Il server di autorizzazione ha generato l'ID client e il segreto client (a volte chiamato App ID и Segreto dell'app) e li ha inviati al Cliente per un'ulteriore interazione all'interno di OAuth.

"- Ciao! Mi piacerebbe lavorare con te! - Certo, non è un problema! Ecco il tuo ID cliente e segreto!

Il nome implica che il segreto client deve essere tenuto segreto in modo che solo il client e il server di autorizzazione lo sappiano. Dopotutto, è con il suo aiuto che il server di autorizzazione conferma la verità del cliente.

Ma non è tutto... Diamo il benvenuto a OpenID Connect!

OAuth 2.0 è progettato solo per autorizzazione - fornire l'accesso a dati e funzioni da un'applicazione all'altra. OpenID Connect (OIDC) è uno strato sottile sopra OAuth 2.0 che aggiunge i dettagli di accesso e del profilo dell'utente che ha effettuato l'accesso all'account. L'organizzazione di una sessione di accesso viene spesso definita come autenticazione [autenticazione], e informazioni sull'utente che ha effettuato l'accesso al sistema (ad es Proprietario delle risorse'e), — dati personali [identità]. Se il server di autorizzazione supporta OIDC, a volte viene indicato come fornitore di dati personali [fornitore di identità]perché fornisce .'avere informazioni su Proprietario delle risorse'e.

OpenID Connect consente di implementare scenari in cui un singolo accesso può essere utilizzato in più applicazioni: questo approccio è noto anche come single sign-on (SO). Ad esempio, un'applicazione può supportare l'integrazione SSO con social network come Facebook o Twitter, consentendo agli utenti di utilizzare un account che già possiedono e che preferiscono utilizzare.

Il flusso (flusso) OpenID Connect ha lo stesso aspetto del caso di OAuth. L'unica differenza è che nella richiesta primaria l'ambito specifico utilizzato è openid, - UN . alla fine diventa come Token di accessoE Token ID.

Proprio come nel flusso OAuth, Token di accesso in OpenID Connect, questo è un valore che non è chiaro .'A. Dal punto di vista .‘а Token di accesso rappresenta una stringa di caratteri che viene passata insieme a ogni richiesta a Server di risorse'y, che determina se il token è valido. Token ID rappresenta una cosa completamente diversa.

Il token ID è un JWT

Token ID è una stringa di caratteri formattata in modo speciale nota come JSON Web Token o JWT (a volte i token JWT sono pronunciati come "jots"). Agli osservatori esterni, JWT può sembrare un incomprensibile incomprensibile, ma . può estrarre varie informazioni dal JWT, come ID, nome utente, ora di accesso, data di scadenza Token ID'a, la presenza di tentativi di interferire con il JWT. Dati all'interno Token ID'a sono chiamati applicazioni [affermazioni].

Nel caso di OIDC, esiste anche un modo standard con cui . può richiedere ulteriori informazioni sulla persona [identità] от Server di autorizzazione'a, ad esempio, un indirizzo e-mail che utilizza Token di accesso.

Ulteriori informazioni su OAuth e OIDC

Quindi, abbiamo brevemente esaminato come funzionano OAuth e OIDC. Pronto a scavare più a fondo? Ecco altre risorse per aiutarti a saperne di più su OAuth 2.0 e OpenID Connect:

Come sempre, non esitate a commentare. Per essere sempre aggiornato sulle nostre ultime novità, iscriviti a Twitter и YouTube Okta per gli sviluppatori!

Una guida illustrata a OAuth e OpenID Connect