Qual è la differenza tra OpenID e OAuth?


Answers

Esistono tre modi per confrontare OAuth e OpenID:

1. Scopi

OpenID è stato creato per l'autenticazione federata, ovvero consente a una terza parte di autenticare i tuoi utenti per te, utilizzando gli account che hanno già . Il termine federato è fondamentale qui perché l'intero punto di OpenID è che qualsiasi provider può essere utilizzato (ad eccezione delle white-list). Non è necessario preselezionare o negoziare un accordo con i fornitori per consentire agli utenti di utilizzare qualsiasi altro account che hanno.

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 insieme diverso di caratteristiche che sono desiderate da diverse implementazioni ma essenzialmente, sono piuttosto intercambiabili. Al loro centro, entrambi i protocolli sono un metodo di verifica delle asserzioni (OpenID è limitato all'asserzione "this is who I am", 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 indietro con un'affermazione verificabile. OpenID fornisce un'asserzione di identità mentre OAuth è più generico sotto forma di un token di accesso che può quindi essere utilizzato per "porre domande al provider OAuth" . Tuttavia, ognuno di essi supporta diverse funzionalità:

OpenID : la caratteristica più importante di OpenID è il suo processo di scoperta. OpenID non richiede la codifica hard di ciascun provider che si desidera utilizzare in anticipo. Utilizzando la scoperta, l'utente può scegliere qualsiasi provider di terze parti che desidera autenticare. Questa funzione di scoperta ha anche causato la maggior parte dei problemi di OpenID perché il modo in cui viene implementato è l'utilizzo di URI HTTP come identificatori che la maggior parte degli utenti Web non ottiene. Altre caratteristiche OpenID ha il supporto per la registrazione client ad-hoc utilizzando uno scambio DH, la modalità immediata per ottimizzare l'esperienza dell'utente finale e un modo per verificare le asserzioni senza fare un altro round-trip al provider.

OAuth : la caratteristica più importante di OAuth è il token di accesso che fornisce un metodo di lunga durata per effettuare richieste aggiuntive. A differenza di OpenID, OAuth non termina con l'autenticazione ma fornisce un token di accesso per accedere a risorse aggiuntive fornite dallo stesso servizio di terze parti. Tuttavia, poiché OAuth non supporta la scoperta, richiede la preselezione e l'hard-coding dei provider che decidi di utilizzare. Un utente che visita il tuo sito non può utilizzare alcun identificatore, solo quelli preselezionati dall'utente. Inoltre, OAuth non ha un concetto di identità, quindi utilizzarlo 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'utilizzo 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 questo è 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.

Question

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




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 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, trust per l'autenticazione degli utenti). Infatti, il server B si assicura che U sia effettivamente U, e poi dice a 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à ai dipendenti chiavi che aprono le porte delle stanze che dovrebbero entrare, ma ogni 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 attraverso OAuth e la mostra al server S, allora il server S può dedurre che B autenticato A prima di concedere l'accesso chiave. 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 suppongo che sia un vero impiegato, sulla base del fatto che il keymaster non gli avrebbe dato una chiave che apre la mia stanza se non lo fosse.

(source)

In che modo OpenID Connect è diverso da OpenID 2.0?

OpenID Connect svolge molte delle stesse attività di OpenID 2.0, ma lo fa in un modo che è API-friendly e utilizzabile da applicazioni native e mobili. OpenID Connect definisce i meccanismi opzionali per la firma e la crittografia robuste. 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.

(source)

OpenID connect ti fornirà 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, scoperta degli endpoint e registrazione dinamica dei client.

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

(source)

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 alle specifiche OpenID Connect ed è certificata OpenID. La documentazione trovata in Uso 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 campo di gioco Google OAuth 2.0 .

(source)




Credo che abbia senso rivisitare questa domanda come indicato anche nei commenti, l'introduzione di OpenID Connect potrebbe aver portato più confusione.

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




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

OAuth: prima di concedere l'accesso ad alcune funzionalità, l'autenticazione deve essere eseguita, giusto? quindi OAuth = cosa OpenId fa + concede l'accesso ad alcune funzionalità? - Hassan Makarov, 21 giugno alle 1:57

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

Quando il flusso OAuth ti reindirizza a un servizio di destinazione (il provider OAuth, ovvero), è probabile che dovrai eseguire l'autenticazione con quel servizio prima che un token venga restituito all'applicazione / al 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 presumere che "avere una capacità di interagire con una risorsa di proprietà di un determinato utente" implichi che "tu e il proprietario della / e risorsa / e di destinazione / i siano / sono nella stessa".

Non fare questo errore.

Anche se è vero che ti autentichi con il provider OAuth (ad esempio, per nome utente e password, o forse certificati client SSL, o qualche altro mezzo), ciò che il cliente riceve in cambio non dovrebbe necessariamente essere preso come prova di identità. Un esempio potrebbe essere un flusso in cui l'accesso alle risorse di un altro utente è stato delegato all'utente (e per proxy, il client OAuth). L'autorizzazione non implica l'autenticazione.

Per gestire l'autenticazione, è probabile che vogliate esaminare OpenID Connect, che è essenzialmente un altro livello in cima al set di base di OAuth 2.0. Ecco una citazione che cattura (a mio avviso) i punti salienti di OpenID Connect (da here ):

OpenID Connect è uno standard aperto pubblicato all'inizio del 2014 che definisce un modo interoperativo per utilizzare OAuth 2.0 per eseguire l'autenticazione dell'utente. In sostanza, è una ricetta ampiamente diffusa per il cioccolato fondente che è stata provata e testata da un ampio numero e varietà di esperti. Invece di costruire un protocollo diverso per ogni potenziale provider di identità, un'applicazione può parlare un protocollo a tutti i provider con cui vogliono lavorare. Dato che si tratta di uno standard aperto, OpenID Connect può essere implementato da chiunque senza limitazioni o preoccupazioni di proprietà intellettuale.

OpenID Connect è costruito direttamente su OAuth 2.0 e nella maggior parte dei casi viene distribuito direttamente con (o sopra) 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 di OAuth 2.0 con funzionalità JOSE è già un lungo cammino verso la definizione di un sistema OpenID Connect completamente compatibile e il delta tra i due è relativamente piccolo. Ma quel delta fa una grande differenza e OpenID Connect riesce a evitare molte delle insidie ​​sopra discusse aggiungendo diversi componenti chiave alla base OAuth: [...]

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




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




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

  1. OpenID era un'implementazione proprietaria di Google che consente applicazioni di terze parti come per i siti web dei giornali che puoi accedere usando google e commentare un articolo e così via su altri casi. Quindi, in sostanza, nessuna condivisione delle password sul sito web dei giornali. Lasciatemi fare una definizione qui, questo approccio nell'approccio aziendale è chiamato Federazione. In Federazione, hai un server in cui ti autentichi e autorizzi (chiamato IDP, Identity Provider) e generalmente il detentore delle credenziali dell'utente. l'applicazione client in cui si ha business è denominata SP o Service Provider. Se torniamo allo stesso esempio di sito web del quotidiano, il sito web dei giornali è SP e Google è IDP. In azienda questo problema era stato precedentemente risolto utilizzando SAML. quella volta XML usato per governare l'industria del software. Quindi dai servizi web alla configurazione, tutto ciò che era usato per andare in XML così abbiamo SAML, un protocollo federativo completo
  2. OAuth: OAuth ha visto la sua comparsa come standard guardando tutti questi tipi di approcci proprietari e quindi abbiamo avuto OAuth 1.o come standard, ma solo l'autorizzazione. Non sono state notate molte persone, ma ha iniziato a raccogliere. Poi abbiamo avuto OAuth 2.0 nel 2012. CTO, Architects ha davvero iniziato a prestare attenzione mentre il mondo si sta muovendo verso il cloud computing e con i dispositivi informatici che si spostano verso dispositivi mobili e altri simili. OAuth è stato considerato come la soluzione di problemi importanti in cui i clienti software potevano offrire servizi IDP a una società e avere molti servizi da venditori diversi, come Salesforce, SAP, ecc. Quindi l'integrazione qui sembra davvero uno scenario di federazione un grosso problema, l'utilizzo di SAML è costoso quindi esploriamo OAuth 2.o. Oh, ho perso un punto importante che durante questo periodo, Google ha rilevato che OAuth in realtà non affronta l'autenticazione, in che modo IDP fornirà i dati utente a SP (che in realtà è meravigliosamente risolto in SAML) e con altre estremità libere come:

    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 dati è Resource Server e l'applicazione che mostra che i dati sono Client)

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