Qual è la differenza tra OpenID e OAuth?

Sto davvero cercando di capire la differenza tra OpenID e OAuth? Forse sono due cose totalmente separate?

OpenID riguarda l'autenticazione (ad es. Dimostrare chi sei), OAuth riguarda l'autorizzazione (ad es. Per concedere l'accesso a funzionalità / dati / ecc. Senza dover gestire l'autenticazione originale).

OAuth potrebbe essere utilizzato in siti di partner esterni per consentire l'accesso ai dati protetti senza che questi debbano autenticare nuovamente un utente.

Il post sul blog " OpenID contro OAuth dal punto di vista dell'utente " ha un semplice confronto dei due dal punto di vista dell'utente e " OAuth-OpenID: abbai l'albero sbagliato se pensi che siano la stessa cosa " ha più informazioni a proposito.

Esistono tre modi per confrontare OAuth e OpenID:

1. Scopi

OpenID è stato creato per l'autenticazione federata, ovvero consentire a terzi di autenticare i tuoi utenti per te, utilizzando gli account che già possiedono . Il termine federato è fondamentale in questo caso perché il punto centrale di OpenID è che è possibile utilizzare qualsiasi provider (ad eccezione delle white list). Non è necessario preselezionare o negoziare un accordo con i fornitori per consentire agli utenti di utilizzare qualsiasi altro account in loro possesso.

OAuth è stato creato per rimuovere la necessità per gli utenti di condividere le proprie password con applicazioni di terze parti . In realtà è iniziato come un modo per risolvere un problema OpenID: se supporti OpenID sul tuo sito, non puoi utilizzare le credenziali HTTP Basic (nome utente e password) per fornire un'API perché gli utenti non hanno una password sul tuo sito.

Il problema è con questa separazione di OpenID per l'autenticazione e OAuth per l'autorizzazione è che entrambi i protocolli possono realizzare molte delle stesse cose. Ognuno di essi fornisce un diverso set di funzionalità che sono desiderate da diverse implementazioni ma sostanzialmente sono abbastanza intercambiabili. Alla base, entrambi i protocolli sono un metodo di verifica delle asserzioni (OpenID si limita all'asserzione "questo è chi sono io", mentre OAuth fornisce un "token di accesso" che può essere scambiato per qualsiasi asserzione supportata tramite un'API).

2. Caratteristiche

Entrambi i protocolli forniscono un modo per un sito di reindirizzare un utente da qualche altra parte e tornare con un'affermazione verificabile. OpenID fornisce un'asserzione di identità mentre OAuth è più generico sotto forma di token di accesso che può quindi essere utilizzato per "porre domande al provider OAuth" . Tuttavia, ciascuno di essi supporta funzionalità diverse:

OpenID - la caratteristica più importante di OpenID è il suo processo di scoperta. OpenID non richiede una codifica rigida per ogni provider che si desidera utilizzare in anticipo. Utilizzando il rilevamento, l'utente può scegliere qualsiasi provider di terze parti che desidera autenticare. Questa funzionalità di rilevamento ha anche causato la maggior parte dei problemi di OpenID perché il modo in cui è implementato è utilizzando gli URI HTTP come identificatori che la maggior parte degli utenti Web non riesce a ottenere. Altre caratteristiche OpenID ha il suo supporto per la registrazione client ad hoc che utilizza uno scambio DH, modalità immediata per l'esperienza dell'utente finale ottimizzata e un modo per verificare le asserzioni senza fare un altro viaggio di andata e ritorno al fornitore.

OAuth : la caratteristica più importante di OAuth è il token di accesso che fornisce un metodo duraturo per effettuare richieste aggiuntive. A differenza di OpenID, OAuth non termina con l'autenticazione ma fornisce un token di accesso per ottenere l'accesso a risorse aggiuntive fornite dallo stesso servizio di terze parti. Tuttavia, poiché OAuth non supporta il rilevamento, richiede la preselezione e la codifica definitiva dei provider che si decide di utilizzare. Un utente che visita il tuo sito non può utilizzare alcun identificatore, solo quelli preselezionati da te. Inoltre, OAuth non ha un concetto di identità, quindi usarlo per il login significa aggiungere un parametro personalizzato (come fatto da Twitter) o effettuare un'altra chiamata API per ottenere l'utente attualmente "connesso".

