Normes d'identification modernes: OAuth 2.0, OpenID Connect, WebAuthn

Laisser ou ne pas laisser? Telle est la question…

Maintenant, sur de nombreux sites, nous voyons la possibilité de s'inscrire ou de se connecter en utilisant les réseaux sociaux, et certains sites proposent l'utilisation de clés de sécurité externes ou d'empreintes digitales. Qu'Est-ce que c'est? Des normes de sécurité bien conçues ou des implémentations propriétaires? Pouvons-nous faire confiance à ces technologies et les utiliser pour le développement de sites Web et dans la vie quotidienne? Faisons les choses correctement. Ainsi, il existe maintenant plusieurs normes et technologies pour identifier les utilisateurs d'OAuth 2.0, OpenID Connect, WebAuthn, SAML 2.0, Credential Management API, etc. Dans cet article, je vais parler des trois protocoles les plus prometteurs OAuth 2.0, OpenID Connect et WebAuthn. Et pour comprendre comment les mettre en pratique, nous ferons trois travaux de laboratoire. Nous utiliserons GitHub et Google comme plates-formes pour identifier les utilisateurs.sur lesquels la plupart ont des comptes.

image

OAuth 2.0


Commençons par le protocole OAuth 2.0 le plus célèbre. Il a été publié en 2012 en tant que RFC 6749: le cadre d'autorisation OAuth 2.0 .

En utilisant OAuth 2.0, un utilisateur permet à un site spécifique de recevoir ses données privées des réseaux sociaux, mais sans transférer ses identifiants / mots de passe sur le site. Par exemple, lorsque vous vous inscrivez sur un site via Facebook, vous donnez simplement à ce site la permission d'obtenir votre nom, votre adresse e-mail et d'autres données privées de Facebook.

Traitons de l'implémentation technique. Pour plus de simplicité, j'appellerai n'importe quel site qui stocke les informations d'identification des utilisateurs sur le réseau social. Et MySite nommera tout site ou application qui souhaite obtenir des données utilisateur du réseau social.

image

La norme définit les rôles suivants:

  • Resource Owner — , MySite .
  • Client ( MySite) — , Authorization Server Resource Server .
  • Authorization Server — / , .
  • Resource Server — , API. Authorization Server Resource Server .

Authorization flow


  • MySite :
  • MySite Name ( ), Homepage ( MySite) Callback (, )
  • Le rĂ©seau social donne l'ID client (parfois appelĂ© AppID) et le secret client.
  • L'ID dĂ©veloppeur doit ĂŞtre enregistrĂ© dans l'ID client et le secret client.

Maintenant, le processus lui-même. Les détails des implémentations spécifiques peuvent varier, mais la logique générale sera toujours la suivante:

image

  1. Le propriétaire de la ressource se connecte au client (MySite), sélectionne l'option «se connecter en utilisant le réseau social», le site redirige l'utilisateur vers le réseau social sur le serveur d'autorisation.
  2. Le serveur d'autorisation vérifie si l'utilisateur a une session active et, sinon, affiche le formulaire de connexion.
  3. Le propriétaire de la ressource entre son nom d'utilisateur / mot de passe et confirme que certaines données privées peuvent être utilisées par MySite, comme le nom d'utilisateur ou l'adresse e-mail.
  4. Le serveur d'autorisation vérifie l'utilisateur et redirige vers l'adresse de rappel avec le résultat de l'authentification et le «code d'autorisation»
  5. Client “Authorization Code”, Client ID Client Secret.
  6. Authorization Server “access token” JWT (JSON Web Token), . JWT “refresh token”, c .
  7. Client API, “access token”.
  8. Resource Server “access token” (, Authorization Server) .

OAuth 2.0 (GitHub)


Il existe de nombreuses instructions sur la façon de mettre en œuvre l'autorisation OAuth 2.0 à l'aide des réseaux sociaux. J'ai personnellement aimé l'article suivant: Authentification à l'aide de GitHub OAuth 2.0 avec NodeJS Il détaille les étapes et fournit un programme de test. Mais, pour vraiment comprendre l'algorithme, il vaut mieux passer par toutes les étapes avec vos mains (requêtes http du navigateur ou appels à curl). Aller.

Pour commencer, enregistrez votre application sur GitHub: github.com/settings/applications/new

Définissez les paramètres:


