it-swarm.dev

Quando usi OpenID vs. OpenID Connect

Possono essere usati insieme? .... o sono due protocolli separati che possono o non possono essere utili a seconda del contesto?

Il motivo per cui lo chiedo è perché sto cercando di implementare quanto segue:

  1. L'utente "Bob" si rivolge a un client implementato come un'applicazione solo User-Agent.
  2. Le risorse protette sono controllate dallo stesso dominio del server di autenticazione/autorizzazione, ma si trovano su sottodomini diversi. Tuttavia, nei cookie non viene trovata alcuna sessione, quindi ...
  3. Bob fa clic su "Accedi" e viene reindirizzato al server di autorizzazione/autenticazione utilizzando qualcosa di simile al seguente:

    GET https://accounts.example.com/authorize?response_type=token&client_id=123&redirect_uri=http://original.example.com&scope=openid profile token custom
    
  4. A Bob viene fornito un elenco di opzioni tra cui scegliere per l'autenticazione, ad esempio "esempio, google, Twitter" ecc. Che porta alla sua autenticazione su example.com, che a sua volta viene utilizzata per la sua autorizzazione per un'API specifica ospitata dall'esempio .com.

Dovrei usare OpenID Connect, OpenID 2.0, entrambi? Che cosa? Questa è la prima volta che implemento uno di essi. Sto solo chiedendo della parte di autenticazione di questo. Sto solo cercando di ottenere l'autenticazione di Bob in modo da poter passare al rilascio del token al client.

26
tjb1982

OpenID e OpenID Connect sono entrambi per l'autenticazione , non per l'autorizzazione . Le due attività sono distinte. OpenID Connect è infatti OAuth (un protocollo di autorizzazione) che viene trasformato (abusato) in un protocollo di autenticazione. Altre spiegazioni in questa risposta .

In una certa misura puoi mescolare autenticazione e autorizzazione, ma questa è una fonte di confusione. Nel tuo caso, apparentemente vuoi autenticare gli utenti con "Google, Twitter, ...": vuoi che Google (o Twitter) ti dica chi l'utente è , ma non ciò che l'utente dovrebbe essere autorizzato a fare ; vuoi questi fornitori esterni per l'autenticazione, non l'autorizzazione.