3. Implementazioni tecniche

I due protocolli condividono un'architettura comune nell'uso del reindirizzamento per ottenere l'autorizzazione dell'utente. In OAuth l'utente autorizza l'accesso alle proprie risorse protette e in OpenID, alla propria identità. Ma è tutto ciò che condividono.

Ogni protocollo ha un modo diverso di calcolare una firma utilizzata per verificare l'autenticità della richiesta o della risposta e ognuno ha requisiti di registrazione diversi.

OpenID è (principalmente) per l'identificazione / autenticazione, in modo che stackoverflow.comsappia che possiedo chris.boyle.name(o ovunque) e quindi che probabilmente sono la stessa persona che ha posseduto chris.boyle.nameieri e guadagnato alcuni punti reputazione.

OAuth è progettato per l'autorizzazione a intraprendere azioni per tuo conto, in modo che stackoverflow.com(o ovunque) possa chiedere l'autorizzazione, per esempio, Tweet per tuo conto automaticamente, senza conoscere la tua password di Twitter.

Molte persone continuano a visitarlo, quindi ecco un diagramma molto semplice per spiegarlo

Per gentile concessione di Wikipedia

OAuth

Utilizzato authorizationsolo per delegati : ciò significa che stai autorizzando l'accesso a un servizio di terze parti per utilizzare i dati personali, senza fornire una password. Anche le "sessioni" OAuth generalmente vivono più a lungo delle sessioni utente. Ciò significa che OAuth è progettato per consentire l'autorizzazione

ovvero Flickr utilizza OAuth per consentire ai servizi di terze parti di pubblicare e modificare un'immagine di persone per loro conto, senza che debbano fornire il loro nome utente e password sfarfallio.

OpenID

Utilizzato per authenticatel'identità single sign-on. Tutto ciò che OpenID dovrebbe fare è consentire a un provider OpenID di dimostrare che dici di esserlo. Tuttavia, molti siti utilizzano l'autenticazione dell'identità per fornire l'autorizzazione (tuttavia i due possono essere separati)

cioè Uno mostra il passaporto in aeroporto per autenticare (o provare) il nome della persona che si trova sul biglietto che sta usando.

Usa OAuth se i tuoi utenti potrebbero voler semplicemente accedere con Facebook o Twitter. Usa OpenID se i tuoi utenti sono manubri che gestiscono i propri provider OpenID perché "non vogliono che qualcun altro possieda la propria identità".

• OpenID è uno standard aperto e un protocollo di autenticazione decentralizzata controllato da OpenID Foundation.
• OAuth è uno standard aperto per la delega di accesso.
• OpenID Connect (OIDC) Combina le funzionalità di OpenID e OAuth, ovvero autenticazione e autorizzazione.

OpenID assume la forma di un URI univoco gestito da alcuni "provider OpenID", ovvero provider di identità (idP).

OAuth può essere utilizzato insieme a XACML dove OAuth viene utilizzato per il consenso della proprietà e la delega dell'accesso, mentre XACML viene utilizzato per definire i criteri di autorizzazione.

OIDC utilizza semplici token Web JSON (JWT), che è possibile ottenere utilizzando flussi conformi alle specifiche OAuth 2.0 . OAuth è direttamente correlato a OIDC poiché OIDC è un livello di autenticazione basato su OAuth 2.0 .

Ad esempio , se hai scelto di accedere a Auth0 utilizzando il tuo account Google, hai utilizzato OIDC . Una volta autenticato con successo con Google e autorizzato Auth0 ad accedere alle tue informazioni, Google invierà a Auth0 informazioni sull'utente e sull'autenticazione eseguita. Queste informazioni vengono restituite in un token Web JSON (JWT). Riceverai un token di accesso e, se richiesto, un token ID. Tipi di token : Fonte: OpenID Connect

