OpenID è un protocollo per l'autenticazione mentre OAuth è per autorizzazione . L'autenticazione consiste nell'assicurarsi che il ragazzo con cui stai parlando sia effettivamente quello che 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 esempio il nome e la password di U) vengono inviate ad un altro server, B, che A trust (almeno, si fida per l'autenticazione degli utenti). Infatti, il server B si assicura che U sia effettivamente U, e poi dice ad A: "ok, questa è la U genuina".

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 dar loro troppa energia. Puoi immaginare un server OAuth come il key master in un grande hotel; dà a dipendenti chiavi che aprono le porte delle stanze che dovrebbero entrare, ma ogni chiave è limitata (non dà accesso a tutte le stanze); inoltre, i tasti 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 attraverso OAuth e la mostra al server S, allora il server S può inferire che B ha autenticato A prima di concedere la chiave di accesso. Quindi alcune persone usano OAuth dove dovrebbero usare OpenID. Questo schema può o non può essere illuminante; ma penso che questa pseudo-autenticazione sia più confusa di qualsiasi altra cosa. OpenID Connect fa proprio questo: abusa 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 io suppongo che questo è un vero impiegato, sulla base del fatto che il key master non gli avrebbe dato una chiave che apre la mia stanza se non lo fosse.

Termini semplici

1. OpenID riguarda la verifica dell'identità di una persona .
2. OAuth riguarda l'accesso a una persona.
3. OpenID Connect fa entrambi .

Tutti e tre consentono a una persona di fornire il proprio nome utente / password (o altre credenziali) a un'autorità attendibile anziché a un'app meno affidabile.

Altri dettagli

Per capire qualcosa, guarda la sua storia.

OpenID e amp; OAuth si sono sviluppati su binari paralleli e nel 2014 sono stati integrati in OpenID Connect. Nel corso della loro storia, OpenID e OAuth hanno consentito a un'app di utilizzare un'autorità attendibile per gestire le credenziali degli utenti privati. Mentre OpenID consente all'autorità di verificare l'identità di un utente, OAuth consente all'autorità di concedere un accesso limitato alle informazioni di un utente.

OpenID 1.0 (2006) consente a un'app di chiedere un'autorità per prova che un utente finale possiede un identificativo (un URL).

• Utente finale ad app: sono Steve A. Smith.
• App to authority: è Steve A. Smith?
• L'utente finale e l'autorità parlano per un momento.
• Autorità di app: Sì, questo è Steve A. Smith.

OpenID 2.0 (2007) fa lo stesso, ma aggiunge un secondo formato di identità (XRI) e aggiunge flessibilità a come l'utente finale specifica l'identità e l'autorità.

OpenID Attribute Exchange 1.0 (2007) estende OpenID 2.0 consentendo a un'app di recuperare e amp; memorizzare le informazioni del profilo dell'utente finale con l'autorizzazione - oltre a verificare l'identità dell'utente finale.

• Utente finale ad app: sono Steve A. Smith.
• App to authority: è questo Steve A. Smith? Oh, e se lo è, prendi anche il suo indirizzo e-mail e il numero di telefono.
• L'utente finale e l'autorità parlano per un momento.
• Autorità di app: Sì, questo è Steve A. Smith. La sua email è [email protected] e il numero di telefono è 123-456-7890.

OAuth 1.0 (2010) consente a un utente finale di concedere a un'app un accesso limitato alle risorse su un server di terze parti di proprietà di un'autorità.

• App per utente finale: vorremmo accedere alle tue foto su un altro server.
• L'utente finale e l'autorità parlano per un momento.
• Autorità di app: qui è un token di accesso.
• App al server di terze parti: ecco il token di accesso che dimostra che sono autorizzato ad accedere alle immagini per un utente finale.

OAuth 2.0 (2012) fa la stessa cosa di OAuth 1.0 ma con un nuovo protocollo.

OpenID Connect (2014) combina le funzionalità di OpenID 2.0, OpenID Attribute Exchange 1.0 e OAuth 2.0 in un singolo protocollo. Permette ad un'applicazione di usare un'autorità ...

1. per verificare l'identità dell'utente finale,
2. per recuperare le informazioni sul profilo dell'utente finale e
3. per ottenere un accesso limitato ai contenuti dell'utente finale.

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

Wikipedia di cortesia

Oltre alle altre risposte: penso che molta confusione derivi da inacurrato, o almeno insolito uso dei termini Autenticazione e Autorizzazione

OpenID Connect 1.0 è commercializzato come soluzione Authentication , mentre non gestisce da solo l'autenticazione. L'autenticazione "reale" nel suo senso fondamentale (processo di convalida delle credenziali dell'utente per dimostrare un'identità ) non rientra nell'ambito di OpenID Connect.

