OAuth 2.0 est-il un système d’authentification ?
L’authentification suppose que l’application protégée, qui reçoit une autorisation de délivrer les informations à l’application cliente, puisse identifier l’utilisateur final et l’application qui sont à l’origine de l’autorisation.
OAuth ne fournit pas cette identité et doit être complété pour assurer l’authentification.
OpenID Connect
OpenID Connect est une couche d’authentification construite sur OAuth 2.0. Le serveur d’autorisation (ou "fournisseur OpenID" dans ce cas, en anglais OpenID Provider ou OP) contient des informations sur une personne. OAuth est utilisé pour protéger ces informations, permettant à une application tierce (client) d’y accéder au nom de cette personne. Pour autoriser la diffusion d’informations, la personne est authentifiée et le Fournisseur OpenID fournit au client des détails notamment sur l’identité de la personne et le moment de l’authentification.
En plus du jeton d’accès, OpenID Connect met en oeuvre le jeton JWT (JSON Web Token) qui contient des informations sur l’utilisateur authentifié. Le jeton d’identification est signé par le serveur d’autorisation et peut être lu et vérifié sans accéder au serveur d’autorisation. C’est cette caractéristique qui doit conduire à choisir OpenID Connect, en réponse à la problématique de la Validation du jeton par une ressource protégée.
En outre, OpenID Connect standardise différentes choses que OAuth laisse au choix du développeur. Par exemple les scopes, la découverte des points d’extrémité et l’enregistrement dynamique des clients. Mais cela reste des options, le standard est ouvert.