Analogia :
Un uso organizzazione ID card per scopo identificativo e contiene chip, memorizza i dettagli di dipendenti con autorizzazione come i Campus / accesso Porta / ODC. La carta d' identità funge da OIDC e il chip funge da OAuth . altri esempi e modulo wiki

OpenID e OAuth sono protocolli basati su HTTP per l'autenticazione e / o l'autorizzazione. Entrambi hanno lo scopo di consentire agli utenti di eseguire azioni senza fornire credenziali di autenticazione o autorizzazioni generali a clienti o terze parti. Mentre sono simili e ci sono standard proposti per usarli entrambi insieme, sono protocolli separati.

OpenID è destinato all'autenticazione federata. Un cliente accetta un'asserzione di identità da qualsiasi fornitore (sebbene i clienti siano liberi di inserire nella whitelist o nella blacklist).

OAuth è destinato all'autorizzazione delegata. Un client si registra con un provider, che fornisce token di autorizzazione che accetterà per eseguire azioni per conto dell'utente.

OAuth è attualmente più adatto per l'autorizzazione, perché nel protocollo sono integrate ulteriori interazioni dopo l'autenticazione, ma entrambi i protocolli si stanno evolvendo. OpenID e le sue estensioni potrebbero essere utilizzate per l'autorizzazione e OAuth per l'autenticazione, che può essere considerata un'autorizzazione non operativa.

Credo che abbia senso rivedere questa domanda, come sottolineato anche nei commenti, l'introduzione di OpenID Connect potrebbe aver creato più confusione.

OpenID Connect è un protocollo di autenticazione come OpenID 1.0 / 2.0 ma in realtà è costruito su OAuth 2.0, quindi otterrai funzionalità di autorizzazione insieme a funzionalità di autenticazione. La differenza tra i due è abbastanza ben spiegata in dettaglio in questo articolo (relativamente recente, ma importante): http://oauth.net/articles/authentication/

La spiegazione della differenza tra OpenID, OAuth, OpenID Connect:

OpenID è un protocollo per l'autenticazione mentre OAuth è per l'autorizzazione. L'autenticazione consiste nell'assicurarsi che il ragazzo con cui stai parlando sia davvero chi afferma di essere. L'autorizzazione consiste nel decidere cosa dovrebbe essere permesso a quel ragazzo.

In OpenID, l'autenticazione è delegata: il server A vuole autenticare l'utente U, ma le credenziali di U (ad es. Nome e password U) vengono inviate a un altro server, B, che A si fida (almeno, si fida per autenticare gli utenti). In effetti, il server B si assicura che U sia effettivamente U, quindi dice ad A: "ok, questa è la vera U".

In OAuth, l'autorizzazione è delegata: l'entità A ottiene dall'entità B un "diritto di accesso" che A può mostrare al server S per ottenere l'accesso; B può quindi fornire chiavi di accesso temporanee e specifiche ad A senza dare loro troppa potenza. Puoi immaginare un server OAuth come il caposquadra di un grande hotel; fornisce ai dipendenti le chiavi che aprono le porte delle stanze in cui dovrebbero entrare, ma ciascuna chiave è limitata (non dà accesso a tutte le stanze); inoltre, le chiavi si autodistruggono dopo poche ore.

In una certa misura, l'autorizzazione può essere abusata in qualche pseudo-autenticazione, sulla base del fatto che se l'entità A ottiene da B una chiave di accesso tramite OAuth e la mostra al server S, allora il server S può dedurre che B ha autenticato A prima di concedere l'accesso chiave. Quindi alcune persone usano OAuth dove dovrebbero usare OpenID. Questo schema può o meno essere illuminante; ma penso che questa pseudo-autenticazione sia più confusa di ogni altra cosa. OpenID Connect fa proprio questo: abusa di OAuth in un protocollo di autenticazione. Nell'analogia dell'hotel: se incontro un presunto dipendente e quella persona mi mostra che ha una chiave che apre la mia stanza, allora suppongo che questo sia un vero impiegato, sulla base del fatto che il caposquadra non gli avrebbe dato una chiave che apre la mia stanza se non lo fosse.

