Noter. trad.: Cet excellent article d'Okta explique comment OAuth et OIDC (OpenID Connect) fonctionnent de manière simple et claire. Cette connaissance sera utile aux développeurs, aux administrateurs système et même aux "utilisateurs réguliers" d'applications Web populaires, qui échangent très probablement également des données confidentielles avec d'autres services.
À l'âge de pierre d'Internet, le partage d'informations entre les services était facile. Vous avez simplement donné votre identifiant 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.
"Donnez-moi votre compte bancaire." "Nous promettons que tout ira bien avec le mot de passe et l'argent. C'est honnête, honnête !" *hihi*
Horreur! Personne ne devrait jamais exiger qu'un utilisateur partage un nom d'utilisateur et un mot de passe, crédits, 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 fou, mais certaines applications utilisent encore cette pratique !
Il existe aujourd'hui 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 leur fonctionnement à l'aide d'illustrations simples (Pensez-vous que mes dessins ressemblent à des barbouillages d'enfants ? Ah bon !).
Au fait, ce guide est également disponible en format vidéo :
Mesdames et messieurs, bienvenue : OAuth 2.0
est une norme de sécurité qui permet à une application d'obtenir l'autorisation d'accéder aux informations d'une autre application. Séquence d'étapes pour la délivrance d'un permis [autorisation] (ou consentement [consentement]) appelle souvent autorisation [autorisation] ou autorisation déléguée [autorisation déléguée]. Avec 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!
A titre d'exemple, disons que vous découvrez un site appelé "Unlucky Pun of the Day" [Terrible jeu de mot du jour] et a décidé de s'y inscrire afin de 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, tout le monde aime les jeux de mots effrayants, n'est-ce pas ?
"Jeu de mots malheureux du jour : vous avez entendu parler du type 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 - traduction approximative)
Il est clair qu'écrire à chaque personne de la liste de contacts n'est pas une option. Et, si vous êtes ne serait-ce qu'un peu comme moi, alors vous ferez tout pour éviter les travaux inutiles. Heureusement, Terrible Pun of the Day peut inviter tous vos amis à lui tout seul ! Pour cela, il vous suffit d'ouvrir l'accès à la messagerie de vos contacts - le site lui-même leur enverra des invitations (règles OAuth) !
« Tout le monde aime les jeux de mots ! - Déjà connecté? "Voulez-vous autoriser le site Terrible Pun of the Day à accéder à votre liste de contacts ? - Merci! A partir de maintenant, nous enverrons des rappels tous les jours à tous ceux que vous connaissez, jusqu'à la fin des temps ! Tu es le meilleur ami!"
- Choisissez votre service de messagerie.
- Si nécessaire, rendez-vous sur le site de messagerie et connectez-vous à votre compte.
- Autorisez Terrible Pun of the Day à accéder à vos contacts.
- Retournez sur le site Terrible Pun of the Day.
Si vous changez d'avis, les applications utilisant OAuth offrent également un moyen de révoquer l'accès. Une fois que vous décidez que vous ne souhaitez plus partager de contacts avec Terrible Pun of the Day, vous pouvez vous rendre sur le site de messagerie et supprimer le site de jeux de mots de la liste des applications autorisées.
Flux OAuth
Nous venons de traverser ce qu'on appelle habituellement couler [couler] OAuth. Dans notre exemple, ce flux est constitué 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 de Terrible Pun of the Day utilise le flux OAuth 2.0 le plus courant, connu sous le nom de flux "code d'autorisation". [flux "code d'autorisation"].
Avant de plonger dans les détails du fonctionnement d'OAuth, parlons de la signification de certains termes :
- Propriétaire de la ressource:
C'est toi! Vous êtes propriétaire de vos informations d'identification, de vos données et contrôlez toutes les activités pouvant être effectuées sur vos comptes. - Client:
Une application (par exemple, le service Terrible Pun of the Day) qui souhaite accéder ou effectuer certaines actions au nom de Propriétaire de la ressource'UN. - Serveur d'autorisation:
L'appli qui sait Propriétaire de la ressource'a et dans lequel tu Propriétaire de la ressource'a déjà un compte. - Serveur de ressources:
Interface de programmation d'application (API) ou service qui Client veut utiliser au nom Propriétaire de la ressource'UN. - URI de redirection:
Le lien qui Serveur d'autorisation va rediriger Propriétaire de la ressource'et après avoir accordé l'autorisation Client'à. Elle est parfois appelée "URL de rappel". - Type de réponse:
Le type d'informations que l'on s'attend à recevoir Client. Le plus commun Type de réponse'ohm est le code, c'est-à-dire Client s'attend à recevoir Code d'autorisation. - Domaine:
Il s'agit d'une description détaillée des autorisations requises Client'y, comme l'accès aux données ou l'exécution de certaines actions. - Consentement
:
Serveur d'autorisation prend Scopesdemandé Client'om, et demande Propriétaire de la ressource'a, est-il prêt à fournir Client'avoir les autorisations appropriées. - identité du client:
Cet ID est utilisé pour identifier Client'un sur Serveur d'autorisation'e. - Secret client:
C'est le mot de passe qui n'est connu que Client'toi et Serveur d'autorisation'à. Cela leur permet de partager des informations en privé. - Code d'autorisation:
Code temporaire à courte durée de validité, qui Client fournit Serveur d'autorisation'y en échange de Jeton d'accès. - Jeton d'accès:
La clé que le client utilisera pour communiquer avec Serveur de ressources'om. Une sorte de badge ou de carte-clé qui fournit Client'avoir la permission de demander des données ou d'effectuer des actions sur Serveur de ressources'e en votre nom.
Noter: 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, même s'ils n'appartiennent pas à la même organisation. Par exemple, le serveur d'autorisation peut être un service tiers approuvé par le serveur de ressources.
Maintenant que nous avons couvert 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, vous souhaitez fournir le service Terrible Pun of the Day (Clienty) accéder à vos contacts afin qu'ils puissent envoyer des invitations à tous vos amis.
- Client redirige le navigateur vers la page Serveur d'autorisation'a et inclure dans la requête identité du client, URI de redirection, Type de réponse et un ou plusieurs Scopes (autorisations) dont il a besoin.
- Serveur d'autorisation vous vérifie, en vous demandant un nom d'utilisateur et un mot de passe si nécessaire.
- Serveur d'autorisation affiche un formulaire Consentement (confirmations) avec une liste de tous Scopesdemandé Client'om. Vous acceptez ou refusez.
- Serveur d'autorisation vous redirige vers le site Client'a, en utilisant URI de redirection avec Code d'autorisation (Code d'autorisation).
- Client communique directement avec Serveur d'autorisation'ohm (en contournant le navigateur Propriétaire de la ressource'a) et envoie en toute sécurité identité du client, Secret client и Code d'autorisation.
- Serveur d'autorisation vérifie les données et répond avec Jeton d'accès'om (jeton d'accès).
- Maintenant Client peut utiliser Jeton d'accès envoyer une demande à Serveur de ressources pour obtenir une liste de contacts.
ID client et secret
Bien avant que vous autorisiez Terrible Pun of the Day à accéder à vos contacts, le client et le serveur d'autorisation avaient établi une relation de travail. Le serveur d'autorisation a généré l'ID client et le secret client (parfois appelés ID de l'application и Secret d'application) et les a envoyés au client pour une interaction ultérieure au sein d'OAuth.
"- Bonjour! J'aimerais travailler avec vous ! - Bien sûr, pas de problème ! Voici votre identifiant client et votre secret ! »
Le nom implique que le secret du client doit être gardé secret afin que seuls le client et le serveur d'autorisation le sachent. Après tout, c'est avec son aide que le Serveur d'Autorisation confirme la véracité du Client.
Mais ce n'est pas tout... Veuillez accueillir OpenID Connect !
OAuth 2.0 est uniquement conçu pour autorisation - de permettre l'accès aux données et fonctions d'une application à une autre. (OIDC) est une fine couche au-dessus d'OAuth 2.0 qui ajoute les informations de connexion et de profil de l'utilisateur connecté au compte. L'organisation d'une session de connexion est souvent appelée authentification [authentification], et des informations sur l'utilisateur qui s'est connecté au système (c'est-à-dire sur Propriétaire de la ressource'e), - données personnelles [identité]. Si le serveur d'autorisation prend en charge OIDC, il est parfois appelé fournisseur de données personnelles [fournisseur d'identité]parce qu'il fournit Client'avoir des informations sur Propriétaire de la ressource'e.
OpenID Connect vous permet de mettre en œuvre des scénarios dans lesquels une seule connexion peut être utilisée dans plusieurs applications - cette approche est également connue sous le nom de authentification unique (SSO). Par exemple, une application peut prendre en charge l'intégration SSO avec des réseaux sociaux tels que Facebook ou Twitter, permettant aux utilisateurs d'utiliser un compte qu'ils possèdent déjà et qu'ils préfèrent utiliser.
Le flux (flux) OpenID Connect ressemble à celui d'OAuth. La seule différence est que dans la requête principale, la portée spécifique utilisée est openid, - UN Client devient finalement comme Jeton d'accèsEt Jeton d'identification.
Tout comme dans le flux OAuth, Jeton d'accès dans OpenID Connect, il s'agit d'une valeur qui n'est pas claire Client'à. Du point de vue Client'UN Jeton d'accès représente une chaîne de caractères transmise avec chaque demande à Serveur de ressources'y, qui détermine si le jeton est valide. Jeton d'identification représente une chose complètement différente.
Le jeton d'identification est un JWT
Jeton d'identification est une chaîne de caractères spécialement formatée appelée JSON Web Token ou JWT (parfois les jetons JWT sont prononcés comme "jots"). Pour les observateurs extérieurs, JWT peut sembler un charabia incompréhensible, mais Client peut extraire diverses informations du JWT, telles que l'ID, le nom d'utilisateur, l'heure de connexion, la date d'expiration Jeton d'identification'a, la présence de tentatives d'interférer avec le JWT. Données à l'intérieur Jeton d'identification'a sont appelés applications [réclamations].
Dans le cas de l'OIDC, il existe également un moyen standard par lequel Client peut demander des informations supplémentaires sur la personne [identité] à partir de Serveur d'autorisation'a, par exemple, une adresse e-mail utilisant 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 toujours, n'hésitez pas à commenter. Pour être tenu au courant de nos dernières actualités, abonnez-vous à и Okta pour les développeurs !
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com