Guide illustré sur OAuth et OpenID Connect

Note de traduction.Dans ce magnifique document proposé par Okta, les principes de fonctionnement d'OAuth et d'OIDC (OpenID Connect) sont présentés de manière simple et visuelle. Ces connaissances seront utiles aux développeurs, aux administrateurs systémiques et même aux « utilisateurs lambda » des applications web populaires, qui échangent probablement également des données sensibles avec d'autres services.

À l'époque des débuts d'internet, partager des informations entre services était facile. Il suffisait de donner son identifiant et son mot de passe d'un service à un autre pour qu'il puisse accéder à votre compte et obtenir toutes les informations nécessaires.

« Donnez votre compte bancaire. » — « Nous vous promettons que votre mot de passe et votre argent seront en sécurité. C'est promis, juré ! » *hi hi*

Horreur ! Personne ne devrait jamais demander à un utilisateur de partager son identifiant 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 conservera les données en toute sécurité et ne collectera pas plus d'informations personnelles que nécessaire. Cela peut sembler fou, mais certaines applications continuent d'utiliser de telles pratiques !

Aujourd'hui, il existe une norme unique permettant à un service d'accéder en toute sécurité aux données d'un autre. Malheureusement, ces normes sont truffées de jargon et de termes techniques qui compliquent leur compréhension. L'objectif de ce document est d'expliquer leur fonctionnement à l'aide d'illustrations simples (Pensez-vous que mes dessins ressemblent à des gribouillages d'enfants ? Eh bien, tant pis !).

D'ailleurs, ce guide est également disponible au format vidéo :

Mesdames et messieurs, voici : OAuth 2.0

OAuth 2.0 — c'est une norme de sécurité qui permet à une application d'obtenir une autorisation pour accéder à des informations dans une autre application. La séquence d'actions pour accorder l'autorisation [permission] ou de consentement [consent]) est souvent appelée autorisation [authorization] ou même autorisation déléguée [delegated authorization]. Grâce à cette norme, vous autorisez une application à lire des données ou à utiliser des fonctionnalités d'une autre application en votre nom, sans lui communiquer votre mot de passe. Génial !

Prenons l'exemple d'un site intitulé « Le Pire Calembour du Jour » [Terrible Pun of the Day] Vous avez décidé de vous inscrire pour recevoir quotidiennement des jeux de mots sous forme de messages texte sur votre téléphone. Vous avez beaucoup aimé le site et avez voulu le partager avec tous vos amis, car tout le monde aime les punèses, n'est-ce pas ?

