Identifiez les fonctions de OAuth
Au cours de la dernière partie, vous avez vu ce qu'étaient l’authentification et l’autorisation. Nous avons créé un formulaire de connexion en utilisant Spring Security, puis nous avons ajouté des pages séparées en autorisant l’accès en fonction des rôles (administrateur et utilisateur). C’était une première démonstration sur la façon d'utiliser l’authentification et l’autorisation sur le même site.
La création d’une connexion sécurisée est simple… en théorie. 😉
Imaginez que vous êtes développeur d’application pour une petite entreprise de e-commerce. Des clients se connectent et effectuent des achats en utilisant leurs données personnelles. La majorité des violations de données prennent pour cible les petites entreprises, car elles ne dédient généralement pas un budget important aux mesures de protection de données.
Heureusement, il existe une solution à ce problème : OAuth !
Hein ? 😨
Pas d’inquiétude. Vous apprendrez tous ces détails techniques à mesure que nous avancerons dans ce chapitre. Pour l’heure, laissez-moi vous donner une idée générale de la chose. 😎
En clair, OAuth 2.0 permet à vos clients de créer un compte sur votre application web en se connectant sur un compte appartenant à une société vérifiée, comme Google, Facebook, Twitter, Okta ou GitHub. Vous vous êtes probablement déjà enregistré sur un site permettant de créer un profil via votre compte Google ou Facebook.
Cette application web vous permet de créer un compte avec vos identifiants Google ou Facebook. Beaucoup d’utilisateurs choisissent ce mode de connexion, facile et rapide. Dans ce cas, Google et Facebook sont qualifiés de fournisseurs d’identité (IdP). Ces derniers sont utilisés pour authentifier un utilisateur et gérer son identité.
Ça ressemble à une authentification… alors pourquoi OAuth est-il considéré comme un protocole d'autorisation ?
Ces sociétés (Google, Facebook, etc.) gèrent l’authentification sur leur serveur, en tant que fournisseurs d’identité. Cependant, lorsqu’il s’agit de se connecter à une application via un fournisseur d’identité, OAuth délègue les permissions requises au cours de ce processus.
Qu’entendez-vous par “permissions” ?
Les permissions reviennent à donner l’accès à une information. OAuth permet à l’utilisateur et au serveur qui gère la connexion, par exemple Google, d'autoriser l’utilisation de certaines informations par l’application.
Facebook gère la partie connexion ; vous n’avez donc pas besoin de créer un nouveau compte. Il n’est même pas nécessaire que vous donniez vos identifiants Facebook à ce site. En tant que développeur, inutile de s’embêter à mettre en place une base de données sécurisée pour gérer les identifiants de chacun. OAuth s’en charge pour vous.
Maintenant que vous avez une idée de ce que c’est, regardons de plus près le fonctionnement de OAuth 2.0. Une fois que vous aurez compris tout ça, il vous sera plus facile de l’implémenter dans votre code en utilisant Spring Security.
Décrivez le Code Workflow de l’autorisation de OAuth 2.0
Regardons ce protocole d'autorisation étape par étape.
Étape 1 : Connection au serveur d’autorisation de Facebook
Imaginons que vous souhaitiez vous connecter à OpenClassrooms.
Pour rappel, il existe deux entités clés dans ce processus :
l'utilisateur : c’est vous, la personne qui se connecte à OpenClassrooms avec OAuth ;
le client : l’application web à laquelle vous vous connectez avec le bouton “Se connecter avec Facebook”.
Vous cliquez pour vous connecter à Facebook.
Le client vous dirige vers le serveur d’autorisation de Facebook.
Il s’agit du serveur auquel vous vous connectez grâce à vos identifiants Facebook. Ce serveur est enregistré avec OpenClassrooms.
Étape 2 : Autorisation avec OAuth
Lorsque que vous entrez vos identifiants Facebook, l’indication suivante apparaît :
“Autorisez-vous OpenClassrooms à accéder à votre liste de contacts ?”
OAuth s’assure alors que vous acceptez ce périmètre (scope, en anglais).
Les données spécifiques requises dans le scope sont qualifiées de claims (des clés). Ces clés peuvent représenter des données personnelles d’utilisateurs, dont le nom entier, l’adresse mail, etc. Il peut également s’agir de droits spécifiques dans le cadre de l’autorisation, comme un mode lecture seule, ou une suppression d’accès concernant une clé spécifique.
Si vous répondez oui, vous serez redirigé vers l’URL de redirection avec un code d’autorisation. Il s’agit d’un code temporaire qui détient les informations concernant vos identifiants Facebook.
Étape 3 : Autorisation en échange d’un token d’accès
Le client envoie un code d’autorisation au serveur d’autorisation de Facebook, en échange d’un token d’accès à votre liste de contacts. Ce token détient des informations d’autorisation de Facebook.
Étape 4 : Validation avec le serveur de ressources
Ce token est envoyé vers le serveur API de Facebook, qui est appelé serveur de ressources dans ce workflow. Ce serveur vérifie les informations sur le token d’accès, et permet au client d’accéder aux données d’utilisateur requises dans l’application.
Désormais, chaque fois qu'OpenClassrooms vérifiera votre connexion, il procédera à votre validation et à celle des informations autorisées sur le serveur de ressources de Facebook.
Et voilà, maintenant vous savez comment fonctionne OAuth 2.0 !
Comprenez OpenID Connect (OIDC)
OAuth 2.0 travaille avec des fournisseurs d’identité externes qui garantissent une authentification sécurisée. Le processus OAuth 2.0, quant à lui, traite majoritairement de l’autorisation. Que faire si un site nécessite plus d’informations, comme un nom, un prénom et une adresse vérifiés ?
Mais d'ailleurs, c’est quoi, un nom et une adresse vérifiés ?
Lorsque vous vous enregistrez sur des sites spécifiques et que vous leur fournissez une adresse mail, votre enregistrement n'est validé que lorsque votre e-mail est vérifié.
Habituellement, cette vérification a lieu lorsque vous cliquez sur le lien qui vous est envoyé. Le fournisseur d’identité peut alors prouver la vérification de vos données personnelles de cette manière.
Comment cela se traduit dans OAuth 2.0 ?
OAuth est un protocole d’autorisation qui, une fois enregistré auprès du fournisseur d’identité, renvoie un token d’accès contenant un principal et un objet authorities. Ce token permet de valider votre identité auprès du fournisseur.
Le principal représente les informations vous concernant, que le fournisseur d'identité renvoie.
Comment régler ce problème ? Comment faire pour que l’application web client dispose d'informations vérifiables et prouvées pour s'authentifier ?
Je vous présente (roulement de tambour) une extension OAuth 2.0 assez incroyable : OpenID Connect (OIDC). Elle peut ajouter la pièce d'authentification manquante à OAuth 2.0.
Et donc, comment ça marche ?
Souvenez-vous : l’authentification revient à prouver qui vous êtes, qui vous prétendez être.
Avec OIDC, le client peut obtenir vos données encodées depuis le serveur ressource de Facebook, comme une adresse mail vérifiée, et donc, est capable de vous authentifier.
Les données personnelles encodées se présentent sous la forme d'un token chiffré. Ce token est renvoyé vers l’application web du client. Il contient les informations protégées, les claims, qui représentent le détail des informations pour l’utilisateur concerné, depuis le scope Open ID.
Comment s’en servir ?
Voici trois manières dont OIDC résout les problèmes d’authentification, en ajoutant la sécurité ainsi que l’identité dans le fournisseur d’identité externe.
En raison de l’encodage en Base64 de la clé privée du fournisseur d'identité, lorsque l’authentification requiert OIDC, un hacker ne peut pas injecter de fausses informations pour modifier le principal du client, car le token ID, le token d’accès et le token de rafraîchissement sont envoyés encodés via HTTPS.
Le token d’identité est temporaire, l’authentification est donc vérifiée en permanence. Le token d’accès de OAuth 2.0 est valide durant 24 heures, et ne peut être rétabli qu'avec un token de rafraîchissement. Cela rend le suivi de l'authentification de l’utilisateur un peu plus compliqué, et donc moins vulnérable aux attaques. Vous pouvez modifier le délai d’expiration du token d’accès en suivant ces étapes (en anglais).
Qu'il s’agisse de l'OpenID, du profil, de l'e-mail, du téléphone ou de l'adresse, OAuth 2.0 permet de récupérer ces informations (stockées dans une partie protégée du token d’accès) grâce à la requête d’autorisation de OAuth 2.0.
Prenons l’exemple d’un token d’identité utilisé pour valider l’authentification d’un utilisateur.
Votre société utilise OAuth 2.0 avec Amazon Web Services (AWS) en tant que fournisseur d'identité, et single sign-on (SSO) pour authentifier les utilisateurs à plusieurs applications d’entreprises. Vous pouvez utiliser OpenID Connect comme SSO afin d'authentifier les utilisateurs sur toutes les API des différentes applications, sans avoir à répéter l’opération d’authentification plusieurs fois. Le token d’accès sert à valider les utilisateurs à travers plusieurs API et plateformes, rendant ainsi la gestion des authentifications simple et sécurisée.
C’est quoi la différence entre un token d’accès et un token d’identité ?
OAuth utilise des tokens d’accès car ils sont plus sécurisés que des cookies de session. Les tokens ne révèlent aucune information concernant les identifiants de l’utilisateur ou sa session. Les tokens d’accès disposent de noms d’utilisateurs et d'informations d’autorisation. Ces informations ne sont pas toujours des tokens JWT, et ne sont pas toujours encodées : leur sécurité n’est donc pas toujours garantie.
Les tokens d’identité sont des jetons JWT encodés avec Base64, via une clé privée fournie par le fournisseur d'identité. Ces tokens ne peuvent donc être décodés que sur permission du fournisseur d'identité !
Comment l’ajout d’OIDC modifie-t-il le workflow d’OAuth ?
Les seuls éléments qui peuvent subir des modifications sont les étapes 1 et 2 du workflow 2.0.
À l’étape 1, vous cliquez sur “Connectez-vous avec Facebook”. Le client vous renvoie alors vers le serveur d'autorisation de Facebook via une URL de redirection et un scope. Ce scope est destiné à OIDC, et définit des claims spécifiques réalisés par l’application client.
À l’étape 3 du workflow d’ OAuth 2.0, le client transmet le code d’autorisation au serveur d’autorisation de Facebook, en échange d’un token d’accès. Avec OIDC, un token d’accès est retourné au client avec un token d’identité. Ce dernier contient les informations du claim requises.
Vous savez maintenant comment fonctionne l’autorisation OAuth 2.0, et vous connaissez les avantages de l’ajouter à OIDC !
En résumé
OAuth est un protocole d’autorisation permettant de profiler une connexion sécurisée, en utilisant des jetons d’encodage sans état pour sécuriser les sessions des utilisateurs sur une application web.
OAuth travaille avec des fournisseurs d’identité, qui gèrent les authentifications. OAuth gère l’autorisation des permissions par l’utilisateur, ainsi que les serveurs du fournisseur d’identité.
OIDC peut être ajouté au scope (permission), pour que le client identifie l'utilisateur avec un token d’identité et des données personnelles vérifiées additionnelles, appelées claims.
Au prochain chapitre, nous ajouterons le formulaire de connexion par défaut en utilisant GitHub, et apprendrons à l’ajouter à OIDC.
