Authentification API avec des jetons d'accès OAuth 2.1
L'authentification API est la manière dont votre API détermine quel appelant a envoyé une requête et ce qu'il a le droit de faire. L'approche habituelle consiste à faire présenter par les appelants un jeton d'accès de courte durée émis via OpenID Connect et OAuth 2.1, puis à faire valider ce jeton par votre API à chaque requête. Skycloak Platform est conçu pour être le serveur qui émet ces jetons, si bien que votre API n'a plus qu'à les vérifier.
Comment les jetons d'accès protègent votre API
Un jeton d'accès est une déclaration signée par votre serveur de connexion qui indique à qui il a été délivré, à quelle API il est destiné et jusqu'à quand il est valable. Votre application web, votre application mobile ou un autre service l'obtient par un flux OAuth 2.1 : le flux authorization code quand une personne se connecte, ou l'octroi client credentials quand l'un de vos services en appelle un autre sans utilisateur. OAuth 2.1 impose PKCE (proof key for code exchange) sur le flux authorization code, ce qui empêche un tiers d'échanger un code d'autorisation volé contre un jeton. L'appelant envoie ensuite le jeton dans l'en-tête Authorization de chaque requête vers votre API.
Les jetons d'accès sont généralement des JSON Web Tokens, ou JWT, que votre API peut vérifier localement sans appeler le serveur de connexion à chaque requête. Ils expirent au bout de quelques minutes et non de plusieurs mois, si bien qu'un jeton divulgué cesse vite de fonctionner, et un jeton de rafraîchissement permet au client d'en obtenir un nouveau sans redemander la connexion à l'utilisateur. Les scopes du jeton indiquent ce que l'appelant peut faire, par exemple lire des factures sans pouvoir les supprimer, et votre API peut ainsi refuser une action que le jeton n'a jamais accordée. La décision de savoir qui peut appeler quoi reste ainsi en un seul endroit au lieu d'être répartie entre vos points de terminaison.
Ce que votre API vérifie à chaque requête
Valider un JWT revient à faire quatre vérifications sur le jeton lui-même, puis une vérification de ses scopes, et en omettre une seule laisse une faille. Votre API vérifie la signature avec les clés publiques que publie votre serveur de connexion, afin de rejeter un jeton que personne n'a signé. Elle vérifie que l'émetteur est l'adresse de connexion de votre tenant et que l'audience est votre API, afin de refuser un jeton créé pour une autre application ou un autre tenant. Elle contrôle ensuite la date d'expiration, et enfin que les scopes couvrent l'action demandée.
Chaque tenant de la plateforme a sa propre adresse de connexion et ses propres clés de signature, si bien que votre API de production n'accepte jamais un jeton émis par votre tenant de préproduction. Dans la plupart des langages, les bibliothèques JWT standard savent récupérer les clés publiées, les mettre en cache et prendre en compte les nouvelles lors d'une rotation, et vous écrivez donc très peu de ce code vous-même. Les jetons liés à l'expéditeur ajoutent une protection de plus. Avec DPoP (demonstrating proof of possession), prévu pour la première version de la plateforme, le client prouve avec sa propre clé privée qu'il détient le jeton, si bien qu'un jeton copié depuis un journal ou un proxy ne peut pas être utilisé par celui qui l'a copié.
En quoi les jetons d'accès diffèrent des clés d'API statiques
Une clé d'API statique est un secret de longue durée que l'appelant envoie avec chaque requête, et votre API la recherche pour savoir qui appelle. Les clés sont simples à distribuer, mais elles n'expirent généralement jamais, elles ne disent rien de l'utilisateur derrière la requête, et une clé divulguée continue de fonctionner jusqu'à ce que quelqu'un s'en aperçoive et la révoque. Chaque vérification demande aussi une recherche dans votre propre base de données, et faire tourner une clé suppose de se coordonner avec celui qui la détient.
Les jetons d'accès évitent l'essentiel de ces problèmes, car ils expirent vite, nomment l'application et, s'il y en a un, l'utilisateur, et portent des scopes que votre API peut appliquer sans recherche. Les clés d'API gardent leur place pour des intégrations simples, et l'API de gestion de la plateforme elle-même utilise des clés avec des scopes de lecture et d'écriture par ressource. Pour l'API de votre produit, la plateforme est conçue pour émettre les jetons via OpenID Connect et OAuth 2.1 sans que votre équipe exploite ce serveur, et une démo vous montre lesquels de ces éléments vous pouvez utiliser aujourd'hui.
Questions fréquentes
Faut-il un utilisateur pour obtenir un jeton d'accès ?
Non. L'octroi client credentials permet à l'un de vos services de s'authentifier en son propre nom et d'obtenir un jeton pour appeler un autre service, sans utilisateur. C'est de l'OAuth standard, et le jeton porte l'identité et les scopes du service appelant plutôt que ceux d'un utilisateur.
Mon API peut-elle vérifier les jetons sans appeler la plateforme à chaque requête ?
Oui. La plateforme est conçue pour émettre les jetons d'accès sous forme de JWT signés : votre API peut alors vérifier la signature avec les clés publiques que publie votre tenant et contrôler localement l'émetteur, l'audience et l'expiration. Elle n'a besoin de récupérer à nouveau les clés que lors de leur rotation.
Découvrez Skycloak Platform par vous-même
Réservez une démo : nous vous présentons la plateforme en partant de vos propres parcours de connexion.