(fonte)

In che modo OpenID Connect è diverso da OpenID 2.0?

OpenID Connect esegue molte delle stesse attività di OpenID 2.0, ma lo fa in un modo che sia API-friendly e utilizzabile da applicazioni native e mobili. OpenID Connect definisce meccanismi opzionali per la firma e la crittografia affidabili. Mentre l'integrazione di OAuth 1.0a e OpenID 2.0 richiedeva un'estensione, in OpenID Connect, le funzionalità di OAuth 2.0 sono integrate con il protocollo stesso.

(fonte)

OpenID connect ti darà un token di accesso più un token ID. Il token ID è un JWT e contiene informazioni sull'utente autenticato. È firmato dal provider di identità e può essere letto e verificato senza accedere al provider di identità.

Inoltre, OpenID connect standardizza un paio di cose che oauth2 lascia alla scelta. ad esempio ambiti, rilevamento degli endpoint e registrazione dinamica dei client.

Ciò semplifica la scrittura di codice che consente all'utente di scegliere tra più provider di identità.

(fonte)

OAuth 2.0 di Google

Le API OAuth 2.0 di Google possono essere utilizzate sia per l'autenticazione che per l'autorizzazione. Questo documento descrive la nostra implementazione OAuth 2.0 per l'autenticazione, che è conforme alla specifica OpenID Connect ed è certificata OpenID. La documentazione presente in Utilizzo di OAuth 2.0 per accedere alle API di Google si applica anche a questo servizio. Se desideri esplorare questo protocollo in modo interattivo, ti consigliamo il Google OAuth 2.0 Playground .

(fonte)

Più un'estensione alla domanda che una risposta, ma può aggiungere qualche prospettiva alle grandi risposte tecniche sopra. Sono un programmatore esperto in diverse aree, ma un noob totale per la programmazione per il web. Ora provando a creare un'applicazione basata sul Web utilizzando Zend Framework.

Sicuramente implementerà un'interfaccia di autenticazione di base nome utente / password specifica per l'applicazione, ma riconoscerà che per un numero crescente di utenti il ​​pensiero di un altro nome utente e password è un fattore dissuasivo. Pur non essendo esattamente un social network, so che una percentuale molto elevata dei potenziali utenti dell'applicazione ha già account Facebook o Twitter. L'applicazione non vuole davvero o non ha bisogno di accedere alle informazioni sull'account dell'utente da quei siti, vuole solo offrire la comodità di non richiedere all'utente di impostare nuove credenziali dell'account se non lo desidera. Da un punto di vista della funzionalità, sembrerebbe un bambino poster per OpenID. Ma sembra che né Facebook né Twitter siano fornitori OpenID in quanto tali, sebbene supportino l'autenticazione OAuth per accedere ai dati dei loro utenti.

In tutti gli articoli che ho letto sui due e su come differiscono, non sarà fino a quando non ho visto l'osservazione di Karl Anderson sopra, che "OAuth può essere usato per l'autenticazione, che può essere considerata un'autorizzazione non operativa" che Ho visto qualsiasi conferma esplicita che OAuth era abbastanza buono per quello che volevo fare.

In effetti, quando sono andato a pubblicare questa "risposta", non essendo un membro in quel momento, ho guardato a fondo in fondo a questa pagina le opzioni per identificarmi. L'opzione per utilizzare un login OpenID o ottenerne uno se non ne avessi uno, ma nulla su Twitter o Facebook, sembra suggerire che OAuth non fosse adeguato per il lavoro. Ma poi ho aperto un'altra finestra e ho cercato il processo di registrazione generale per StackOverflow - ed ecco che c'è una serie di opzioni di autenticazione di terze parti tra cui Facebook e Twitter. Alla fine ho deciso di utilizzare il mio ID google (che è un OpenID) proprio per il motivo per cui non volevo concedere l'accesso stackoverflow all'elenco dei miei amici e qualsiasi altra cosa che Facebook mi piace condividere sui suoi utenti - ma almeno '