Pour l'autorisation de travailler sur son propre site, les adresses doivent être réelles, mais cela n'est pas nécessaire pour les travaux de laboratoire.

Obtenez de GitHub:

  • ID client: ab8ec08a620c2
  • Secret client: e6fdd52b0a99e8fbe76b05c1b7bb93c1e

Bien sûr, dans tous les travaux de laboratoire, toutes les valeurs sont fausses.

Voici Ă  quoi ressemble l'ID client et le secret sur le site Web de GitHub:

image

Maintenant, nous commençons l'autorisation. Nous pensons que l'étape 1 est déjà terminée: l'utilisateur s'est connecté à MySite et a sélectionné «Se connecter avec GitHub». L'étape 2 du flux d'appels est un appel au format REST:

https://github.com/login/oauth/authorize?client_id=ab8ec08a620c2


  • l'adresse est le point de connexion sur github
  • client_id est l'ID client Ă©mis lors de l'inscription

Ă€ la suite de cet appel, GitHub affiche une fenĂŞtre d'autorisation:

image

Étape 3: Entrez le login / mot de passe pour accéder à GitHub

Étape 4: GitHub redirige la demande vers la page d'accueil, dans cette demande, nous voyons le code:

http://MySite/home?code=a29b348f63d21

Il n'y a pas de site de travail à cette adresse, mais l'essentiel pour nous est de connaître le code envoyé pour former la prochaine étape 5:

https://github.com/login/oauth/access_token?client_id=ab8ec08a620c2&
client_secret=e6fdd52b0a99e8fbe76b05c1b7bb93c1e&
code=a29b348f63d21

  • l'adresse est le point de rĂ©ception du jeton d'accès sur GitHub
  • client_id est l'ID client Ă©mis lors de l'inscription
  • client_secret est un secret client Ă©mis lors de l'inscription
  • le code est le code qui vient d'ĂŞtre envoyĂ©

Étape 6: En réponse, jeton d'accès reçu:

access_token=31b71cbd372acdbb20ec1644b824f3dd0&scope=&token_type=bearer

Étape 7: insérez le access_token dans l'en-tête de la demande et appelez l'API GitHub:

curl -H "Authorization: token 31b71cbd372acdbb20ec1644b824f3dd0" https://api.github.com/user

Étape 8: En réponse, nous obtenons JSON avec des informations utiles sur moi que vous pouvez utiliser pour créer un profil sur MySite:

{
  "login": "AlexeySushkov",
  "html_url": "https://github.com/AlexeySushkov",
  "repos_url": "https://api.github.com/users/AlexeySushkov/repos",
  "name": "Alexey Sushkov",
  "blog": "http://sushkov.ru",
  "location": "St.Petersburg, Russia",
  "email": "alexey.p.sushkov@gmail.com",
 ..
}  

En fait, nous n'avons examiné qu'un seul scénario OAuth 2.0. Il existe plusieurs scénarios, chacun étant utilisé en fonction de l'application, des considérations de sécurité, de la méthode de déploiement, etc. Une description de tous les scénarios peut être trouvée, par exemple, ici: OAuth 2.0 en bref .

Openid connect


Avec OAuth 2.0 un peu compris. Voyons maintenant pourquoi nous avons besoin d'OpenID Connect, qui est un module complémentaire pour OAuth 2.0:

  • C OAuth 2.0 .. access token, . access token MySite. OpenID Connect — (identity). .
  • OpenID Connect “service discovery”. SSO (Single Sign-On), .

Regardons la norme du côté technique.

