OpenId Connect pour les nuls
Ajout d’une couche d’identité au protocole OAuth2.
Pour rappel, le protocole OAuth2 permet de faire de la délégation d’autorisation. C'est-à-dire qu’il permet aux services et applications de pouvoir partager leurs données entre eux facilement à l’aide d’un access token.
Certaines applications récupèrent les informations d’un utilisateur, comme le mail, le nom ou le prénom, dans le but d’afficher un message de bienvenue personnalisé, au moment où l’utilisateur arrive sur son interface par exemple. Elles utilisent l’access token qu’elles ont en main pour pouvoir authentifier le visiteur et récupérer les informations sur son identité. Le problème avec cette méthode, c’est que l’access token n’est pas une preuve que l’utilisateur est bien connecté à ce moment-là. Il permet juste à son porteur d’être autorisé à accéder à une ressource.
Le Ressource Server quand il réceptionne la demande d’accès aux ressources, n’a pas le moyen de savoir si l’utilisateur est connecté ou non. Surtout avec la notion de refresh token, que nous avons vu dans l’article sur Le protocole OAuth2 qui permet de faire une nouvelle demande d’access token sans que l’utilisateur soit connecté.
La solution pour pallier ce problème et s’assurer que l’utilisateur soit bien connecté, est d’utiliser une surcouche à OAuth2 qui va gérer l’authentification.
Cela tombe bien, c’est ce que nous permet le protocole OpenID Connect (OIDC) que nous allons voir un peu plus en détail dans cet article.
Le protocole OpenID Connect
OIDC est un protocole qui est très utilisé. Il permet d’ajouter une surcouche d’authentification à OAuth2, tout en nous donnant la possibilité de faire de la fédération d’identité.
La fédération d’identité permet de centraliser les données d’identités d’un utilisateur. Elle permet à des services et des applications de partager des informations sur un utilisateur. Cela permet notamment d’offrir à l’utilisateur la possibilité d’utiliser plusieurs services, en se connectant une seule fois auprès d’un tiers de confiance, grâce au Single Sign On (SSO).
Aujourd’hui OIDC est très utilisé pour faire notamment du SSO. Le Single Sign On, comme son nom l’indique, permet de faire de l’authentification unique. Ce qui permet aux utilisateurs d’accéder à différents services et applications en utilisant un seul identifiant unique, pour la durée d’une session.
Il y a plusieurs avantages comme éviter à l’utilisateur de renseigner un énième mot de passe qu’il va oublier ensuite. Ou bien lui offrir la possibilité d’accéder à plusieurs services après une unique authentification. Quand l’utilisateur va se connecter pour la première fois, une session SSO va être ajoutée dans son navigateur sous forme d’un cookie. Ce cookie va permettre par la suite de pouvoir utiliser une application de confiance sans que l’utilisateur ait à saisir de nouveau ses identifiants de connexion.
Reprenons notre exemple avec notre utilisatrice Emma que nous avons vue dans l’article sur OAuth2. Imaginons qu’Emma n’ait pas de compte sur LinkedIn. Deux solutions lui sont proposées par LinkedIn :
- La première est de remplir un formulaire de création de compte, où elle doit saisir son mail et un mot de passe.
- La deuxième solution est d’utiliser son compte Google pour créer un compte, via un bouton “se connecter avec Google”. Cette deuxième solution va permettre à Emma de pouvoir se connecter avec son compte Google pour accéder à l’application LinkedIn en SSO. De plus en plus de services utilisent le SSO pour authentifier ou créer un compte au sein de leurs applications.
Les deux protocoles se ressemblent. Il existe une différence notable qui se passe au moment de l’initialisation de la première demande. Le Scope openid doit être spécifié dès qu’on souhaite utiliser le protocole OIDC.
Une petite différence réside au moment où le Client (application cliente) va recevoir son access token. Il va également recevoir un ID Token que nous allons voir un peu plus en détail plus bas. Il existe également quelques différences de terminologies entre OAuth2 et OIDC.
Le End User est notre utilisateur qui va aller demander la connexion à un service, qui est notre Ressource Owner chez OAuth2.
Le Relying Party va représenter le Client. C’est lui qui va faire la requête pour authentifier un utilisateur et récupérer certains attributs d’identité comme le mail, le nom ou le prénom.
L’Identity Provider qui est notre Authorization Server va avoir une nouvelle fonctionnalité d’authentification d’un utilisateur. Il va être le référent de l’information pour confirmer qu’un End User s’est correctement authentifié.
Avec le protocole OAuth2, le Client va échanger un Authorization Code pour un access token afin d’avoir accès aux données de l’utilisateur. OIDC introduit un nouveau jeton qui est l’ID Token. Cet ID Token est fourni en même temps que l’access token.
L’ID Token est un jeton qui va porter l’identité de la personne qui est connectée, à l’image d’une carte d’identité ou d’un passeport. Il va contenir également des informations d’authentification, des attributs de l’identité du End User :
{
"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",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}- issuing authority (iss) : est l’Identity Provider ; l’autorité qui va délivrer les différents tokens.
- subject (sub) : unique identifiant assigné à un utilisateur donnée par l’ID Provider, comme le nom de famille.
- audience (aud) : permet d’identifier le Relaying Party auquel le JWT est destiné.
- nonce : chaîne de caractères qui permet de se protéger des attaques par rejeu (replay attack) qui consiste à interpeter une transmission de données et les rejouer. Le nonce est associé à une session Client qui possède un ID Token et qui va permettre de vérifier que c’est la même entité qui a fait la première demande d’authentification.
- expiration date (exp) : date d’expiration du token.
- issue date (iat) : date à laquelle le token a été émis.
- On a différents attributs utilisateur, comme le name ou le gender qui sont associés à des scopes que nous allons voir un peu plus bas.
Vous pouvez ajouter d’autres attributs optionnels dans la documentation d’OpenID Connect Core 1.0.
L’ID Token utilise le format JWT qui permet l’échange de tokens entre plusieurs services. Il peut être signé (JWS) ou bien encrypté pour ajouter une couche de confidentialité (JWE).
L’ossature du JWT signé (JWS) est composée de trois parties (le Header, le Payload et la Signature) qui sont encodées en base64 et séparées par un point.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiczZCaGRSa3F0MyIsIm5vbmNlIjoibi0wUzZfV3pBMk1qIiwiZXhwIjoxMzExMjgxOTcwLCJpYXQiOjEzMTEyODA5NzAsIm5hbWUiOiJKYW5lIERvZSIsImdpdmVuX25hbWUiOiJKYW5lIiwiZmFtaWx5X25hbWUiOiJEb2UiLCJnZW5kZXIiOiJmZW1hbGUiLCJlbWFpbCI6ImphbmVkb2VAZXhhbXBsZS5jb20iLCJwaWN0dXJlIjoiaHR0cDovL2V4YW1wbGUuY29tL2phbmVkb2UvbWUuanBnIn0.a7BkqyH2bUn-_QK7XuHc1yUe3m2AhcN2_2DxLxoo37YLe Header va fournir des informations sur le type de signature et le chiffrement utilisé pour l’encodage.
{ "alg": "HS256", "typ": "JWT" }Le Payload est la partie la plus intéressante, c’est celle qui contient les informations qui vont être transmises au Client.
{ "sub": "12345677", "name": "Jane Doe", "exp": 1311281970}La signature permet d’encoder le JWT via une clé secrète qui est connue seulement par le fournisseur du token. Il permet de vérifier que le jeton n’a pas été modifié pendant une requête.
{ 7WK5T79u5mIzjIXXi2oI9Fglmgivv7RAJ7izyj9tUyQ }Le JWE est utilisé quand un ID Token doit être crypté et encodé en base64url. Les deux parties (l’émetteur et le destinataire du JWE) doivent avoir la même clé de chiffrement pour décoder le contenu. Le JWE est composé de 5 types, séparés par des points.
- On retrouve le Header qui permet de récupérer les informations d’encodage.
- Le Encrypted Key est la clé de chiffrement.
- Le JWE initialization vector, permet d’introduire un caractère aléatoire pour le cryptage.
- Le JWE Ciphertext est le Payload où on va retrouver les attributs d’identité d’un utilisateur qui lui est crypté.
- Le JWE Authentication Tag permet de garantir l’intégrité du texte chiffré.
Les attributs d’identités et Scopes.
Le protocole OIDC fournit une vingtaine d’attributs d’identités et quatre scopes qui peuvent être utilisés pour le consentement et pour récupérer des informations sur le End User.
On a des attributs standards prédéfinis par OIDC :
- Scope profile : nom, prénom, genre, date de naissance, avatar…
- Scope email : email
- Scope address : adresse de l’utilisateur
- Scope phone : numéro de téléphone
Il existe aussi des attributs privés qui sont proposés par le fournisseur d’identité ; l’Identity Provider.
Ces informations sont accessibles dans l’ID Token. Si le Client a besoin de retrouver des informations à propos de l’utilisateur qui vient de se connecter, il peut utiliser l’endpoint qui est introduit par OIDC : UserInfo.
Le endpoint UserInfo est protégé par OAuth2. Le Client doit présenter un access token valide pour accéder aux attributs d’identités.
OIDC propose d’autres endpoints par défaut :
- authorization : pour permettre d’authentifier un utilisateur
- token : pour demander un access / refresh / ID token.
- revocation : pour supprimer un access token ou un refresh token
- introspection : pour pouvoir valider un access ou un refresh token.
Il est également possible d’utiliser un endpoint qui existe déjà avec OAuth2 : Discovery endpoint. Le Discovery endpoint permet d’accéder à des données de configuration, comme les scopes pris en charge, les autres endpoints ou bien les algorithmes de chiffrement.
Si vous avez aimé cet article, n’hésitez pas à mettre un like et à vous abonner :)
Ressources :