Sarebbe davvero fantastico se qualcuno potesse pubblicare informazioni o puntatori a informazioni sul supporto di questo tipo di configurazione di autorizzazioni multiple di terze parti e su come gestisci gli utenti che revocano l'autorizzazione o perdono l'accesso al loro sito di terze parti. Ho anche l'impressione che il mio nome utente qui identifichi un account stackoverflow univoco a cui potrei accedere con l'autenticazione di base se volessi configurarlo e anche accedere a questo stesso account tramite altri autenticatori di terze parti (ad esempio, per essere considerato registrato su stackoverflow se sono stato effettuato l'accesso a uno di Google, Facebook o Twitter ...). Dal momento che questo sito lo sta facendo, qualcuno qui probabilmente ha delle intuizioni abbastanza buone sull'argomento. :-)

Mi dispiace che sia stato così lungo, e più una domanda che una risposta - ma l'osservazione di Karl ha fatto sembrare il posto più appropriato per pubblicare tra il volume di discussioni su OAuth e OpenID. Se c'è un posto migliore per questo che non ho trovato, mi scuso in anticipo, ho provato.

OpenID dimostra chi sei.

OAuth concede l'accesso alle funzionalità fornite dalla parte autorizzante.

Attualmente sto lavorando su OAuth 2.0 e OpenID connect spec. Quindi ecco la mia comprensione: in precedenza erano:

1. OpenID era l'implementazione proprietaria di Google che consentiva ad applicazioni di terze parti come per i siti Web di giornali di accedere tramite Google e commentare un articolo e così via altre pagine d'uso. Quindi, in sostanza, nessuna condivisione di password al sito Web del giornale. Consentitemi di mettere una definizione qui, questo approccio nell'approccio aziendale si chiama Federazione. Nella Federazione, hai un server in cui esegui l'autenticazione e l'autorizzazione (chiamato IDP, provider di identità) e in genere il custode delle credenziali dell'utente. l'applicazione client di cui si dispone è denominata SP o Service Provider. Se torniamo allo stesso esempio di sito Web di giornali, il sito Web di giornali è SP qui e Google è IDP. In azienda questo problema è stato precedentemente risolto utilizzando SAML. quel tempo XML usava per governare l'industria del software. Quindi, dai servizi Web alla configurazione, tutto andava in XML, quindi abbiamo SAML,

