Cosa OpenID Connect aggiunge a OAuth 2.0 (perché OAuth 2.0 non è sufficiente per l'autenticazione?)

Question

Ho letto un certo numero di diversi write-up su questo ora, ma non sono ancora chiaro sul valore primario che OpenID Connect fornisce oltre OAuth 2.0.

Con consenso:
Quando si riceve un token di accesso tramite il flusso OAuth 2.0, il client viene a sapere che l'utente è stato autenticato dal server di autorizzazione. Sembra che OpenID Connect stia semplicemente aggiungendo un token ID con le informazioni dell'utente, ma tali informazioni potrebbero essere parte del token di accesso o disponibili attraverso una risorsa protetta (come una risorsa userDetails separata). Ciò non sembra giustificare la creazione di OpenID Connect, quindi sono sicuro che mi manca qualcosa ...

Grazie per il vostro aiuto!

Aggiunta di ulteriori dettagli troppo lunghi per un commento. Grazie mille per il tuo aiuto finora.

Penso che mi sto avvicinando, grazie alle vostre risposte. Quindi ho rivisto questo articolo: http://oauth.net/articles/authentication/. Dice che "OAuth non dice assolutamente nulla sull'utente". Tuttavia, ti stai fidando dello stesso servizio per autenticare l'utente finale prima di rilasciare un token di accesso. Nella sezione "errori comuni", l'articolo spiega perché non è possibile utilizzare il token di accesso per l'autenticazione. Ho i seguenti problemi con questo nella mia comprensione:

Token di accesso come prova di autenticazione Il token di accesso è stata la prova di autenticazione qualche precedente punto. Se il cliente desidera autenticare l'utente a un certo punto dopo aver ottenuto un token di accesso, perché non solo ripetere il flusso Oauth esistente con l'utente finale che sta tentando di accedere al client?

Accesso a una risorsa protetta come prova Come sopra: se il client richiede l'autenticazione in qualsiasi punto, ripetere il flusso Oauth.

iniezione di token di accesso Non è chiaro come OpenID aiuta questo

La mancanza di restrizione pubblico Perché è più difficile a portata di mano un client ingenuo di un documento di identità valido del token insieme con il token di accesso? Questo è rilevante per il flusso lato server? E ancora, puoi ripetere il flusso di OAuth se necessario.

Iniezione di informazioni utente non valide Questo sembra richiedere una firma, non un token separato. Se il flusso OAuth ha luogo su HTTPS, aggiunge qualche sicurezza al provider di identità per firmare due volte i dettagli dell'utente?

protocolli diversi per ogni potenziale provider di identità Questo sembra giusto, ma sembra ancora strano se l'unico scopo sarebbe la standardizzazione del token utilizzato per le informazioni dell'utente.

Answer 1

Un token di accesso è opaco per il Cliente e potrebbe essere stato fornito da chiunque, il che significa che non è necessariamente consegnato al Cliente da un utente che ha effettuato l'accesso. Un utente malintenzionato può fornire un token di accesso al client ricevuto da un altro utente nel proprio servizio (non necessariamente dannoso).Il token ID di OpenID Connect si assicura che l'utente abbia effettuato l'accesso di recente all'OP e fornisca informazioni su quell'utente che può essere verificato dal Cliente. Inoltre, il token ID è mirato in modo specifico al tuo cliente.

Le differenze sono descritte molto bene in http://oauth.net/articles/authentication/

Answer 2

un token ID può essere firmato dal server di autenticazione. Un'applicazione client può verificare la firma per confermare che l'utente finale è stato autenticato dal server di autenticazione stesso. Il token di accesso + la chiamata di risorse protette non fornisce un tale meccanismo.

Inoltre, OpenID Connect ha introdotto altri meccanismi relative all'autenticazione quali:

1. autenticazione Contesto di riferimento alla classe
2. autenticazione Età massima
3. sub domanda in claims parametro di richiesta

per soddisfare i requisiti di sicurezza di livello superiore da parte dei governi.

Leggi OpenID Connect Core 1.0 e altre specifiche correlate. Inoltre, è possibile trovare "Authorization interaction" utile come riepilogo su ciò che OpenID Connect ha aggiunto per controllare l'autenticazione dell'utente finale.

Answer 3

OAuth 2.0 è circa la concessione di un terzo accesso limitato a una risorsa. The RFC inizia con

Il framework di autorizzazione OAuth 2.0 consente di terze parti domanda per ottenere un accesso limitato a un servizio HTTP ...

OpenID Connect è di stabilire l'identità di un utente finale. Le OpenID Connect Core spec inizia con

OpenID Connect 1.0 è uno strato di identità semplice sulla parte superiore del 2,0 protocollo OAuth. Esso consente ai clienti di verificare l'identità del utente finale base l'autenticazione effettuata da un server di autorizzazione ...

In OAuth 2.0, quando un server riceve una richiesta di risorsa che contiene un token di accesso, il server di risorsa sa che il proprietario della risorsa ha concesso a terzi l'accesso a una risorsa. Il token di accesso rappresenta questa approvazione ma non identifica la terza parte che la presenta.

Se un'azienda pensa che qualcuno come Salesforce o Google sia meglio attrezzato di gestire account utente, password, certificati digitali, ecc., La società potrebbe utilizzare OpenID Connect essenzialmente per "esternalizzare" tale responsabilità a un provider OpenID Connect . Quando la società riceve un token ID nel contesto di un flusso OpenID Connect, sa che il provider ha autenticato l'utente finale e ha stabilito l'identità dell'utente.

OpenID Connect ha riutilizzato i flussi OAuth 2.0 in modo da poter stabilire l'identità di un utente finale.