vs - Qual è la differenza tra OpenID e OAuth?





oauth2 connect (15)


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)

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




Più un'estensione alla domanda piuttosto che una risposta, ma può aggiungere una certa prospettiva alle grandi risposte tecniche di cui sopra. Sono un programmatore esperto in un certo numero di settori, ma un noob totale alla programmazione per il web. Ora stiamo provando a creare un'applicazione basata sul web usando Zend Framework.

Implementerà sicuramente un'interfaccia di autenticazione utente / password di base specifica dell'applicazione, ma riconosce che per un numero crescente di utenti il ​​pensiero di un altro nome utente e password è un deterrente. Pur non essendo esattamente social networking, so che una percentuale molto ampia di potenziali utenti dell'applicazione ha già account Facebook o Twitter. L'applicazione non vuole o non ha bisogno di accedere alle informazioni sull'account dell'utente da quei siti, ma vuole solo offrire la comodità di non richiedere all'utente di impostare nuove credenziali dell'account se non lo desiderano. Dal punto di vista della funzionalità, sembrerebbe un bambino poster per OpenID. Ma sembra che né Facebook né Twitter siano provider 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 in che modo si differenziano, non sarebbe stato fino a quando non ho visto l'osservazione di Karl Anderson sopra che "OAuth può essere usato per l'autenticazione, che può essere pensata come un'autorizzazione non operativa" che Ho visto qualsiasi conferma esplicita che OAuth fosse abbastanza buono per quello che volevo fare.

Infatti, quando sono andato a postare questa "risposta", non essendo un membro in quel momento, ho guardato a lungo ea fondo in questa pagina le opzioni per identificarmi. L'opzione per l'utilizzo di un login OpenID o di ottenerne uno se non ne avessi uno, ma nulla su Twitter o Facebook, sembrava suggerire che OAuth non fosse adeguato per il lavoro. Ma poi ho aperto un'altra finestra e ho cercato la procedura di registrazione generale per - ed ecco che c'è una manciata 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) esattamente per il motivo che non volevo concedere l'accesso alla mia lista di amici e qualsiasi altra cosa che Facebook ami condividere con i suoi utenti - ma almeno è un prova che OAuth è adeguato per l'uso che avevo in mente.

Sarebbe davvero bello se qualcuno potesse pubblicare informazioni o suggerimenti su come supportare questo tipo di installazione di autorizzazioni in 3 parti e su come gestire 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 identifichi un account unico al quale potrei accedere con l'autenticazione di base se volessi configurarlo e accedere allo stesso account tramite altri autenticatori di terze parti (ad es. In modo tale da essere considerato registrato in se ero collegato a uno qualsiasi di Google, Facebook o Twitter ...). Dal momento che questo sito lo sta facendo, qualcuno qui probabilmente ha qualche buona intuizione sull'argomento. :-)

Scusa, è stata una cosa lunga e più una domanda che una risposta, ma l'osservazione di Karl ha fatto sembrare che fosse il posto più appropriato da pubblicare tra il volume di thread su OAuth e OpenID. Se c'è un posto migliore per questo che non ho trovato, mi scuso in anticipo, ci ho provato.




OAuth

Utilizzato solo per l' authorization delegata, ovvero se si autorizza l'accesso di un servizio di terze parti a utilizzare dati personali, senza fornire una password. Anche le "sessioni" di OAuth generalmente durano più a lungo delle sessioni utente. Significa che OAuth è progettato per consentire l'autorizzazione

cioè Flickr utilizza OAuth per consentire ai servizi di terze parti di pubblicare e modificare un'immagine di persone per loro conto, senza che questi debbano distribuire il nome utente e la password del flicker.

OpenID

Utilizzato per authenticate l'identità Single Sign-On. Tutto ciò che OpenID dovrebbe fare è consentire ad un provider OpenID di dimostrare che tu dici di essere. 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 dimostrare) il nome di chi è sul biglietto che sta usando è loro.




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







OpenID dimostra chi sei.

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




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à".




Mi piacerebbe 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).




