| access management
OAuth2 et OIDC, deux petites histoires
Les protocoles OAuth 2.0 et OpenID connect ont connu un large succès à la fois au sein des entreprises et sur Internet depuis leurs introductions en 2012 et 2014.
Le protocole OpenID Connect repose grandement sur OAuth 2.0 mais a un objectif différent, ce qui peut mener à des confusions.
Pour mieux comprendre, souvenons-nous des deux concepts clés :
La délégation d'accès (OAuth2.0)
Qui n’a jamais été chercher une baguette à la boulangerie pour quelqu’un d’autre ? Le boulanger vous connaît bien, vous êtes un client chez lui, il sait que la personne qui vous envoi (resource owner) a un compte chez lui (une ressource), et cela tombe bien car elle vous a remis un petit mot signé (preuve d’autorisation ou grant). Le boulanger va vous donner temporairement la possibilité d’acheter du pain en utilisant le compte de la personne qui vous envoie. D’une certaine façon, le boulanger vous a donc en quelque sorte accordé un jeton d’accès (access_token) tant que vous êtes dans sa boutique.
Dans cet exemple, la confiance repose sur le fait que le boulanger vous connaisse et sur la signature du petit mot. La personne qui vous envoie n’a pas été obligée d’apporter une preuve de son identité.
Lors d’une délégation d’accès, nous avons eu quatre acteurs :
- Vous-même : le client ;
- Le boulanger qui a vérifié la signature du petit mot et vous a autorisé à dépenser sur le compte de la personne qui vous envoie : c’est un peu le serveur d’autorisation de notre histoire ;
- La personne qui vous envoie chez le boulanger (resource owner) ;
- Le compte de cette personne (la ressource).
L'authentification (Open ID Connect)
Si vous avez déjà commandé une bière au comptoir dans votre jeunesse, on vous a certainement demandé votre carte d’identité. Mais qu’est-ce-que cela a à voir avec l’authentification ? Étudions le sujet.
Pour obtenir votre carte d’identité, vous avez dû prouver celle-ci auprès de l’Etat qui est alors l’équivalent de l’OpenID provider.
Une fois que vous avez prouvé qui vous êtes, l’Etat vous remet une carte d’identité (id token) qui comporte des attributs d’identité (photo, nom, prénom, date de naissance). Mais les autorités pourront aussi utiliser l’identifiant de la carte (que nous assimilons à l’access token dans cet exemple) pour obtenir plus d’informations sur vous (UserInfo endpoint).
Retournons au barman (relying party) qui scrute avec attention votre date de naissance et votre photo : ce dernier décidera finalement de vous accorder votre pinte préférée… ou pas !
Besoin de conseils pour sécuriser votre entreprise ?
Ici, nous n’avons plus que trois acteurs en jeu :
- Vous-même (End-User) ;
- L’Etat, qui vous a fourni votre pièce d’identité (OpenID Provider) ;
- Le barman (Relying-Party ou RP qui se repose sur l’Etat pour être sûr de votre majorité).
Bien qu’OpenID Connect repose sur OAuth 2.0, l’access_token émis par l’OpenID Provider n’a, à la base, que deux utilités :
- Respecter le protocole OAuth 2.0 sur lequel repose OpenID Connect ;
- Permettre l’accès au UserInfo endpoint.
Bien que beaucoup le fassent, l’access token obtenu dans le contexte d’OpenID Connect ne devrait pas directement servir pour accéder à une autre ressource que l’UserInfo endpoint.
Le RP devrait en principe se contenter des informations de l’ID token pour s’assurer de l’identité de l’utilisateur. En revanche, rien n’interdit au RP d’échanger l’ID token auprès de l’OpenID Provider contre un nouvel access_token – qui lui servira à accéder à une API grâce au flux « token exchange. »
Ceci est d’autant plus vrai que certains OpenID Provider appliquent une audience à l’access_token qu’ils délivrent avec l’id_token, limitant leur utilisation au seul UserInfo Endpoint. ADFS, par exemple, limitera l’audience de l’access_token à « urn:microsoft:userinfo ».
Pour approfondir le sujet :
https://connect2id.com/learn/openid-connect ;
https://auth0.com/blog/id-token-access-token-what-is-the-difference/.