OpenID Connect dovrebbe essere meglio commercializzato come un protocollo Federazione , consentendo a una parte richiedente di utilizzare il processo di autenticazione esistente, il database utente e la gestione della sessione da un provider di ID di terze parti. Funziona in modo simile a SAML 2.0.

Nota: in senso stretto, da un punto di vista di Relying Party, ottenere e convalidare un token ID da un provider di ID può essere considerato un metodo di autenticazione. Credo che sia da qui che "OpenID Connect è un protocollo di autenticazione".

Stesso ragionamento per OAuth 2.0 che è un protocollo Autorizzazione : solitamente l'autorizzazione è il processo di definizione di un criterio di accesso che determina quali utenti hanno accesso a quali risorse. Questa definizione non vale per OAuth.

OAuth 2.0 sta in effetti offrendo agli utenti la possibilità di consentire a un'applicazione / client di accedere alle proprie risorse per loro conto. In altre parole, OAuth 2.0 autorizza le applicazioni client , non gli utenti, ad accedere alle risorse. La Politica di autorizzazione (che concede agli utenti l'accesso alle risorse) dovrebbe esistere prima di implementare OAuth.

Avrei etichettato OAuth un protocollo di delega di accesso .

Mi scuso se quel post solleva ulteriormente la confusione:)

Abbiamo già uno schema e molti buoni dati, quindi ecco un esempio nel caso in cui questo aiuti.

Diciamo che voglio pubblicare un commento su StackOverflow. StackOverflow consente solo commenti se un utente ha 50 reputazione.