OpenID Connect (OIDC) est une norme OpenID ouverte développée par le consortium OpenID Foundation . OIDC étend OAuth 2.0 avec les fonctionnalités clés suivantes:

  • Le serveur d'autorisation, en plus du jeton d'accès et du jeton d'actualisation, renvoie un «jeton d'identité» (jeton d'identification). Il est contenu dans le mĂŞme JWT. Les informations suivantes peuvent ĂŞtre extraites du jeton ID: nom d'utilisateur, heure de connexion, date d'expiration du jeton ID. Les ID de jeton peuvent ĂŞtre transfĂ©rĂ©s entre les participants.
  • OIDC fournit une API supplĂ©mentaire qui vous permet de demander des informations sur l'utilisateur et ses sessions en cours.

Le diagramme d'interaction dans OpenID Connect ressemble à celui d'OAuth. La seule différence dans le contenu des demandes:

  • Dans la demande initiale de code, un attribut supplĂ©mentaire, scope = openid, est ajoutĂ©.
  • Ă€ la suite de l'algorithme, le client, en plus d'accĂ©der et d'actualiser le jeton, reçoit un ID de jeton.

OpenID Connect: Lab (Google)


Voyons maintenant ce que Google va nous faire plaisir sur ce sujet. Il y a des instructions détaillées pour configurer et utiliser OpenID Connect de Google et un bac à sable pour utiliser l'API Google : Google OAuth 2.0 Playground .

Ici, comme dans le cas d'OAuth 2.0, nous allons parcourir les étapes et regarder les données entrantes. De même, nous pensons que l'application est enregistrée, que l'ID client et le secret client sont reçus, l'étape 1 est passée. L'étape 2 du flux d'appels est un appel au format REST:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
scope=openid%20email&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
state=765439764

Google est un peu plus compliqué, car ils accordent plus d'attention à la sécurité:

  • l'adresse est le point de connexion sur Google
  • response_type = code - attendez-vous Ă  recevoir du code en rĂ©ponse
  • client_id - ID client Ă©mis lors de l'inscription
  • scope = openid email - Ă  quelles donnĂ©es voulons-nous accĂ©der
  • redirect_uri - redirect_uri spĂ©cifiĂ© lors de l'enregistrement de l'application
  • Ă©tat - le numĂ©ro gĂ©nĂ©rĂ© par le client, qui est transmis entre le client et AS pour se protĂ©ger contre les interfĂ©rences intrusives.

Étape 3: Il n'y a pas de formulaire de saisie de mot de passe, car J'étais déjà connecté à Google.

Étape 4: Google redirige la demande vers la page d'accueil, dans cette demande, nous voyons le code:

http://MySite?state=123&code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&scope=email+openid+https://www.googleapis.com/auth/userinfo.email&authuser=0&prompt=none

Comme dans le cas de GitHub, il n'y a pas de site de travail à cette adresse, mais ce n'est pas nécessaire, l'essentiel pour nous est de connaître le code afin de former la prochaine étape 5. C'est aussi un peu plus compliqué, car Google requiert une demande POST, pas un GET:

curl -d "code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
client_secret=HMVctrTicW6RC1Q8T&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
grant_type=authorization_code" 
-H "Content-Type: application/x-www-form-urlencoded" -X POST https://oauth2.googleapis.com/token

  • l'adresse est le point de rĂ©ception des jetons sur Google
  • le code est le code qui vient d'ĂŞtre envoyĂ©
  • client_id est l'ID client Ă©mis lors de l'inscription
  • client_secret est un secret client Ă©mis lors de l'inscription
  • grant_type = autorisation_code - la seule valeur valide de la norme

Étape 6: En réponse, vous avez reçu access_token et id_token:

{
  "access_token": "ya29.Il_AB0KeKnjBJx0dhjm2nCLt1B-Mq0aQBW5T302JnlZfsxW1AXqLFfDJZRMi2R2WKG4OX4msKLjx4E4CSl4G_4ajAy3aqrf4pM0ic0jJr092pA67H9aktJktCbx",
  "expires_in": 3327,
  "scope": "openid https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1
………………………………_…………………………………………………….._4mUTiMNSAHljap1hLD2hAzgOZWuQ"
}

Que faire maintenant de cette richesse?

Étape 7: Avec access_token, tout est clair: nous l'incluons dans un appel API, par exemple GMail:

curl -H "Authorization: Bearer ya29.a0Adw1xeWvFoxHKNICHnV6vFFj5TZdPQVlYD98h8wjW95ZEbHVui_pk7HGRoq3Q7MlVLV23xkVM0yyjSP8ClSlvfUy3b_IqvKQW5Lvwj38QzJhee-aH1grerB4pRpMzn_FGueigG_RGI56pKPgFBTr49cpynQy" https://www.googleapis.com/gmail/v1/users/alexey.p.sushkov@gmail.com/profile

Étape 8: En réponse, nous obtenons JSON avec des informations utiles:

{
 "emailAddress": "alexey.p.sushkov@gmail.com",
 "messagesTotal": 372543,
...
}

Vérifions maintenant la déclaration selon laquelle id_token contient des informations pour authentifier l'utilisateur et maintenir la session. Pour ce faire, vous devez décrypter le contenu. La façon la plus simple de le faire est de contacter l'API Google à
oauth2.googleapis.com/tokeninfo et de spécifier l'id_token reçu comme paramètre:

https://oauth2.googleapis.com/tokeninfo?id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1NGMwZTIxOGIiLCJ0eXAiOi
………………………_……………………………...
SVQ5GQni3irfOzOXYEiqijp6TjGa_a-3jKcEsU5TbasZmAIejsdVcNy2_4mUTiMNSAHljap1hLD2hAzgOZWuQ

Got JSON:
{
  "iss": "https://accounts.google.com",
  "email": "alexey.p.sushkov@gmail.com",
  "email_verified": "true",
  "iat": "1583257010",
  "exp": "1583260610",
  "typ": "JWT"
...
}

Nous voyons que id_token contient des informations sur la connexion de l'utilisateur, l'heure de réception et la durée de vie du jeton. Nous pouvons conclure qu'OpenID Connect de Google fonctionne et qu'il peut être utilisé pour des scénarios pertinents.

Webauthn


API d'authentification Web (Ă©galement connue sous le nom de WebAuthn):

  • La norme permet aux utilisateurs de s'identifier sur des sites Web et dans des applications Ă  l'aide de clĂ©s de sĂ©curitĂ© externes (par exemple, des clĂ©s USB) ou par empreinte digitale et, par la suite, par d'autres donnĂ©es biomĂ©triques: visage, rĂ©tine.
  • — / «Public key cryptography». Public key cryptography — , . Private key ( ) , public key ( ) .
  • W3C (World Wide Web Consortium) FIDO, Google, Mozilla, Microsoft, Yubico. W3C HTTP, HTML, XML . WebAuthn. WebAuthn : Chrome, Firefox, Edge, Safari.


Par rapport Ă  OAuth 2.0, WebAuthn ajoute les rĂ´les suivants:

Authenticator : une clé de sécurité externe (support physique ou scanner d'empreintes digitales) qui vous permet d'authentifier un utilisateur à l'aide de diverses technologies, telles que BlueTooth / NFC / USB. Sert pour:

  • GĂ©nĂ©ration d'informations d'identification de clĂ© publique (paires de clĂ©s publiques / privĂ©es).
  • Authenticator stocke en toute sĂ©curitĂ© la clĂ© privĂ©e dans sa mĂ©moire
  • Passe la clĂ© publique aux systèmes externes
  • Signe les donnĂ©es avec une clĂ© privĂ©e et transfère le rĂ©sultat vers des systèmes externes

Authenticator utilise le protocole CTAP (Client to Authenticator Protocols) pour interagir avec le navigateur.

Partie de confiance : remplit la même fonction que le «serveur d'autorisation» dans OAuth 2.0, à savoir, vérifie l'identité de l'utilisateur. Seulement dans OAuth 2.0, c'était le nom d'utilisateur / mot de passe, et dans WenAuthn, c'était les informations d'identification de la clé publique.

Agent utilisateur : intègre le navigateur et l'application réseau, sert les mêmes objectifs que le client dans OAuth 2.0, à savoir, d'une part, interagit avec l'utilisateur et lui fournit une interface graphique, et d'autre part, interagit avec les systèmes qui stockent les informations d'identification de l'utilisateur .

Flux d'autorisation


Avant de démarrer le processus d'authentification, tout comme dans OAuth 2.0, vous devez effectuer des étapes préparatoires, uniquement dans OAuth 2.0, nous avons enregistré l'application et dans WebAuth 2.0, nous avons enregistré l'utilisateur. L'API d'authentification Web spécifie deux appels:

  • navigator.credentials.create - pour crĂ©er des informations d'identification utilisateur
  • navigator.credentials.get - vĂ©rifie les informations d'identification de l'utilisateur

Par conséquent, pour vous inscrire, vous devez appeler navigator.credentials.create.

En conséquence, l'authentificateur de l'utilisateur stockera la clé privée pour un site spécifique, et la clé publique sera stockée dans la partie utilisatrice.

image

Après cela, le processus d'authentification sera le suivant:

image

  1. “WebAuthn”. , , WebAuthn, “ ” “ ”. Relying Party Challenge. Challenge — , Code OAuth 2.0.
  2. Relying Party Challenge. , REST API.
  3. Authenticator- CTAP (Client to Authenticator Protocols). navigator.credentials.get c :

    • Challenge
  4. Authenticator , , .
  5. , Authenticator .
  6. L'application envoie les données signées à la partie utilisatrice.
  7. La partie utilisatrice décrypte les données à l'aide de la clé publique, vérifie le défi et autorise l'utilisateur.

Pour fixer le matériel, nous effectuons des travaux de laboratoire:

WebAuthn: Lab (Google)


Pour implémenter WebAuthn, seules les requêtes http ne peuvent pas être supprimées, car vous devez appeler l'API du navigateur pour interagir avec l'authentificateur. Mais ici, Google est heureux, a créé un bac à sable avec des instructions étape par étape: votre premier WebAuthn .

À la suite du travail, nous obtenons une application client-serveur JS qui implémente l'authentification par empreinte digitale. Un déme de travail est situé à .

Si vous l'exécutez sur un smartphone avec un capteur d'empreintes digitales, vous pouvez voir le résultat du travail. Comme d'habitude, première préparation - enregistrez l'utilisateur:

image

Créez un nom d'utilisateur / mot de passe puis attachez l'empreinte digitale:

image

Après cela, le programme montre quelle clé publique est attachée à cette empreinte digitale:

image

Vous pouvez maintenant démarrer le script d'authentification. Comme d'habitude, nous pensons que l'étape 1 est terminée et nous sommes sur le site. Pour passer à l'étape 2, cliquez sur «Try Reauth». Le navigateur effectuera l'étape 3 et interagira avec l'authentificateur, qui à l'étape 4 vous demandera de mettre votre doigt:

image

Et si le doigt enregistré est attaché, les étapes 5 et 6 passeront avec succès et à l'étape 7, l'application affichera à nouveau la fenêtre avec la clé publique correspondante:

image

Conclusion


Nous avons donc examiné les trois protocoles les plus courants et les plus prometteurs pour l'identification des utilisateurs: OAuth 2.0, OpenID Connect, WebAuthn. Nous avons compris la portée de leur applicabilité:

  • OAuth 2.0 - utilisĂ© pour enregistrer et connecter les utilisateurs aux sites utilisant les rĂ©seaux sociaux. Et aussi pour obtenir les donnĂ©es des utilisateurs des rĂ©seaux sociaux.
  • OpenID Connect — . OpenID Connect SSO .
  • WebAuthn — .


  • , , .
  • , , .
  • Il est logique d'authentifier les utilisateurs sur des plateformes cloud telles que Facebook ou Google, comme ils emploient les meilleurs experts en sĂ©curitĂ© qui peuvent fournir toutes les nuances de sĂ©curitĂ©.
  • Je suggère optimiste pour l'avenir, car Protocole WebAuthn - une vraie chance de se dĂ©barrasser de l'enfer des mots de passe de notre temps!

Ce n'est qu'un début!

Annexe: autres protocoles d'authentification


Pour être complet, je vais énumérer les autres protocoles et technologies pertinents utilisés pour identifier les utilisateurs:

SAML 2.0 (langage de balisage d'assertion de sécurité)


Le protocole mature de 2005, mais a un ensemble limité de scénarios pour la construction de systèmes SSO. Utilise un format de données basé sur XML. Plus de détails peuvent être trouvés dans l'article: «Qui utilise le protocole d'authentification SAML 2.0»

API de gestion des informations d'identification


Le développement est réalisé par la même organisation que WebAuthn - W3C. La norme de gestion des informations d'identification vous permet de:

  • Stockez l'identitĂ© des abonnĂ©s, ce qui permet aux utilisateurs d'accĂ©der aux sites sans entrer de mots de passe, mais d'utiliser les mots de passe du magasin.
  • SĂ©lectionnez les comptes nĂ©cessaires pour accĂ©der Ă  certains sites.
  • Vous permet d'utiliser des identifiants / mots de passe entrĂ©s sur un appareil sur d'autres appareils.

Un exemple d'implémentation courant de l'API de gestion des informations d'identification est le gestionnaire de mots de passe de Google: passwords.google.com

Initiative pour l'authentification ouverte (OATH)


Ressources sur le serment

Une liste complète des protocoles basés sur OAuth 2.0



All Articles