OpenID riguarda l'autenticazione (cioè la prova di chi sei), OAuth riguarda l'autorizzazione (per esempio per garantire l'accesso a funzionalità / dati / ecc. Senza dover affrontare l'autenticazione originale).

OAuth può essere utilizzato in siti partner esterni per consentire l'accesso ai dati protetti senza che debbano ripetere l'autenticazione di un utente.

Il post del blog " OpenID versus OAuth dal punto di vista dell'utente " ha un semplice confronto tra i due dal punto di vista dell'utente e " OAuth-OpenID: Stai abbaiando sull'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 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 di 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 caratteristica di scoperta ha anche causato la maggior parte dei problemi di OpenID perché il modo in cui è implementato è usando gli URI HTTP come identificatori che la maggior parte degli utenti web non ottengono. Altre caratteristiche OpenID ha il supporto per la registrazione client ad-hoc utilizzando uno scambio DH, 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 l'individuazione, 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.




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 decentralizzazione della convalida dell'identità. Questo website afferma quanto segue:

OAuth è un protocollo progettato per verificare l'identità di un utente finale e concedere autorizzazioni a terzi. Questa verifica genera un token. La terza parte può utilizzare questo token per accedere alle risorse per conto dell'utente. I token hanno uno scopo. 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 realtà la persona che afferma di essere. Decentralizzando 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 (OIDC) è un protocollo di autenticazione, basato sulla famiglia di specifiche OAuth 2.0 (ovvero O pen Auth orization). Utilizza semplici JSON Web Tokens (JWT), che è possibile ottenere utilizzando flussi conformi alle specifiche OAuth 2.0 . OAuth è direttamente correlato a OpenID Connect (OIDC) poiché OIDC è uno strato di autenticazione basato su OAuth 2.0

Mentre OAuth 2.0 riguarda l'accesso e la condivisione delle risorse, ad esempio Autorizzazione, OIDC si basa interamente sull'autenticazione utente. Il suo scopo è quello di darti un accesso per più siti. Ogni volta che è necessario accedere a un sito Web utilizzando OIDC , si viene reindirizzati al sito OpenID in cui si effettua il login e quindi riportati al sito Web.

OpenID Connect (OIDC) è un livello di autenticazione su OAuth 2.0, un framework di autorizzazione. Lo standard è controllato dalla Fondazione OpenID .:

Ad esempio , se hai scelto di accedere a Auth0 utilizzando il tuo account Google, hai utilizzato OIDC . Una volta che l'autenticazione con Google è avvenuta con successo e autorizzi Auth0 ad accedere alle tue informazioni, Google invierà di nuovo le informazioni su Auth0 dell'utente e l'autenticazione eseguita. Questa informazione viene restituita 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'organizzazione usa la carta d'identità per scopi di identificazione e contiene chip, memorizza i dettagli sul dipendente insieme all'autorizzazione, cioè all'accesso Campus / Gate / ODC. La carta d'identità funge da OIDC e Chip funge da OAuth . altri esempi




OpenId utilizza OAuth per gestire l'autenticazione.

Per analogia, è come se .NET si appoggi alle API di Windows. Potresti chiamare direttamente l'API di Windows ma è così vasto, complesso e gli argomenti del 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 definisce un token specifico (Id_token), firma digitale e flussi particolari.




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




Per me, la vera differenza tra SSO e OAuth è la concessione, non l'autenticazione perché un server che implementa OAuth ha ovviamente l'autenticazione (devi accedere al tuo google, openId o facebook affinché OAuth avvenga con l'app client)

In SSO, un utente avanzato / sysadmin concede all'utente finale l'accesso a un'applicazione in anticipo sull'app "SSO" In OAuth, l'utente finale concede l'accesso alle applicazioni ai suoi "dati" sull'app "OAuth"

Non vedo perché il protocollo OAuth non possa essere utilizzato come parte di un server SSO. Basta togliere la schermata di concessione dal flusso e lasciare che il server OAuth cerchi la sovvenzione dal db di backing.

(i miei 2 centesimi)





openid oauth