« Mauvais jeu de mots du jour : Avez-vous entendu parler de ce gars qui a perdu la moitié gauche de son corps ? Maintenant, il a toujours raison ! » (traduction approximative, car il y a un jeu de mots dans l'original — note de traduction)

Il est clair qu'il n'est pas pratique d'écrire à chaque personne de votre liste de contacts. Et, si vous êtes ne serait-ce qu'un peu comme moi, vous ferez tout pour éviter de faire du travail supplémentaire. Heureusement, Terrible Pun of the Day peut inviter tous vos amis pour vous ! Il vous suffit d'ouvrir l'accès à l'e-mail de vos contacts — le site enverra automatiquement des invitations (OAuth gère ça) !

« Tout le monde aime les jeux de mots ! - Êtes-vous déjà connecté ? - Voulez-vous donner accès au site Terrible Pun of the Day à votre liste de contacts ? - Merci ! Maintenant, nous enverrons chaque jour des rappels à tous ceux que vous connaissez, jusqu'à la fin des temps ! Vous êtes le meilleur ami ! »

1. Choisissez votre service de messagerie.
2. Si nécessaire, rendez-vous sur le site de votre messagerie et connectez-vous à votre compte.
3. Autorisez le site Terrible Pun of the Day à accéder à vos contacts.
4. Retournez sur le site Terrible Pun of the Day.

Dans le cas où vous changeriez d'avis, les applications utilisant OAuth fournissent également un moyen d'annuler l'accès. Si vous décidez de ne plus vouloir partager vos contacts avec Terrible Pun of the Day, vous pouvez vous rendre sur le site de votre messagerie et supprimer le site de jeux de mots de la liste des applications autorisées.

Flux OAuth

Nous venons de passer par ce que l'on appelle généralement un flux [flow] OAuth. Dans notre exemple, ce flux se compose d'étapes visibles, ainsi que de plusieurs étapes invisibles, au cours desquelles les deux services s'accordent sur un échange sécurisé d'informations. Dans l'exemple précédent avec Terrible Pun of the Day, c'est le flux OAuth 2.0 le plus courant, connu sous le nom de flux « avec code d'autorisation » [«authorization code» flow].

Avant de plonger dans les détails du fonctionnement d'OAuth, parlons du sens de certains termes :

• Propriétaire de la ressource:

  
  
  C'est vous ! Vous possédez vos identifiants, vos données et gérez toutes les actions qui peuvent être effectuées sur vos comptes.

• Client:

  
  
  Une application (par exemple, le service Terrible Pun of the Day) qui souhaite accéder ou effectuer des actions au nom de Propriétaire de la ressource‘a.

• Serveur d'Autorisation:

  
  
  Une application qui sait Propriétaire de la ressource‘a et où Propriétaire de la ressource‘a déjà un compte.

• Serveur de Ressources:

  
  
  Une interface de programmation d'application (API) ou un service que Client veut utiliser au nom de Propriétaire de la ressource‘a.

• URI de Redirection:

  
  
  Le lien par lequel Serveur d'Autorisation redirigera Propriétaire de la ressource‘a après avoir accordé l'autorisation Client‘u. Parfois, cela s'appelle « URL de Retour » (« Callback URL »).

• Type de Réponse:

  
  
  Le type d'information que l'on s'attend à recevoir Client. Le plus courant Type de Réponse‘om est un code, c'est-à-dire Client s'attend à recevoir Code d'Autorisation.

• Portée:

  
  
  C'est une description détaillée des permissions requises par Client‘u, comme l'accès aux données ou l'exécution de certaines actions.

• Consentement:

  
  
  Serveur d'Autorisation prend Les Portées, demandées par Client‘om, et demande à Propriétaire de la ressource‘a s'il est prêt à accorder Client‘u les permissions appropriées.

• ID Client:

  
  
  Cet ID est utilisé pour identifier Client‘a sur Serveur d'Autorisation‘e.

• Secret Client:

  
  
  C'est un mot de passe qui est connu uniquement de Client‘u et Serveur d'Autorisation‘u. Il leur permet d'échanger des informations de manière confidentielle.

• Code d'Autorisation:

  
  
  Un code temporaire avec une durée de validité limitée, que Client propose Serveur d'Autorisation‘u en échange de Jeton d'Accès.

• Jeton d'Accès:

  
  
  Une clé que le client utilisera pour communiquer avec Serveur de Ressources‘om. C'est comme un badge ou une carte magnétique, donnant Client‘u l'autorisation de demander des données ou d'exécuter des actions sur Serveur de Ressources‘e en votre nom.

Remarque: parfois, le Serveur d'Autorisation et le Serveur de Ressources sont le même serveur. Cependant, dans certains cas, ce peuvent être des serveurs différents, qui n'appartiennent même pas à la même organisation. Par exemple, le Serveur d'Autorisation peut être un service tiers de confiance pour le Serveur de Ressources.

Maintenant que nous nous sommes familiarisés avec les concepts de base de OAuth 2.0, revenons à notre exemple et examinons en détail ce qui se passe dans le flux OAuth.

1. Vous, Propriétaire de la ressource, souhaitez accorder à la service Terrible Pun of the Day (Client‘u) accès à vos contacts afin qu'il puisse envoyer des invitations à tous vos amis.
2. Client redirige le navigateur vers la page de Serveur d'Autorisation‘a et inclut dans la demande ID Client, URI de Redirection, Type de Réponse une ou plusieurs Les Portées (permissions) dont il a besoin.
3. Serveur d'Autorisation vérifie votre identité, en demandant votre nom d'utilisateur et votre mot de passe si nécessaire.
4. Serveur d'Autorisation affiche un formulaire Consentement (de confirmation) avec la liste de toutes les Les Portées, demandées par Client‘om. Vous acceptez ou refusez.
5. Serveur d'Autorisation vous redirige vers le site de Client‘a, en utilisant URI de Redirection avec Code d'Autorisation (le code d'autorisation).
6. Client se connecte directement à Serveur d'Autorisation‘om (contournant le navigateur Propriétaire de la ressource‘a) et envoie des informations de manière sécurisée. ID Client, Secret Client et Code d'Autorisation.
7. Serveur d'Autorisation vérifie les données et répond avec Jeton d'Accès‘un (jeton d'accès).
8. Maintenant Client peut être utilisé Jeton d'Accès pour envoyer une demande à Serveur de Ressources afin d'obtenir une liste de contacts.

Client ID et Secret

Bien avant que vous n'ayez donné à Terrible Pun of the Day l'accès aux contacts, le Client et le Serveur d'Autorisation avaient établi une relation de travail. Le Serveur d'Autorisation a généré le Client ID et le Client Secret (parfois appelés App ID et App Secret) et les a envoyés au Client pour une interaction ultérieure dans le cadre d'OAuth.

«— Salut ! Je voudrais travailler avec toi ! — Pas de souci ! Voici tes Client ID et Secret ! »

Le nom suggère que le Client Secret doit être gardé secret, afin qu'il ne soit connu que du Client et du Serveur d'Autorisation. En effet, c'est avec cela que le Serveur d'Autorisation confirme l'authenticité du Client.

Mais ce n'est pas tout… Veuillez accueillir OpenID Connect !

OAuth 2.0 est conçu uniquement pour l'autorisation — pour fournir l'accès aux données et aux fonctionnalités d'une application à une autre. OpenID Connect (OIDC) — est une couche mince au-dessus d'OAuth 2.0, ajoutant des informations sur la connexion et le profil de l'utilisateur qui s'est connecté au compte. L'organisation de la session de connexion est souvent appelée authentification [authentication], et les informations sur l'utilisateur connecté (c'est-à-dire sur Propriétaire de la ressource‘lui), — données personnelles [identity]. Si le Serveur d'Autorisation prend en charge OIDC, il est parfois appelé fournisseur d'identité [identity provider], car il fournit Client‘lui des informations sur Propriétaire de la ressource‘e.

OpenID Connect permet d'implémenter des scénarios où une seule connexion peut être utilisée dans plusieurs applications, — cette approche est également connue sous le nom de single sign-on (SSO). Par exemple, une application peut prendre en charge l'intégration SSO avec des réseaux sociaux comme 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 OpenID Connect ressemble à celui d'OAuth. La seule différence est que dans la demande initiale, l'espace spécifique utilisé est openid, — et Client il obtient finalement Jeton d'Accès, et via le ID Token.

Tout comme dans le flux OAuth, Jeton d'Accès dans OpenID Connect — c'est une certaine valeur, incompréhensible pour Client‘lui. Du point de vue de Client‘lui Jeton d'Accès représente une chaîne de caractères qui est transmise avec chaque demande à Serveur de Ressources‘lui, et celui-ci détermine si le jeton est valide. le ID Token représente quelque chose de complètement différent.

ID Token — c'est un JWT

le ID Token — c'est une chaîne de caractères formatée d'une manière particulière, connue sous le nom de JSON Web Token ou JWT (parfois les jetons JWT sont prononcés comme « jots »). Pour les observateurs extérieurs, le JWT peut sembler être une sorte de charabia, mais Client il peut extraire du JWT diverses informations, telles que l'ID, le nom d'utilisateur, l'heure de connexion et la date d'expiration le ID Token‘a, la présence de tentatives d'intervention dans le JWT. Les données à l'intérieur le ID Token‘a sont appelées revendications [claims].

Dans le cas de l'OIDC, il existe également une méthode standard par laquelle Client vous pouvez demander des informations supplémentaires sur l'identité [identity] à partir de Serveur d'Autorisation‘a, par exemple, une adresse e-mail, en utilisant Jeton d'Accès.

Des informations supplémentaires sur OAuth et OIDC

Ainsi, nous avons brièvement examiné les principes de fonctionnement d'OAuth et d'OIDC. Prêt à approfondir ? Voici des ressources supplémentaires pour en savoir plus sur OAuth 2.0 et OpenID Connect :

• Qu'est-ce que OAuth ?
• Personne ne se soucie de OAuth ou OpenID Connect
• Implémentez le flux de code d'autorisation OAuth 2.0 avec PKCE
• Quel est le type de subvention OAuth 2.0 ?
• OAuth 2.0 depuis la ligne de commande
• Construisez une application Node.js sécurisée avec SQL Server

Comme d'habitude, n'hésitez pas à commenter. Pour rester informé de nos dernières nouveautés, abonnez-vous à Twitter et YouTube la société Okta pour les développeurs !

P.S. de l'auteur

Lisez aussi dans notre blog :

• «L'alphabet de la sécurité dans Kubernetes : authentification, autorisation, audit»;
• «Utilisateurs et autorisation RBAC dans Kubernetes»;
• «33+ outils pour la sécurité de Kubernetes»;
• «Sécurité pour les conteneurs Docker».

Source : habr.com