it-swarm.dev

Differenza tra OAUTH, OpenID e OPENID Connect in termini molto semplici?

Sono molto confuso dal gergo difficile disponibile in rete su OAUTH, OpenID e OPENID Connect. Qualcuno può dirmi la differenza in parole semplici.

148
user960567

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). Infatti, 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 OAuth server come il caposquadra di un grande hotel; dà ai dipendenti le chiavi che aprono le porte delle stanze in cui dovrebbero entrare, ma ogni chiave è limitata ( non dà accesso a tutte le stanze); inoltre, le chiavi si autodistruggono dopo alcune 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ò 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 ogni 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 un chiave che apre la mia stanza, quindi I supponiamo che questo è un vero impiegato, sulla base del fatto che il caposquadra non gli avrebbe dato una chiave che aprisse la mia stanza se non lo fosse.

181
Thomas Pornin

Termini semplici

  1. OpenID riguarda la verifica dell'identità di una persona (autenticazione).
  2. OAuth riguarda l'accesso alle cose di una persona (autorizzazione).
  3. OpenID Connect fa entrambe .

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 attendibile.

Più dettagli

Per capire qualcosa, guarda la sua storia.

OpenID & OAuth si sono sviluppati su tracce parallele e nel 2014 si sono fusi in OpenID Connect. Nel corso della loro storia, OpenID e OAuth hanno permesso 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 cose di un utente.

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

  • Utente finale dell'app: sono Steve A. Smith.
  • App all'autorità: è Steve A. Smith?
  • L'utente finale e l'autorità parlano per un momento.
  • Autorità per l'app: Sì, quello è Steve A. Smith.

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

OpenID Attribute Exchange 1. (2007) estende OpenID 2.0 consentendo a un'app di recuperare e archiviare le informazioni del profilo dell'utente finale con l'autorità - oltre a verificare l'identità dell'utente finale.

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

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

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

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

OpenID Connect (2014) combina le funzionalità di OpenID 2.0, OpenID Attribute Exchange 1.0 e OAuth 2.0 in un unico protocollo. Consente a un'applicazione di utilizzare 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 alle cose dell'utente finale.
93
Shaun Luttin

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

OpenID_vs._pseudo-authentication_using_OAuth

Wikipedia di cortesia

59
Vrashabh Irde

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

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

OpenID Connect dovrebbe essere commercializzato meglio come protocollo Federazione , consentendo a una Parte Rely di utilizzare il processo di autenticazione, il database utente e la gestione delle sessioni esistenti da parte di terzi Provider ID. Funzionalmente è simile a SAML 2.0.

Nota: a rigor di termini, dal punto di vista di un Relying Party, ottenere e validare un token ID da un provider ID può essere considerato come un metodo di autenticazione. Credo che sia da lì che "OpenID Connect è un protocollo di autenticazione".


Stesso ragionamento per OAuth 2.0 essendo un protocollo Autorizzazione : di solito l'autorizzazione è il processo di definizione di una politica di accesso che determina quale gli utenti hanno accesso a quali risorse. Tale definizione difficilmente si applica a OAuth.

OAuth 2.0 sta effettivamente offrendo agli utenti un modo per consentire a un'applicazione un'applicazione/client di accedere alle proprie risorse per loro conto. In altre parole, OAuth 2.0 autorizza le applicazioni client , non gli utenti, per accedere alle risorse. La politica di autorizzazione ( la concessione agli utenti l'accesso alle risorse dovrebbe esistere prima della distribuzione di OAuth.

Avrei etichettato il protocollo OAuth an delega di accesso .

Chiedo scusa se quel post aumenta ulteriormente la confusione :)

8
Guillaume

Abbiamo già un diagramma e molti buoni dati, quindi ecco un esempio nel caso in cui sia di aiuto.

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