2. OAuth: OAuth ha visto l'emergenza come uno standard che esamina tutti questi tipi di approcci proprietari e quindi abbiamo avuto OAuth 1.o come standard ma affrontando solo l'autorizzazione. Non molte persone lo hanno notato, ma in qualche modo ha iniziato a raccogliere. Poi abbiamo avuto OAuth 2.0 nel 2012. I CTO, Architects hanno davvero iniziato a prestare attenzione mentre il mondo si sta muovendo verso il cloud computing e con i dispositivi di elaborazione verso il mobile e altri dispositivi simili. OAuth ha considerato come risolvere il problema principale in cui i clienti del software potrebbero fornire il servizio IDP a una società e avere molti servizi da diversi fornitori come salesforce, SAP, ecc. Quindi l'integrazione qui sembra davvero uno scenario di federazione un grosso problema, l'uso di SAML è costoso quindi esploriamo OAuth 2.o. Oh, ho perso un punto importante che durante questo periodo, Google ha percepito che OAuth in realtà non

   un. OAuth 2.o non dice chiaramente come accadrà la registrazione del cliente b. non menziona nulla sull'interazione tra SP (Resource Server) e l'applicazione client (come Analytics Server che fornisce i dati è Resource Server e l'applicazione che mostra che i dati sono Client)

Ci sono già risposte meravigliose qui fornite tecnicamente, ho pensato di dare una breve prospettiva evolutiva

OpenId utilizza OAuth per gestire l'autenticazione.

Per analogia, è come se NET si basasse sull'API di Windows. Potresti chiamare direttamente l'API di Windows, ma è argomenti così ampi, complessi e di metodo così vasti che potresti facilmente commettere errori / bug / problemi di sicurezza.

Lo stesso con OpenId / OAuth. OpenId si affida a OAuth per gestire l'autenticazione ma definendo un token specifico (Id_token), una firma digitale e flussi particolari.

Vorrei affrontare un aspetto particolare di questa domanda, come catturato in questo commento:

OAuth: prima di concedere l'accesso ad alcune funzionalità, è necessario eseguire l'autenticazione, giusto? quindi OAuth = cosa fa OpenId + garantisce l'accesso ad alcune funzionalità? - Hassan Makarov, il 21 giugno alle 1:57

Sì e no. La risposta è sottile, quindi abbi pazienza.

Quando il flusso OAuth ti reindirizza a un servizio di destinazione (ovvero il provider OAuth), è probabile che dovrai autenticarti con quel servizio prima che un token venga restituito all'applicazione / servizio client. Il token risultante consente quindi all'app client di effettuare richieste per conto di un determinato utente.

Nota la generalità di quest'ultima frase: in particolare, ho scritto "per conto di un determinato utente", non "per conto di te ". È un errore comune supporre che "avere la capacità di interagire con una risorsa posseduta da un determinato utente" implica "che tu e il proprietario della (e) risorsa (e) di destinazione siete una cosa sola".

Non commettere questo errore.

Sebbene sia vero che esegui l'autenticazione con il provider OAuth (ad esempio, per nome utente e password, o forse certificati client SSL o altri mezzi), ciò che il client ottiene in cambio non deve essere necessariamente preso come prova dell'identità. Un esempio potrebbe essere un flusso in cui l'accesso alle risorse di un altro utente è stato delegato a te (e per proxy, il client OAuth). L'autorizzazione non implica l'autenticazione.

Per gestire l'autenticazione, probabilmente vorrai esaminare OpenID Connect, che è essenzialmente un altro livello in cima alla base impostata da OAuth 2.0. Ecco una citazione che cattura (secondo me) i punti più salienti su OpenID Connect (da https://oauth.net/articles/authentication/ ):

OpenID Connect è uno standard aperto pubblicato all'inizio del 2014 che definisce un modo interoperabile per utilizzare OAuth 2.0 per eseguire l'autenticazione utente. In sostanza, è una ricetta ampiamente pubblicata per il fondente al cioccolato che è stata provata e testata da un ampio numero e varietà di esperti. Invece di creare un protocollo diverso per ogni potenziale provider di identità, un'applicazione può comunicare un protocollo a tutti i provider con cui desidera lavorare. Dal momento che è uno standard aperto, OpenID Connect può essere implementato da chiunque senza restrizioni o problemi di proprietà intellettuale.

OpenID Connect si basa direttamente su OAuth 2.0 e nella maggior parte dei casi viene distribuito insieme (o sopra) a un'infrastruttura OAuth. OpenID Connect utilizza anche la suite di specifiche JSON Object Signing And Encryption (JOSE) per trasportare informazioni firmate e crittografate in luoghi diversi. In effetti, una distribuzione OAuth 2.0 con funzionalità JOSE è già una lunga strada per definire un sistema OpenID Connect pienamente conforme e il delta tra i due è relativamente piccolo. Ma quel delta fa una grande differenza e OpenID Connect riesce a evitare molte delle insidie ​​discusse sopra aggiungendo diversi componenti chiave alla base OAuth: [...]

Il documento continua quindi a descrivere (tra le altre cose) gli ID token e un endpoint UserInfo. Il primo fornisce una serie di rivendicazioni (chi sei, quando il token è stato emesso, ecc., E possibilmente una firma per verificare l'autenticità del token tramite una chiave pubblica pubblicata senza dover chiedere al servizio upstream), e il secondo fornisce un significa, ad esempio, chiedere il nome / cognome dell'utente, e-mail e informazioni simili, il tutto in modo standardizzato (al contrario delle estensioni ad hoc di OAuth che le persone usavano prima delle cose standardizzate di OpenID Connect).

Entrambi i protocolli sono stati creati per diversi motivi. OAuth è stato creato per autorizzare terze parti ad accedere alle risorse. OpenID è stato creato per eseguire la convalida dell'identità decentralizzata. Questo sito Web afferma quanto segue:

OAuth è un protocollo progettato per verificare l'identità di un utente finale e concedere autorizzazioni a terzi. Questa verifica si traduce in un token. La terza parte può utilizzare questo token per accedere alle risorse per conto dell'utente. I token hanno un ambito. L'ambito viene utilizzato per verificare se una risorsa è accessibile a un utente o meno

OpenID è un protocollo utilizzato per l'autenticazione decentralizzata. L'autenticazione riguarda l'identità; Stabilire l'utente è in effetti la persona che afferma di essere. Decentralizzare ciò significa che questo servizio non è a conoscenza dell'esistenza di risorse o applicazioni che devono essere protette. Questa è la differenza chiave tra OAuth e OpenID.

OpenID Connect estende il protocollo di autorizzazione OAuth 2.0 da utilizzare come protocollo di autenticazione, in modo che sia possibile eseguire il single sign-on utilizzando OAuth. OpenID Connect introduce il concetto di token ID, che è un token di sicurezza che consente al client di verificare l'identità dell'utente

OAuth 2.0 è un protocollo di sicurezza. Non è NESSUNA autenticazione NÉ un protocollo di autorizzazione.

Autenticazione per definizione risponde a due domande.

1. Chi è l'utente?
2. L'utente è attualmente presente sul sistema?

OAuth 2.0 ha i seguenti tipi di concessione

• client_credentials: quando un'app deve interagire con un'altra app e modificare i dati di più utenti.
• autorizzazioni_codice: l'utente delega il server di autorizzazione per emettere un token di accesso che il client può utilizzare per accedere alla risorsa protetta
• refresh_token: allo scadere di access_token, il token di aggiornamento può essere sfruttato per ottenere un nuovo access_token
• password: l'utente fornisce le proprie credenziali di accesso a un client che chiama il server di autorizzazione e riceve un token di accesso

Tutti e 4 hanno una cosa in comune, access_token, un artefatto che può essere utilizzato per accedere alla risorsa protetta.

Access_token non fornisce la risposta alle 2 domande a cui deve rispondere un protocollo "Autenticazione".

Un esempio per spiegare Oauth 2.0 (crediti: OAuth 2 in Action, pubblicazioni Manning)

Parliamo di cioccolato. Possiamo preparare molte confezioni con cioccolato, tra cui fondente, gelato e torta. Ma nessuno di questi può essere equiparato al cioccolato perché sono necessari più altri ingredienti come panna e pane per rendere la confezione, anche se il cioccolato sembra l'ingrediente principale. Allo stesso modo, OAuth 2.0 è il cioccolato, e i cookie, l'infrastruttura TLS, i provider di identità sono altri ingredienti necessari per fornire la funzionalità "Autenticazione".

Se si desidera l'autenticazione, è possibile scegliere OpenID Connect, che fornisce un "id_token", a parte un access_token, che risponde alle domande a cui deve rispondere ogni protocollo di autenticazione.

OAuth crea l'autenticazione oltre all'autorizzazione: l'utente delega l'accesso alla propria identità all'applicazione, che, quindi, diventa un consumatore dell'API di identità, scoprendo quindi chi ha autorizzato il client in primo luogo http://oauth.net/ articoli / autenticazione /