Nota di traduzione.: In questo straordinario materiale della società 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 gli "utenti normali" di popolari applicazioni web, che probabilmente scambiano anche dati sensibili con altri servizi.
Nell'"era della pietra" di Internet, era facile condividere informazioni tra i servizi. Bastava fornire il proprio username e password da un servizio all'altro, affinché potesse accedere al proprio account e ottenere qualsiasi informazione necessaria.
«Fornisci il tuo conto bancario». — «Promettiamo che la password e i soldi saranno al sicuro. Proprio sinceramente!» *ahi-ahi*
Terribile! Nessuno dovrebbe mai chiedere all'utente di condividere il proprio username e password, le sue credenziali, con un altro servizio. Non c'è alcuna garanzia che l'organizzazione dietro quel servizio custodisca i dati in modo sicuro e non raccolga più informazioni personali di quanto necessario. Può sembrare assurdo, ma alcune applicazioni usano ancora pratiche simili!
Oggi esiste uno standard unico che consente a un servizio di utilizzare in modo sicuro i dati di un altro. Sfortunatamente, tali standard utilizzano una miriade di gerghi e termini che ne complicano la comprensione. L'obiettivo di questo materiale è spiegare, attraverso semplici illustrazioni, come funzionano (Pensate che i miei disegni assomiglino ai pasticci di un bambino? Bene, pazienza!).
A proposito, questo tutorial è disponibile anche in formato video:
Dame e signori, ecco a voi: OAuth 2.0
è uno standard di sicurezza che consente a un'applicazione di ricevere il permesso di accedere alle informazioni di un'altra applicazione. La sequenza di azioni per concedere il permesso [permission] (o consenso [consent]) è spesso chiamata autorizzazione [authorization] o addirittura autorizzazione delegata [delegated authorization]. Con questo standard, permetti a un'applicazione di leggere dati o utilizzare funzioni di un'altra applicazione a tuo nome, senza dover rivelare la tua password. Fantastico!
Come esempio, immaginiamo che tu abbia scoperto un sito con il nome "Terribile calembour del giorno" [Terrible Pun of the Day] E avete deciso di registrarvi per ricevere ogni giorno giochi di parole sotto forma di messaggi di testo sul telefono. Il sito vi è piaciuto molto e avete deciso di condividerlo con tutti i vostri conoscenti. Del resto, i terribili giochi di parole piacciono a tutti, vero?
«Gioco di parole sfortunato del giorno: avete sentito parlare del ragazzo che ha perso la metà sinistra del corpo? Ora è sempre a destra!» (traduzione approssimativa, poiché nell'originale c'è un gioco di parole — nota del traduttore)
È chiaro che scrivere a ogni persona della lista di contatti non è un'opzione. E, se siete anche solo un po' simili a me, farete di tutto per evitare lavoro extra. Per fortuna, il Terrible Pun of the Day può invitare da solo tutti i vostri amici! È sufficiente dargli accesso all'e-mail dei contatti — il sito invierà automaticamente gli inviti (OAuth is the way)!
«Tutti amano i giochi di parole! — Vi siete già registrati? — Volete dare accesso al sito Terrible Pun of the Day alla lista dei contatti? — Grazie! Ora ogni giorno invieremo promemoria a tutti quelli che conoscete, fino alla fine dei tempi! Siete il migliore amico!»
- Scegli il tuo servizio di posta elettronica.
- Se necessario, visita il sito di posta e accedi al tuo account.
- Concedi al sito Terrible Pun of the Day accesso ai contatti.
- Torna al sito Terrible Pun of the Day.
Nel caso cambi idea, le applicazioni che utilizzano OAuth offrono anche un modo per revocare l'accesso. Decidendo che non vuoi più condividere i contatti con il Terrible Pun of the Day, puoi visitare il sito di posta e rimuovere il sito dei giochi di parole dall'elenco delle applicazioni autorizzate.
Flusso OAuth
Appena abbiamo attraversato quello che di solito viene chiamato flusso [flow] OAuth. Nel nostro esempio, questo flusso consiste in passaggi visibili, oltre a diversi passaggi invisibili, dove due servizi concordano su uno scambio sicuro di informazioni. Nell'esempio precedente con il 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, i tuoi dati e controlli tutte le azioni che possono essere eseguite sui tuoi account. - Cliente:
Un'applicazione (ad esempio, il servizio Terrible Pun of the Day) che desidera accedere o eseguire azioni per conto di Proprietario della Risorsal'utente. - Server di Autorizzazione:
Un'applicazione che conosce Proprietario della Risorsal'utente e per la quale Proprietario della Risorsal'utente ha già un account. - Server di Risorse:
Interfaccia di Programmazione dell'Applicazione (API) o servizio a cui Cliente si desidera accedere per conto di Proprietario della Risorsal'utente. - URI di Reindirizzamento:
Link a cui Server di Autorizzazione verrà reindirizzato Proprietario della Risorsal'utente dopo aver concesso l'autorizzazione Cliente. A volte è chiamato "URL di Ritorno" ("Callback URL"). - Tipo di Risposta:
Tipo di informazione che ci si aspetta di ricevere Cliente. Il più comune Tipo di Rispostatipo di risposta è un codice, cioè Cliente che si prevede di ricevere Codice di Autorizzazione. - Ambito:
Questa è una descrizione dettagliata delle autorizzazioni richieste Clientedall'utente, come l'accesso ai dati o l'esecuzione di determinate azioni. - Consenso:
Server di Autorizzazione chiede all'utente le autorizzazionirichieste Clientee informa Proprietario della Risorsal'utente se è disposto a fornire Clientele relative autorizzazioni. - Client ID:
Questa ID è utilizzata per identificare Clientel'utente presso Server di Autorizzazioneil server. - Client Secret:
Questa è una password nota solo a Clientel'utente e Server di Autorizzazioneal servizio. Permette loro di scambiarsi informazioni in modo riservato. - Codice di Autorizzazione:
Un codice temporaneo con una breve durata di validità che Cliente fornisce Server di Autorizzazionel'utente può scambiare per Token di Accesso. - Token di Accesso:
Una chiave che il cliente utilizzerà per comunicare con Server di Risorseil servizio. Una sorta di badge o key card, che fornisce Clienteall'utente autorizzazioni per richiedere dati o eseguire azioni su Server di Risorsedi lui per conto suo.
Nota: a volte il Server di Autorizzazione e il Server di Risorse sono lo stesso server. Tuttavia, in alcuni casi possono essere server diversi, anche non appartenenti alla stessa organizzazione. Ad esempio, il Server di Autorizzazione può essere un servizio di terze parti di cui si fida il Server di Risorse.
Ora che abbiamo appreso i concetti di base di OAuth 2.0, torniamo al nostro esempio e esaminiamo in dettaglio cosa accade nel flusso di OAuth.
- Tu, Proprietario della Risorsa, desideri dare accesso al servizio Terrible Pun of the Day (Clientel'utente) ai tuoi contatti, in modo che possa inviare inviti a tutti i tuoi amici.
- Cliente reindirizza il browser alla pagina Server di Autorizzazionedel servizio e include nella richiesta Client ID, URI di Reindirizzamento, Tipo di Risposta una o più le autorizzazioni autorizzazioni richieste.
- Server di Autorizzazione verifica la tua identità, richiedendo, se necessario, il login e la password.
- Server di Autorizzazione mostra un modulo Consenso (di conferma) con un elenco di tutte le le autorizzazioniautorizzazioni richieste Clientedal servizio. Accetti o rifiuti.
- Server di Autorizzazione ti reindirizza al sito Clientedel servizio, utilizzando URI di Reindirizzamento insieme a Codice di Autorizzazione un codice di autorizzazione.
- Cliente comunica direttamente con Server di Autorizzazioneil servizio (bypassing the browser Proprietario della Risorsadel servizio) e invia in modo sicuro. Client ID, Client Secret e Codice di Autorizzazione.
- Server di Autorizzazione controlla i dati e risponde con Token di Accessoun token di accesso.
- Ora Cliente può utilizzare Token di Accesso per inviare una richiesta a Server di Risorse con l'obiettivo di ottenere un elenco di contatti.
ID Client e Secret
Molto tempo prima che tu concedessi a Terrible Pun of the Day di accedere ai contatti, Client e Authorization Server avevano stabilito una relazione di lavoro. Authorization Server ha generato un Client ID e un Client Secret (a volte chiamati anche 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 implica che il Client Secret debba essere mantenuto riservato, affinché solo il Client e l'Authorization Server ne siano a conoscenza. Infatti, è con il suo aiuto che l'Authorization Server verifica l'autenticità del Client.
Ma non è tutto... Per favore, dai il benvenuto a OpenID Connect!
OAuth 2.0 è stato progettato solo per autorizzazione — 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 sul login e sul profilo dell'utente che ha effettuato l'accesso al suo account. L'organizzazione della sessione di login viene spesso definita autenticazione [authentication], e le informazioni sull'utente che ha effettuato l'accesso (cioè su Proprietario della Risorsaun'identità), — dati personali [identity]. Se l'Authorization Server supporta OIDC, a volte viene chiamato fornitore di identità [identity provider], poiché fornisce Clienteall'utente informazioni su Proprietario della Risorsail server.
OpenID Connect consente di implementare scenari in cui un'unica login può essere utilizzata in più applicazioni; questo approccio è anche noto come single sign-on (SSO). Ad esempio, un'app può supportare l'integrazione SSO con social network, come Facebook o Twitter, consentendo agli utenti di utilizzare un account che già possiedono e preferiscono usare.
Il flusso di OpenID Connect appare identico a quello di OAuth. L'unica differenza è che nella richiesta iniziale lo scope specifico utilizzato è openid, — e Cliente ultimamente riceve sia Token di Accesso, sia un ID Token.
Proprio come nel flusso OAuth, Token di Accesso in OpenID Connect — è un valore non comprensibile Clienteper l'utente. Dal punto di vista Clientedell'utente Token di Accesso rappresenta una stringa di caratteri che viene trasmessa con ogni richiesta al Server di Risorseserver, che determina se il token è valido. un ID Token rappresenta qualcosa di totalmente diverso.
ID Token è un JWT
un ID Token è una stringa di caratteri formattata in modo specifico, nota come JSON Web Token o JWT (a volte i token JWT sono pronunciati «jots»). Agli osservatori esterni, JWT potrebbe sembrare un linguaggio incomprensibile, ma Cliente può estrarre diverse informazioni da un JWT, come ID, nome utente, orario di accesso all'account, scadenza un ID Token, presenze di tentativi di manomissione del JWT. I dati all'interno un ID Tokensono chiamati richieste [claims].
Nel caso di OIDC esiste anche un modo standard attraverso il quale Cliente può richiedere ulteriori informazioni sull'identità [identity] di Server di Autorizzazione, come l'indirizzo email, utilizzando Token di Accesso.
Ulteriori dettagli su OAuth e OIDC
Quindi, abbiamo esaminato brevemente i principi di funzionamento di OAuth e OIDC. Sei pronto a scavare più a fondo? Ecco risorse aggiuntive che ti aiuteranno a saperne di più su OAuth 2.0 e OpenID Connect:
Come sempre, non esitare a commentare. Per rimanere aggiornato sulle nostre ultime novità, iscriviti a e Okta Developer Company!
P.S. dal traduttore
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