StackOverflow deve autorizzare questa richiesta (ad esempio, permetti solo se l'utente ha > = 50 rep). StackOverflow non utilizza OAuth per eseguire questa operazione poiché StackOverflow è proprietario della risorsa protetta. Se StackOverflow stava tentando di pubblicare un commento su Facebook per conto dell'utente, userebbe OAuth. Invece, StackOverflow utilizzerà l'autorizzazione locale (ad esempio if (user.reputation < 50) throw InsufficientReputationError(); )

Per fare questo StackOverflow deve prima sapere chi sta facendo la richiesta. In altre parole, per autorizzare la richiesta deve prima autenticare la richiesta.

StackOverflow controlla prima la sessione e le intestazioni HTTP per vedere se l'utente può essere rapidamente autenticato (ad esempio non è la prima richiesta) ma fallisce.

Supponiamo che StackOverflow abbia deciso di utilizzare OpenID Connect. Ciò significa che StackOverflow si fida di un provider di identità. Questo è un servizio che TrustOverflow si fida e può dire a StackOverflow chi è l'utente corrente. In questo esempio, supponiamo che sia Google.

StackOverflow ora chiede a Google chi è l'utente corrente. Tuttavia, Google deve prima assicurarsi che StackOverflow sia autorizzato a sapere chi è l'utente corrente. In altre parole, Google deve autorizzare StackOverflow. Dal momento che Google è il proprietario della risorsa protetta e StackOverflow è l'unico ad accedervi, possiamo utilizzare OAuth qui. In effetti, OpenID Connect lo impone.

Ciò significa che StackOverflow deve autenticare con un server di autorizzazione di cui Google si fida (in realtà, questo sarebbe anche Google, ma che non deve essere il caso) e ottenere un token di accesso . Porta quel token di accesso a Google e chiede l'identità dell'utente. Google restituisce quindi l'identità dell'utente (firmando l'identità sulla strada) e StackOverflow autorizza quindi la richiesta ora che conosce l'identità dell'utente.

Nel caso lo avessi perso ci sono stati più passaggi di autenticazione e autorizzazione ciascuno.

• StackOverflow ha tentato di autenticare la richiesta utilizzando i cookie di sessione ma non è riuscita.
• StackOverflow quindi autenticato la richiesta utilizzando OpenID Connect
• Google autorizzato richiesta di identità di SO mediante OAuth
• Il server di autorizzazione autenticato StackOverflow (probabilmente utilizzando un ID client e un segreto client).
• Inoltre, come parte del flusso di lavoro OAuth, il server di autorizzazione può avere autenticato la richiesta chiedendo all'utente il suo nome utente & password.
• Inoltre, l'utente stesso potrebbe avere una autorizzazione richiesta di identità di SO rispondendo a una schermata di concessione (ad esempio "vuoi consentire a StackOverflow di avere accesso alla tua email?")
• StackOverflow autorizzato la richiesta assicurando che l'utente abbia > 50 reputazione.

Che cos'è OpenID (senza connessione)?

Questo era un protocollo precedente che consentiva a un provider di identità (come Google) di passare le informazioni dell'utente a un servizio (come StackOverflow). Tuttavia, ha utilizzato un altro metodo (non OAuth) per consentire a Google di autorizzare StackOverflow ad accedere all'identità dell'utente. OpenID aveva alcuni difetti di sicurezza (che credo fossero stati risolti) ma a mio parere il vero killer era semplicemente il fatto che OAuth avesse un supporto migliore e quindi tendeva ad essere meno lavoro rispetto all'apprendimento del protocollo personalizzato di OpenID.

A partire da oggi tutti lo stanno abbandonando. Non usarlo. Utilizza OpenID Connect.

"Abuso" OAuth

Nello scenario che ho descritto sopra, OAuth viene utilizzato esattamente come previsto per l'autorizzazione. Tuttavia, esiste un altro flusso di lavoro che può spesso confondere le persone. Questo è sorto perché in molte situazioni (la maggior parte?) Il server fornisce l'identità dell'utente e il server di autorizzazione OAuth è lo stesso server.

In questo caso sembra un po 'eccessivo che una richiesta HTTP venga prima inviata al server di autorizzazione per ottenere un token di accesso e quindi fatto di nuovo sullo stesso server per ottenere un token di identità. Quindi è stata creata una estensione per le specifiche OAuth per consentire al server di autorizzazione di raggruppare informazioni sull'identità dell'utente con il token di accesso.

Ciò consente l'autenticazione interamente nel browser (ad esempio, i server di StackOverflow non devono essere coinvolti). Tuttavia, quel tipo di autenticazione è meno utile e (penso?) È meno utilizzato.

Come già accennato, Oauth è una cosa, OpenID è un'altra, e OpenID Connect combina i due.

Ma, come già detto, l'uso di autenticazione e autorizzazione per differenziare Oauth e OpenID è semplicemente sbagliato. L'autenticazione, la conferma della veridicità della rivendicazione di un'entità su un'identità memorizzata, è attribuita a OpenID ma è definitivamente parte del processo Oauth. L'autorizzazione, l'autorizzazione ad accedere a una specifica risorsa o contenitore, è attribuita a Oauth ma è definitivamente parte del processo OpenID.

In base alla mia esperienza, la vera differenza tra Oauth e OpenID può essere vista nelle tipiche attività non correlate all'autore che vengono eseguite e da chi, sotto ogni schema.

• OpenID facilita l'accesso dell'utente a un contenitore autorizzato con risorse in bundle (ad esempio accesso al sito Web).
• Oauth facilita l'accesso automatico a una risorsa autorizzata all'interno di un contenitore (ad esempio, le operazioni CRUD su un file o una registrazione tramite una API Web).

OpenID Connect, quindi, consente a un utente di accedere a un indirizzo Web e, una volta dentro, fornisce all'applicazione Web sottostante un modo per recuperare risorse aggiuntive esterne al sito per conto dell'utente.

Riassumendo: OpenID Connect è un'API di identità federata che include un profilo e un'estensione di OAuth 2.0 che consente a un client (ad es. app mobile o sito Web) di reindirizzare una persona a un provider di identità centrale per l'autenticazione e consente a tale persona di autorizzi il rilascio di informazioni a quel cliente.

Dovresti leggere il mio blog OAuth vs. SAML vs. OpenID Connect : link

L'API OpenID Connect include un numero di endpoint, non tutti correlati a OAuth:

OAuth Endpoint

• Autorizzazione : sito Web del canale anteriore che esegue il rendering della pagina di accesso e della pagina di autorizzazione (consenso). (RFC 6749)
• Token : endpoint del canale posteriore, che richiede normalmente l'autenticazione, in cui un client può richiedere token di accesso, id_tokens e token di aggiornamento. (RFC 6749)
• Configurazione : metadati del provider pubblicati in .well-known/openid-configuration , inclusi il percorso degli endpoint, gli algoritmi crittografici supportati e altre informazioni necessarie al client per interagire con l'OP. (RFC 8414)
• Registrazione client : endpoint per un'applicazione per creare o aggiornare un client OAuth (RFC 7591)

Endpoint non OAuth

• Informazioni utente : accesso all'API protetta da token in cui il client può richiedere indicazioni su un argomento. Questo è il server di risorse in termini OAuth.
• JWKS : le chiavi pubbliche correnti dell'OP utilizzate per la firma e la crittografia
• Gestione della sessione : utilizzata da tutte e tre le specifiche di logout di OpenID (nessuna funziona così bene)
• Webfinger : utilizzato per eseguire il bootstrap di OP all'avvio da un indirizzo e-mail (o altro identificativo), ad esempio come si può determinare l'endpoint di configurazione per un dominio. (RFC 7033, ma non fa parte del WG OAuth)