Un altro modo per vederlo è il seguente: un utente si collega al tuo server [~ # ~] s [~ # ~] . Il server [~ # ~] s [~ # ~] offre alcuni "servizi", ovvero farà "cose" quando richiesto; tuttavia, non accetterà di fare le stesse cose per tutti. Supponiamo che tu l'abbia trovato adatto per dare il controllo di ciò che [~ # ~] s [~ # ~] può fare o meno per ciascun utente a un altro sistema che chiameremo [~ # ~] r [~ # ~] . [~ # ~] r [~ # ~] può o meno essere lo stesso computer di [~ # ~] s [~ # ~] , ma pensiamo in modo generico e supponiamo che [~ # ~] r [~ # ~] è distinto da [~ # ~] s [~ # ~] . Dal punto di vista di [~ # ~] s [~ # ~] , le informazioni necessarie rientrano nell'ambito di autorizzazione: [~ # ~] s [~ # ~] vuole sapere se la chiamata deve essere concessa o meno. Quindi ci sarà un protocollo di autorizzazione in corso tra [~ # ~] s [~ # ~] e [ ~ # ~] r [~ ~ #] . Forse, [~ # ~] s [~ # ~] e [~ # ~] r [~ # ~] non parla direttamente tra loro, ma solo attraverso messaggi ("ticket") che vengono trasportati dal client; questo è un dettaglio tecnico.

Tuttavia, per decidere se consentire una determinata richiesta a [~ # ~] s [~ # ~] , il server di autorizzazione [~ # ~] r [~ # ~] deve sapere chi sta inviando il richiesta, perché la risposta dipende dall'identità dell'utente. Pertanto, [~ # ~] r [~ # ~] dovrà autenticare l'utente; o, più genericamente, parlare con un server di autenticazione [~ # ~] t [~ # ~] . [~ # ~] t [~ # ~] è responsabile di assicurarsi che l'utente sia effettivamente chi afferma di essere. Si verifica quindi un protocollo di autenticazione tra [~ # ~] r [~ # ~] e [~ # ~] t [~ ~ #] .

Nel tuo esempio, [~ # ~] r [~ # ~] è il tuo server di autorizzazione, mentre [~ # ~] t [~ # ~] è Google/Twitter. Utilizzeresti OpenID tra [~ # ~] r [~ # ~] e [~ # ~] t [~ # ~] e OAuth tra [~ # ~] s [~ # ~] e [~ # ~] r [~ # ~] .

OpenID Connect è quando [~ # ~] s [~ # ~] vuole fare anche un po 'di autenticazione; [~ # ~] s [~ # ~] quindi utilizza [~ # ~] r [~ # ~ ] (che "parla OAuth") e ne deduce che if [~ # ~] r [~ # ~] consente la richiesta, quindi [~ # ~] r [~ # ~] deve aver effettuato una sorta di autenticazione dell'utente; così [~ # ~] s [~ # ~] decide che l'utente è effettivamente chi afferma di essere, poiché (implicitamente) convinto [~ ~ #] r [~ ~ #] .

19
Thomas Pornin

Non credo che nessuna delle altre precedenti risposte risponda alla domanda, che sta facendo la differenza tra OpenID Connect e OpenID 2.0. OpenID 2.0 non è OAuth 2.0.

OpenID 2.0 e OpenID Connect sono standard molto diversi con parametri e formati del corpo di risposta completamente diversi. Entrambi sono costruiti sopra OAuth 2.0 inserendo valori aggiuntivi in ​​altrimenti valido OAuth 2.0 richieste e risposte, al fine di fornire le informazioni di identità necessarie per l'autenticazione (mentre OAuth 2.0 fornisce solo l'autorizzazione, non l'autenticazione). OpenID Connect ha migliorato la denominazione e la struttura di OpenID 2.0 campi e parametri per essere più facile da usare. Posso facilmente leggere il OpenID Connect specifiche e capire a cosa servono tutti i valori e su cosa impostarli, ma provando a leggere il OpenID 2.0 Le specifiche sono un po 'più difficili e contorte.

A questo punto la scelta è semplice, OpenID 2.0 è obsoleto. Dovresti usare OpenID Connect.

25
theferrit32

OAuth fornisce solo e dovrebbe fornire solo l'autorizzazione utilizzando un token di accesso. OpenID connect è basato su OAuth 2 per fornire informazioni di autenticazione dell'utente. OpenID connect è in effetti figlio di OpenID. Vedi OpenID-Connect-Lecture-for-MIT, slide

OpenID Connect 1.0 è un semplice livello di identità in cima al protocollo OAuth 2.0 [RFC6749]. Consente ai clienti di verificare l'identità dell'utente finale in base all'autenticazione eseguita da un server di autorizzazione, nonché per ottenere informazioni di base sul profilo dell'utente finale in modo interoperabile e simile a REST OpenID Connect Core 1.0 - bozza 17

Le cose sono, OpenID Connect ti fornisce un modo "standard" per ottenere l'identità dell'utente. Se usi OAuth e l'API, dovresti adattare la tua richiesta per ogni risorsa, che potrebbe non fornire sempre le stesse informazioni o cambiare nel tempo. E concettualmente usi OAuth per poter utilizzare un'API, non per autenticare un utente.

Come sfondo, le specifiche OAuth 2.0 Authorization Framework [RFC6749] e OAuth 2.0 Bearer Token Usage [RFC6750] forniscono un quadro generale per le applicazioni di terze parti da ottenere e utilizzano un accesso limitato alle risorse HTTP. Definiscono i meccanismi per ottenere e utilizzare i token di accesso per accedere alle risorse, ma non definiscono metodi standard per fornire informazioni sull'identità. In particolare, senza profilazione OAuth 2.0, è incapace di fornire informazioni sull'autenticazione di un utente finale OpenID Connect Core 1.0 - bozza 17

Nota che OpenID connect fornisce un id_token con alcune informazioni sull'utente. Ma se si desidera l'intero insieme di informazioni, è comunque necessario access_token per richiedere al provider OpenID di ottenere userinfo (che mi confonde la prima volta che lo vedo). Vedi 5.3.1. userinfo request nel progetto

5
Nereis