Quando usi OpenID vs. OpenID Connect

OpenID e OpenID Connect sono entrambi per autenticazione , non per autorizzazione . Le due attività sono distinte. OpenID Connect è in effetti 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 utenti con "Google, Twitter, ...": vuoi Google (o Twitter) per dirti chi è l'utente , ma non ciò che l'utente dovrebbe essere autorizzato a fare ; vuoi questi provider esterni per l'autenticazione, non l'autorizzazione.

Un altro modo per vederlo è il seguente: un utente si connette al server S . Server S offre alcuni "servizi", cioè "cose" quando richiesto; tuttavia, non accetterà di fare le stesse cose per tutti. Supponiamo che tu l'abbia trovato adatto a dare il controllo di ciò che S potrebbe fare o meno per ogni utente a un altro sistema che chiameremo R . R può o meno essere lo stesso computer di S , ma pensiamo genericamente e supponiamo che R sia distinto da S . Dal punto di vista di S , le informazioni necessarie sono nel campo dell'autorizzazione: S vuole sapere se la chiamata deve essere concessa o meno. Quindi ci sarà un protocollo di autorizzazione tra S e R . Forse S e R non parleranno direttamente tra loro, ma solo attraverso messaggi ("ticket") che vengono trasportati dal client; questo è un dettaglio tecnico.

Tuttavia, per decidere se una determinata richiesta di S dovrebbe essere consentita o meno, 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, per parlare con un server di autenticazione T . T è responsabile di assicurarsi che l'utente sia effettivamente chi afferma di essere. Quindi avviene un protocollo di autenticazione tra R e T .

Nel tuo esempio, R è il tuo server di autorizzazione, mentre T è Google / Twitter. Usi OpenID tra R e T e OAuth tra S e R .

OpenID Connect è quando S vuole fare anche qualche autenticazione; S quindi usa R (chi "parla OAuth") e deduce che se R consente la richiesta, allora R deve aver effettuato una sorta di autenticazione dell'utente; quindi S decide che l'utente è effettivamente chi afferma di essere, dal momento che (implicitamente) ha convinto R .

Non penso che nessuna delle altre risposte precedenti risponda alla domanda, che chiede 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 risposta completamente diversi. Entrambi sono costruiti sopra OAuth 2.0 inserendo valori aggiuntivi in richieste e risposte di OAuth 2.0 altrimenti valide, al fine di fornire le informazioni sull'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 dei campi e dei parametri di OpenID 2.0 per essere più facile da usare. Posso leggere facilmente la specifica OpenID Connect e capire a cosa servono tutti i valori e a cosa impostarli, ma provare a leggere la specifica OpenID 2.0 è un po 'più difficile e complicata.

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

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

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. OpenID Connect Core 1.0 - draft 17

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

As background, the OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Token Usage [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. OpenID Connect Core 1.0 - draft 17

Nota che OpenID connect fornisce un token_id con alcune informazioni sull'utente. Ma se si desidera l'intero set di informazioni, è comunque necessario access_token per richiedere al provider OpenID di ottenere l'utenteinfo (che mi confonde la prima volta che lo vedo). Guarda 5.3.1. userinfo request nella bozza