OAuth 2 vs OpenID Connect per proteggere l'API

Da quello che hai spiegato sembra che OAuth 2.0 sia più adatto alle tue esigenze. OpenID Connect è stato sviluppato per aggiungere l'autenticazione sicura a OAuth 2.0. Grandi fornitori, ad esempio Google, Facebook, Yahoo e così via, hanno iniziato a usare OAuth 2.0 come modo per autenticare gli utenti con servizi di "accesso con" in modo che gli utenti potessero utilizzare le proprie credenziali per autenticare una varietà di servizi di terze parti. Standard OAuth 2.0 non può soddisfare in modo sicuro questo requisito a causa di carenze all'interno del protocollo. OpenID Connect risolve queste lacune e consente ai provider di utilizzare in modo sicuro OAuth 2.0 come framework di autenticazione. OAuth 2.0 è stato originariamente sviluppato come framework di autorizzazione che consente a un utente di concedere a un servizio di terzi l'accesso ai propri dati memorizzati nel provider. Lo scenario che hai descritto sembra esattamente ciò che OAuth 2.0 è stato sviluppato per fare. Se non si prevede di offrire un meccanismo di "accesso con", utilizzare OAuth 2.0.

Se un utente avrà le proprie credenziali per i servizi di terze parti e non utilizzerà le credenziali del proprio provider per accedere al servizio, non sarà necessario OpenID Connect.

Questa è stata la risorsa più utile che ho trovato. È un post sul blog di uno dei designer di OpenID Connect che si rivolge ai diversi usi di Facebook per OAuth 2.0.

Innanzitutto, come probabilmente saprai, OpenID Connect è solo un livello di autenticazione costruito su OAuth2. Quindi, a prescindere da ciò che scegli, dovrai implementare OAuth2 (come denominatore comune).

OAuth2 stesso è un meccanismo di autorizzazione (ad esempio, consente di verificare che un token sia valido e che sia concesso un set specifico di ambiti). Non fornisce l'autenticazione immediata (non è possibile dire immediatamente "chi" è l'utente).

Tuttavia, in molti casi, potresti avere sia l'autenticazione che dell'autorizzazione. In questo caso hai bisogno di un layer sopra OAuth2 per fornirlo. Ciò è più comunemente fatto se il server delle risorse espone una sorta di "Chi sono io?" endpoint che restituisce l'identità dell'utente associato al token di accesso.

OpenID Connect lo fa e fornisce un modo standard per ottenere e rappresentare l'identità dell'utente (ovvero l'oggetto restituito da UserInfo endpoint) come un insieme di reclami .

Consente inoltre all'app client di ricevere le informazioni dell'utente insieme al token di accesso (ovvero id_token restituito dall'endpoint del token o incluso insieme al codice di autorizzazione come token JWT firmato, a seconda del flusso), che salva una richiesta HTTP.

OpenID Connect offre anche un sacco di altre cose che IMO sono di minore interesse (registrazione dinamica, ecc.).

Quindi, per rispondere alla tua domanda su OAuth2 rispetto a OpenID Connect: se hai bisogno dell'autenticazione per le tue API, dovrai implementarlo sopra OAuth2. Puoi fare qualcosa di personalizzato o implementare OpenID Connect. OpenID Connect è molto complesso se si desidera implementare l'intera specifica, ma relativamente facile se si desidera implementare l'MVP per autenticare un utente (implementare l'endpoint di informazioni utente e utilizzare la rappresentazione standard e forse problema id_tokens).

Per maggiori informazioni consulta la specifiche OpenID Connect .