Oauth2 vs OpenId Connect
Aujourd’hui, la fédération d’identité est un sujet essentiel en matière d’authentification pour toute organisation offrant de multiples services applicatifs. Parmi les nombreux protocoles de fédération disponibles, les plus répandus semblent être OAuth2 et OpenID Connect (OIDC). Ce billet s’attachera donc à décrypter ces protocoles : à quoi servent-ils ? Quelles différences y a-t-il entre ces 2 protocoles ? Dans quel cas les utiliser ?
Qu’est-ce qu’OAuth2 ?
Communément, on pense à OAuth2 comme à un protocole permettant de se connecter et d’accéder à un service via une identité gérée par un partenaire Et pourtant, c’est exactement ce que n’est pas OAuth2. Le but du protocole est de permettre d’autoriser un site web, un logiciel ou une application (dit « consommateur ») à utiliser l’API sécurisée d’un autre site web (dit « fournisseur ») pour le compte d’un utilisateur.
Si on simplifie, il faut retenir qu’OAuth2 n’est pas un protocole d’authentification, mais de « délégation d’autorisation ». Pour se servir d’OAuth2 comme méthode d’authentification, deux étapes sont nécessaires. La première consiste à récupérer un token d’autorisation, nommé « accessToken », suite à l’authentification de l’utilisateur sur le SI du partenaire. La seconde permet, à partir de cet accessToken, d’appeler une API afin de récupérer les informations de l’utilisateur.
Qu’est-ce qu’OpenID Connect ?
OpenID Connect, troisième génération du protocole OpenID mise en place par la fondation OpenID, consiste en une simple couche d’identification basée sur OAuth 2.0. Ce protocole permet de vérifier l’identité d’un utilisateur auprès d’un serveur d’autorisation afin d’obtenir des informations sur cet utilisateur. Les opérations sont réalisées via des web services REST et les données sont échangées au format JSON.
OpenID Connect apporte certaines nouveautés par rapport à OpenID 2.0 afin de le rendre plus simple d’utilisation, notamment pour l’intégration d’APIs et pour le développement d’applications mobiles. Le protocole définit notamment des mécanismes optionnels de signature et de chiffrement des données, ce qui n’était jusqu’alors pas possible dans les autres protocoles.
Un autre apport important d’OpenID Connect consiste en la standardisation des données obtenues suite à une authentification. Celles-ci sont formalisées dans un « ID token » au format JWT, qui contient des paramètres obligatoires et non obligatoires. Ces paramètres seront toujours nommés de la même façon quel que soit le partenaire de fédération.
Ci-dessous un exemple d’ID Token
{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
Exemples d’utilisation de ces protocoles
Les protocoles de fédération OAuth2 et OpenID Connect sont utilisés au quotidien par un grand nombre d’utilisateurs d’Internet pour s’authentifier sur différents services via l’identité qu’ils possèdent sur l’un des grands acteurs du Web : Facebook, Google, Yahoo, etc.
Par exemple, Facebook Connect ou Google Connect sont utilisés par de très nombreux sites Internet pour authentifier de manière transparente les utilisateurs sur ces sites.
D’un point de vue technique, l’accès à un site lambda via une authentification Google Connect se déroule de la manière suivante :
A la fin de cette séquence, le site client a obtenu un « ID Token », qui contient des informations de l’utilisateur. Il a également récupéré un « Access Token », qui permet d’interroger les APIs de Google (comme ça aurait été le cas dans une séquence OAuth2).
En quoi OpenID Connect est-il différent d’OAuth2 ?
Comme on a pu le voir, le principal apport d’OpenID Connect par rapport à OAuth2 est cette séquence d’authentification. Une fois celle-ci réalisée, on dispose directement des informations utilisateurs, il n’est pas nécessaire de faire appel à une API supplémentaire pour récupérer ces informations.
D’un point de vue sécurité, l’utilisation du format JWT pour les ID Token permet de gérer les fonctions de signature et de chiffrement qui garantissent l’intégrité des données utilisateurs.
Enfin la normalisation des données permet maintenant à l’ensemble des acteurs d’une cinématique OpenID Connect, c’est-à-dire les consommateurs ou les fournisseurs, d’être interopérables : il n’est plus nécessaire de prendre en compte les spécificités de chacun, comme c’est le cas dans une cinématique OAuth2.
Dans quel cas utiliser OpenID Connect ? Dans quel cas utiliser OAuth2 ?
OAuth2 a pour vocation première la sécurisation d’APIs, c’est donc en ce sens qu’il faut l’utiliser. Si la fonction d’authentification n’est pas nécessaire, mais que seule celle d’autorisation est souhaitée, alors ce protocole sera bien adapté.
Dans le cas d’un site web auquel on souhaite ajouter un bouton de type « Authentification avec … », il sera préférable de se tourner vers OpenID Connect.
OpenID Connect a été conçu pour répondre aux limites de OAuth2 dans le domaine de l’authentification forte. Le but est de permettre à des sites tiers d’obtenir une identité de façon plus sécurisée que ne peut le faire OAuth2.
Puisqu’il s’agit d’une surcouche de OAuth2, OpenID Connect est également capable de répondre à l’ensemble des cas d’utilisations de OAuth2.
OAuth2 et OpenID Connect apportent une vraie valeur ajoutée aux organisations désireuses de disposer d’un fournisseur d’identités centralisé, sur lequel les services et applications du SI, consommateurs de ces identités, pourront s’appuyer.
De plus en plus de solutions du marché sont maintenant compatibles avec ces protocoles : OAuth2 et OpenID Connect garantissent l’interopérabilité entre les différentes applications, et fournissent un format d’échange d’informations normalisé qui permet une intégration plus rapide et plus simple des applications dans le système d’informations.
Si les sujets de l’Access Management vous intéressent, n’hésitez pas à télécharger notre fiche pratique sur la sécurisation des accès distants :
