Comprendre comment fonctionne OAuth 2.0
Les solutions d'authentification et d'autorisation d'Okta sont basées sur deux protocoles standard, OAuth 2.0 et Open ID Connect (OIDC). Tout comme le SAML, ces termes peuvent prêter à confusion, car ils font également référence aux différentes manières dont les services peuvent interagir de manière sécurisée. Mais tandis que l’OIDC et le SAML concernent tous deux l'authentification utilisateur, OAuth 2.0 s'applique uniquement à l'autorisation. Cet article consacré à OAuth 2.0 présente les bases de son fonctionnement, les différences avec OAuth 1.0 et son intérêt à la fois pour les développeurs et les utilisateurs.
Qu'est-ce que c'est OAuth 2.0 ?
OAuth 2.0, abréviation de "Open Authorisation" également connue sous le nom de OAuth2, est un protocole d'autorisation. Son objectif est de permettre à un site web ou à une application autorisée d'accéder aux ressources hébergées par un site web ou application, tout en assurant la sécurité des informations d'identification de l'utilisateur. OAuth 2.0 permet également de limiter ce que le site web ou l’application peut faire des informations ou des données.
En quoi cela est-il utile ? Avec OAuth 2.0, vous pouvez partager des ressources telles que des photos ou des contacts de manière transparente entre deux services sans avoir à saisir un nouveau nom d'utilisateur et mot de passe. OAuth 2.0 est désormais plus ou moins la norme sectorielle. Si vous vous êtes déjà connecté à l’application d’un réseau social en important vos contacts depuis une autre application, vous avez probablement déjà eu affaire à OAuth 2.0. Pour les travailleurs qui passent constamment d’un service à l’autre au cours d'une même journée, cela peut représenter un gain de temps précieux, tout en garantissant la sécurité des mots de passe. Pour les administrateurs, OAuth 2.0 peut permettre d’accélérer l'intégration et de centraliser le contrôle des autorisations.
OAuth 2.0 a remplacé OAuth 1.0 en 2012, après des années d’échanges entre les grandes entreprises technologiques. Si l'objectif des deux protocoles reste le même, le lancement d'OAuth 2.0 a impliqué une réécriture complète du cadre. Cela signifie qu'il n'est pas rétrocompatible : OAuth 1.0 et OAuth 2.0 doivent être considérés comme des protocoles distincts.
OAuth : Comment ça marche ?
OAuth 2.0 fonctionne par l'octroi de jetons d'accès. Quatre rôles clés sont définis dans la spécification OAuth 2.0. Ces derniers, essentiels pour comprendre le fonctionnement du protocole, sont distincts des rôles définis par OAuth 1.0. Le "resource owner” est de manière générale l'utilisateur, donc la personne en mesure d’accorder l’accès à ses données. Le client est le site Web ou l'application tierce qui demande le jeton. Le “authorization server” (par exemple Okta) émet les jetons, alors que le “resource server” stocke les ressources du propriétaire, qui accepte le jeton une fois ce dernier vérifié.
Une fois ces termes clés maîtrisés, il sera plus facile de suivre un workflow OAuth 2.0 standard. Par exemple, lorsqu'un utilisateur (le propriétaire de la ressource) effectue une demande en cliquant sur une page Web ou une application cliente, celle-ci demande à l'utilisateur de lui accorder une autorisation - pour accéder aux contacts d'une autre application, par exemple. La page web ou l'application du client transmet cette autorisation au serveur d'autorisation (par exemple Okta), qui envoie un jeton de connexion au serveur de ressources, où les contacts sont stockés. Une fois le jeton vérifié, le serveur de ressources accorde au client l'accès aux contacts, mettant en relation les deux sans que l'utilisateur ait à saisir de mots de passe supplémentaires ou à partager des informations plus confidentielles. Voici comment fonctionne OAuth2 !
Authentification avec OAuth 2.0
Bien entendu, c’est en réalité un peu plus complexe que cela. Pour le développeur qui crée une application cliente ayant besoin d’accès à des ressources, le workflow OAuth2 précis dépendra du type d'autorisation utilisé. Ces différents types d'autorisation comprennent les informations d'identification du client, le code d'autorisation et le propriétaire de la ressource. Le choix entre ces types d'autorisation dépend du cas d'utilisation particulier. Le flux Client Credentials est utilisé lorsqu'il n'y a pas d'utilisateur final, tandis que si un niveau plus élevé de sécurité est nécessaire, un flux Authorization Code avec Proof Key for Code Exchange (PKCE) sera employé. Ce workflow suivra les étapes décrites ci-dessus, mais l'application client crée et enregistre également une clé secrète, pour empêcher l'interception du code d'autorisation.
En combinant OAuth 2.0 avec des protocoles d'authentification fédérés tels qu'OpenID Connect et SAML, il est possible de simplifier d’autant plus encore le passage d’une application à une autre. Ces deux protocoles permettent de proposer aux utilisateurs des expériences d'authentification uniques, en fournissant un accès fluide à plusieurs applications sans que ces derniers aient à saisir à nouveau leurs informations d'identification. Alors que le SAML est indépendant d'OAuth, OpenID Connect est une norme qui s'appuie sur OAuth 2.0 pour authentifier les utilisateurs et transmettre des informations les concernant.
Utiliser OAuth 2.0 avec Okta
L'un des principaux avantages du cadre OAuth 2.0 est qu'il peut être utilisé de manière très précise, avec des périmètres d'accès clairement définis et des jetons à durée limitée pour permettre un niveau de sécurité plus élevé. Avec API Access Control, Okta peut aider vos équipes à adapter OAuth 2.0 à leurs besoins précis, en vous accompagnant dans la mise en œuvre et l’adaptation de vos politiques d'autorisation. Vos applications peuvent ensuite être facilement intégrées à votre infrastructure Okta existante, notamment API Gateway. Maintenant que vous savez comment fonctionne OAuth 2.0, vous pouvez explorer ces outils, ainsi que d'autres manières d’employer OAuth 2.0 et Okta sur le portail des développeurs Okta.
Ressources complémentaires
Differences Between OAuth 1 and 2
What's the Difference between OAuth, OpenID Connect, and SAML?