StackOverflow deve autorizzare questa richiesta (ad es. Consentirla solo se l'utente ha> = 50 ripetizioni). StackOverflow non userebbe OAuth per farlo perché StackOverflow possiede la risorsa protetta. Se StackOverflow stesse provando a pubblicare un commento su Facebook per conto dell'utente, avrebbe usato OAuth. Invece StackOverflow utilizzerà local autorizzazione (ad es. 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 autenticato rapidamente (ad es. Questa non è la loro prima richiesta) ma non riesce.

Facciamo finta che StackOverflow abbia deciso di utilizzare OpenID Connect. Ciò significa che StackOverflow si fida di un provider di identità. Questo è un servizio di cui StackOverflow si fida e che 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. Poiché Google è il proprietario della risorsa protetta e StackOverflow è quello che vi accede, possiamo usare OAuth qui. In effetti, OpenID Connect lo impone.

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

Nel caso in cui tu l'abbia 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 è riuscito.
  • StackOverflow quindi ha autenticato la richiesta utilizzando OpenID Connect
  • Google ha autorizzato la richiesta di identità di SO utilizzando OAuth
  • Il server di autorizzazione autenticato StackOverflow (probabilmente utilizzando un ID client e un segreto client).
  • Inoltre, nell'ambito del flusso di lavoro OAuth, il server di autorizzazione può avere autenticato la richiesta chiedendo all'utente il suo nome utente e password.
  • Inoltre, l'utente stesso potrebbe avere autorizzato la richiesta di identità di SO rispondendo a una schermata di concessione (ad es. "Vuoi consentire a StackOverflow di avere accesso al tuo e-mail?")
  • StackOverflow ha autorizzato la richiesta assicurando che l'utente avesse una reputazione> 50.

Che cos'è OpenID (senza la 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 Google per autorizzare StackOverflow ad accedere all'identità dell'utente. OpenID aveva alcuni difetti di sicurezza (che credo fossero stati risolti) ma a mio avviso il vero killer era semplicemente il fatto che OAuth aveva un supporto migliore e quindi tendeva ad essere meno lavoro dell'apprendimento del protocollo personalizzato di OpenID.

Ad oggi tutti lo stanno abbandonando. Non usarlo. Usa 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 spesso può confondere le persone. Ciò è emerso perché in molte situazioni (la maggior parte?) Il server che fornisce l'identità dell'utente e il OAuth server di autorizzazione sono lo stesso server.

In questo caso sembra un po 'eccessivo che una richiesta HTTP sia prima fatta al server di autorizzazione per ottenere un token di accesso e poi di nuovo fatta allo stesso server per ottenere un token di identità. Quindi è stato creato un estensione per la specifica OAuth per consentire al server di autorizzazione di raggruppare le informazioni sull'identità dell'utente con il token di accesso.

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

8
Pace

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

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

Nella mia esperienza, la vera differenza tra Oauth e OpenID può essere vista nelle tipiche attività non relative all'autorizzazione eseguite e da chi, sotto ogni schema.

  • OpenID facilita l'accesso degli utenti a un contenitore autorizzato con risorse raggruppate (ad es. Accesso al sito Web).
  • Oauth facilita l'accesso automatizzato a una risorsa autorizzata all'interno di un container (ad es. Operazioni CRUD su un file o record tramite un'API Web).

OpenID Connect, quindi, consente a un utente di accedere a un indirizzo Web e, una volta effettuato l'accesso, offre all'applicazione Web sottostante un modo per recuperare risorse aggiuntive fuori sede per conto dell'utente.

3
johnaweber

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 o sito Web mobile) di reindirizzare una persona a un provider di identità centrale per l'autenticazione e consente a tale persona di autorizzare il rilascio di informazioni a quel cliente.

Dovresti leggere il mio blog OAuth vs. SAML vs. OpenID Connect : https://gluu.co/oauth-saml-openid

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

Endpoint OAuth

  • Autorizzazione: sito Web del canale anteriore che visualizza la pagina di accesso e la pagina di autorizzazione (consenso). (RFC 6749)
  • Token: endpoint del canale posteriore, che normalmente richiede l'autenticazione, in cui un client può richiedere token di accesso, token ID e token di aggiornamento. (RFC 6749)
  • Configurazione: metadati del provider pubblicati su .well-known/openid-configuration, inclusa la posizione 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 OAuth (RFC 7591)

Endpoint non OAuth

  • Userinfo: Accedi all'API protetta con token a cui il cliente può richiedere reclami su un argomento. Questo è il Resource Server in OAuth.
  • [~ # ~] jwks [~ # ~]: le attuali chiavi pubbliche dell'OP utilizzate per la firma e la crittografia
  • Gestione della sessione: usato da tutte e tre le specifiche di logout di OpenID (nessuna funziona così bene)
  • Webfinger: utilizzato per bootstrap rilevamento OP funzionante all'indietro da un indirizzo e-mail (o altro identificativo), ovvero come calcolare l'endpoint di configurazione per un dominio. (RFC 7033, ma non parte del OAuth WG)
2
Mike Schwartz