Remarque perev. : Ce super article de blog Okta explique OAuth et OIDC (OpenID Connect) comment cela fonctionne. Ces connaissances seront utiles aux développeurs, aux administrateurs système et même aux «utilisateurs ordinaires» d'applications Web populaires qui échangent très probablement également des données sensibles avec d'autres services.À l'âge de pierre d'Internet, le partage d'informations entre les services était facile. Vous avez simplement donné votre nom d'utilisateur et votre mot de passe d'un service à un autre afin qu'il entre dans votre compte et reçoive toutes les informations dont il avait besoin.
"Fournissez votre compte bancaire." «Nous promettons que tout ira bien avec le mot de passe et l'argent. C'est honnêtement honnête! »* Hee hee *Horreur! Personne ne devrait jamais exiger d'un utilisateur qu'il partage son nom d'utilisateur et son mot de passe, ses
informations d'identification , avec un autre service. Il n'y a aucune garantie que l'organisation derrière ce service gardera les données en sécurité et ne collectera pas plus d'informations personnelles que nécessaire. Cela peut sembler sauvage, mais certaines applications utilisent toujours cette pratique!
Aujourd'hui, il existe une norme unique qui permet à un service d'utiliser en toute sécurité les données d'un autre. Malheureusement, ces normes utilisent beaucoup de jargon et de termes, ce qui complique leur compréhension. Le but de ce matériel est d'expliquer comment ils fonctionnent avec des illustrations simples (pensez-vous que mes dessins ressemblent à un bébé barbouilleur? Eh bien, d'accord!).
Soit dit en passant, ce guide est également disponible en format vidéo:
Mesdames et messieurs, rencontrez: OAuth 2.0
OAuth 2.0 est une norme de sécurité qui permet à une application d'obtenir la permission d'accéder aux informations d'une autre application. La séquence d'étapes pour la délivrance d'une autorisation
(autorisation ) est souvent appelée
autorisation ou même
autorisation déléguée . En utilisant cette norme, vous autorisez une application à lire des données ou à utiliser les fonctions d'une autre application en votre nom sans lui donner votre mot de passe. Classe!
Par exemple, imaginez que vous ayez découvert un site appelé «
Terrible Pun of the Day» et décidé de vous y inscrire pour recevoir quotidiennement des jeux de mots sous forme de SMS sur le téléphone. Vous avez vraiment aimé le site et vous avez décidé de le partager avec tous vos amis. Après tout, des calembours terribles comme tout le monde, non?
"Jeu de mots du jour infructueux: avez-vous entendu parler d'un gars qui a perdu la moitié gauche de son corps?" Maintenant, il a toujours raison! »(Traduction approximative, car l'original a son propre jeu de mots, - environ Transl.)Il est clair qu'écrire à chaque personne de la liste de contacts n'est pas une option. Et, si vous êtes même un peu comme moi, vous ferez tout pour éviter un travail inutile. Heureusement, le jeu de mots Terrible du jour peut inviter tous vos amis seul! Pour ce faire, il vous suffit de lui donner accès à l'e-mail des contacts - le site lui-même leur enverra des invitations (disques OAuth)!
"Tout le monde aime les jeux de mots!" - Déjà connecté? - Vous voulez partager le site Web Terrible Pun of the Day avec votre liste de contacts? - Merci! Maintenant, chaque jour, nous enverrons des rappels à tous ceux que vous connaissez jusqu'à la fin des temps! Tu es le meilleur ami! "- Choisissez votre service de messagerie.
- Si nécessaire, accédez au site de messagerie et connectez-vous à votre compte.
- Donnez à Terrible Pun of the Day la permission d'accéder à vos contacts.
- Retournez au site Web Terrible Pun of the Day.
Si vous changez d'avis, les applications qui utilisent OAuth fournissent également un moyen de révoquer l'accès. Après avoir décidé que vous ne souhaitez plus partager vos contacts avec Terrible Pun of the Day, vous pouvez vous rendre sur le site de messagerie et supprimer le site contenant des jeux de mots de la liste des applications autorisées.
OAuth Stream
Nous venons de passer par ce qu'on appelle communément le
flux OAuth. Dans notre exemple, ce flux se compose d'étapes visibles, ainsi que de plusieurs étapes invisibles, dans lesquelles deux services s'accordent sur un échange sécurisé d'informations. L'exemple précédent Terrible Pun of the Day utilise le flux OAuth 2.0 le plus courant, connu sous le
nom de flux «code d'autorisation» .
Avant de nous plonger dans les détails d'OAuth, parlons de la signification de certains termes:
- Propriétaire de la ressource :
C'est toi! Vous êtes propriétaire de vos identifiants, de vos données et gérez toutes les actions pouvant être effectuées avec vos comptes. - Client :
Une application (par exemple, le service Terrible Pun of the Day) qui souhaite accéder ou effectuer certaines actions au nom du propriétaire de la ressource . - Serveur d'autorisation :
Une application qui connaît le propriétaire de la ressource et dans laquelle le propriétaire de la ressource a déjà un compte. - Serveur de ressources :
Une interface de programmation d'application (API) ou un service qu'un client souhaite utiliser au nom du propriétaire de la ressource . - Rediriger l'URI :
Le lien par lequel le serveur d’autorisations redirige le propriétaire de la ressource vers «après avoir accordé l’autorisation au client » à Elle est parfois appelée URL de rappel. - Type de réponse :
Le type d'informations que le client attend de recevoir. Le type de réponse le plus courant est le code, c'est-à-dire que le client s'attend à recevoir un code d'autorisation . - Portée :
Il s'agit d'une description détaillée des autorisations dont le client a besoin, telles que l'accès aux données ou l'exécution de certaines actions. - Consentement :
Le serveur d'autorisation prend les étendues demandées par le client et demande au propriétaire de la ressource s'il est prêt à accorder au client les autorisations appropriées. - ID client :
Cet ID est utilisé pour identifier le client sur le serveur d'autorisation . - Secret client :
Il s'agit d'un mot de passe connu uniquement du client et du serveur d'autorisation . Il leur permet d'échanger des informations en toute confidentialité. - Code d'autorisation :
Code temporaire à court terme que le client fournit au serveur d'autorisation en échange d'un jeton d'accès . - Jeton d'accès :
Clé que le client utilisera pour communiquer avec le serveur de ressources . Il s'agit d'un badge ou d'une carte-clé qui donne au client l' autorisation de demander des données ou d'effectuer des actions sur le serveur de ressources en votre nom.
Remarque : parfois, le serveur d'autorisation et le serveur de ressources sont le même serveur. Cependant, dans certains cas, il peut s'agir de serveurs différents, n'appartenant même pas à la même organisation. Par exemple, un serveur d'autorisation peut être un service tiers auquel le serveur de ressources fait confiance.
Maintenant que nous nous sommes familiarisés avec les concepts de base d'OAuth 2.0, revenons à notre exemple et examinons de plus près ce qui se passe dans le flux OAuth.
- Vous, propriétaire de la ressource , souhaitez fournir à Terrible Pun of the Day ( Client ) l'accès à vos contacts afin qu'il puisse envoyer des invitations à tous vos amis.
- Le client redirige le navigateur vers la page du serveur d'autorisation et inclut l' ID client , l' URI de redirection , le type de réponse et une ou plusieurs étendues (autorisations) dont il a besoin dans la demande.
- Le serveur d'autorisation vous vérifie, si nécessaire, en demandant un nom d'utilisateur et un mot de passe.
- Le serveur d'autorisation affiche un formulaire de consentement avec une liste de toutes les étendues demandées par le client . Vous acceptez ou refusez.
- Le serveur d'autorisation vous redirige vers le site du client en utilisant l' URI de redirection avec le code d'autorisation .
- Le client communique directement avec le serveur d'autorisation (en contournant le navigateur du propriétaire de la ressource ) et envoie en toute sécurité l' ID client, le secret client et le code d'autorisation .
- Le serveur d'autorisation valide les données et répond avec un jeton d'accès .
- Le client peut désormais utiliser le jeton d'accès pour envoyer une demande au serveur de ressources afin d'obtenir une liste de contacts.
ID client et secret
Bien avant d'avoir autorisé Terrible Pun of the Day à accéder à vos contacts, le client et le serveur d'autorisation ont établi une relation de travail. Le serveur d'autorisations a généré l'ID client et le secret client (parfois appelés
ID d' application et
secret d'application ) et les a envoyés au client pour une interaction ultérieure au sein d'OAuth.
«Bonjour! J'aimerais travailler avec toi! - Oui, pas question! Voici votre identifiant client et votre secret! »Le nom indique que le secret client doit être gardé secret afin que seuls le client et le serveur d'autorisation le sachent. En effet, c'est avec son aide que le serveur d'autorisation confirme la vérité du Client.
Mais ce n'est pas tout ... Veuillez accueillir OpenID Connect!
OAuth 2.0 est conçu pour une
autorisation uniquement - pour fournir un accès aux données et fonctionnalités d'une application à une autre.
OpenID Connect (OIDC) est une couche mince au-dessus d'OAuth 2.0 qui ajoute des informations sur le nom d'utilisateur et le profil de l'utilisateur connecté au compte. L'organisation de la session de connexion est souvent appelée
authentification et les informations sur l'utilisateur connecté (c'est-à-dire sur le
propriétaire de la
ressource ) sont appelées
identité . Si le serveur d'autorisation prend en charge OIDC, il est parfois appelé
fournisseur d'identité , car il fournit au
client des informations sur le
propriétaire de la
ressource .
OpenID Connect vous permet d'implémenter des scénarios lorsqu'une seule connexion peut être utilisée dans de nombreuses applications - cette approche est également connue sous le nom de
connexion unique (SSO). Par exemple, une application peut prendre en charge l'intégration SSO avec les réseaux sociaux tels que Facebook ou Twitter, permettant aux utilisateurs d'utiliser un compte qu'ils ont déjà et qu'ils préfèrent utiliser.
Le flux OpenID Connect ressemble à celui d'OAuth. La seule différence est que dans la demande initiale, la portée spécifique utilisée est
openid et le
client reçoit finalement le
jeton d'accès et le
jeton d'identification .
Tout comme dans le flux OAuth, le
jeton d'accès dans OpenID Connect est une valeur non comprise par le
client . Du point de vue du
client , le
jeton d'accès représente une certaine chaîne de caractères qui est transmise avec chaque demande au
serveur de ressources , qui détermine si le jeton est valide.
Le jeton d'identification est complètement différent.
Le jeton d'identification est un JWT
ID Token est une chaîne de caractères spécialement formatée connue sous le nom de JSON Web Token ou JWT
(parfois les jetons JWT sont prononcés "jots") . JWT peut sembler être un charabia incompréhensible pour les étrangers, mais le
client peut extraire diverses informations du JWT, telles que l'ID, le nom d'utilisateur, l'heure de connexion au compte, la date d'expiration du
jeton d'ID et les tentatives d'intervenir dans le JWT. Les données à l'intérieur de l'
ID de jeton sont appelées une
réclamation .
Dans le cas d'OIDC, il existe également un moyen standard permettant au
client de demander des informations supplémentaires sur l'
identité au
serveur d'autorisation , par exemple, une adresse e-mail à l'aide du
jeton d'accès .
En savoir plus sur OAuth et OIDC.
Nous avons donc brièvement passé en revue le fonctionnement d'OAuth et d'OIDC. Prêt à creuser plus profondément? Voici des ressources supplémentaires pour vous aider à en savoir plus sur OAuth 2.0 et OpenID Connect:
Comme d'habitude, n'hésitez pas à commenter. Pour rester au courant de nos dernières innovations, abonnez-vous à
Twitter et
YouTube d'Okta pour les développeurs!
PS du traducteur
Lisez aussi dans notre blog: