Pourquoi abandonner les tokens d'API statiques et migrer vers OAuth 2.0

Les tokens d'API statiques servent depuis longtemps à appeler des API externes et à accéder aux ressources de tiers, comme les éditeurs de logiciels. À mesure que les normes API ont évolué, OAuth 2.0 s’est imposé comme la solution offrant une sécurité renforcée, une meilleure flexibilité et une expérience améliorée pour les développeurs. Explorons les avantages d’abandonner les jetons statiques au profit d’OAuth 2.0.

Paysage des tokens d'API statiques

Dans un système logiciel sécurisé, tous les appels permettant un accès en lecture ou en écriture aux ressources doivent être autorisés. Lorsque vous appelez une API protégée, l’API doit disposer d’un moyen de valider l’autorisation. Les tokens d'API statiques permettent de transmettre des informations d’autorisation à l’API à l’aide d’une valeur mémorisée, sans contexte utilisateur. Par conséquent, ils proposent une méthode simple (mais limitée) permettant aux développeurs d’accorder à une autre application l’accès à l’API : générer un token, l’enregistrer une seule fois, puis poursuivre la tâche.

Si l’on prend l’exemple d’un appel HTTP adressé à Okta, une requête utilisant un token d'API statique pourrait ressembler à ceci :

L’appelant de l’API (c’est-à-dire le client) ajoute la valeur du token à l’appel. Selon le système fournisseur sollicité, l’API peut ajouter la valeur statique du token dans un header HTTP, tel qu’Authorization (en utilisant un schéma d’autorisation standard ou un schéma propriétaire comme le schéma SSWS d’Okta), ou dans un paramètre de requête.

Passer des tokens d'API statiques à OAuth 2.0 pour renforcer la sécurité

Comme pour de nombreuses technologies, cette facilité d’utilisation s’accompagne d’une plus grande exposition aux risques. Contrairement aux tokens OAuth 2.0 à durée de vie limitée, les tokens statiques sont généralement valables pendant une longue période. Les tokens d’API placés dans les paramètres de requête présentent un risque particulièrement élevé. Les navigateurs enregistrent les URL dans l’historique, et les systèmes de journalisation peuvent consigner l’intégralité de l’URL, ce qui expose le token plus facilement que lors de l’utilisation des en-têtes HTTP.

Pour mieux comprendre les enjeux de sécurité liés aux tokens d'API statiques, analysons certaines de leurs caractéristiques et comparons-les avec l'alternative, OAuth 2.0.

Risques d’accès liés à l’utilisation de tokens d'API statiques

Les tokens statiques peuvent être compromis, ce qui peut entraîner un accès non autorisé. Par exemple, les tokens statiques peuvent être accidentellement intégrés dans des systèmes de gestion de code source, ce qui expose le token aux personnes ayant accès au dépôt et à l’historique de contrôle de la source. Étant donné que les tokens statiques ont une longue durée de vie, le risque d’exposition de ces tokens est particulièrement préoccupant, car les conséquences d’un token volé sont importantes : un token statique compromis reste actif jusqu’à sa désactivation manuelle ou jusqu’à son expiration, ce qui rend possible un accès non autorisé.

Problèmes liés à la rotation des tokens

La rotation des tokens statiques peut représenter une tâche complexe. Comme les valeurs de token persistent dans l’environnement de l’appelant ou les systèmes logiciels, planifier la rotation pour abandonner rapidement un token, en générer un nouveau et enregistrer le token tout en maintenant les environnements de production opérationnels représente un défi de taille.

La difficulté de la limitation du champ d’application

Attribuer des champs d’application limités à des tokens statiques n’est pas simple. Les tokens statiques accordent généralement un accès à l’API appelée dans son intégralité, c’est-à-dire un niveau d’accès tout ou rien. Définir l’accès pour un champ d’application limité, comme un accès en lecture seule par opposition à un accès en écriture, ainsi que d’autres mesures de contrôle des accès granulaires, peut ne pas être possible ou être difficile à gérer avec des tokens d'API statiques.

Autorisations héritées dans les tokens générés par les utilisateurs

Les tokens d’accès générés par les utilisateurs reprennent généralement les autorisations du compte utilisateur qui les a créés. Si c'est un administrateur qui génère le token, il dispose d’un accès complet à toutes les ressources et actions que l’administrateur peut effectuer. Pour atténuer ce problème, il arrive que des entreprises créent des comptes de service avec des droits limités afin de générer le token. Cependant, cette approche entraîne une surcharge de gestion des utilisateurs et peut occuper une place dans une licence.

Défis liés à l’audit

Il est difficile de suivre l’utilisation des tokens statiques. Un besoin fondamental de l’audit consiste à retracer l’interaction d’un utilisateur avec une API. Cependant, les tokens d'API statiques n’ont généralement pas de contexte utilisateur, et tous les appels à l’API utilisent le même token statique, ce qui peut rendre impossible l’identification de l’action d’un utilisateur spécifique avec une API.

Les tokens statiques sont fragiles

Les tokens associés aux comptes utilisateurs perdent leur validité lorsque l’utilisateur quitte l’entreprise. Certaines entreprises utilisent des comptes de service pour contourner cette mesure, ce qui engendre des risques d’accès et alourdit la gestion.

Il existe une méthode plus efficace et plus sécurisée pour accéder aux API et réduire les risques liés aux tokens d'API statiques : utiliser les flux OAuth 2.0 standards du secteur.

Adopter OAuth 2.0 pour renforcer la sécurité

OAuth 2.0 répond à presque tous les scénarios en remplaçant les tokens statiques tels que les tokens SSWS d’Okta. Mais contrairement aux tokens statiques, les spécifications OAuth incluent des définitions et des pratiques sécurisées pour des besoins essentiels comme la rotation des tokens, les décisions d’autorisation de base, et bien d’autres, pour des cas d’usage quotidiens :

• Interaction automatisée entre services pour gérer les appels API en arrière-plan sans contexte utilisateur
• Automatisation basée sur les tâches via vos opérations en ligne de commande
• Limiter les données et les actions des applications aux niveaux d’accès de l’utilisateur afin de préserver la sécurité de l’autorisation

OAuth 2.0 prend en charge chacun des cas d’usage courants mentionnés ci-dessus grâce à des propriétés de configuration transmises dans une requête à un serveur d’autorisation centralisé. L’interaction générale suit un processus en plusieurs étapes :

1. L'appelant demande un token d'accès au serveur d'autorisation, en transmettant les propriétés de configuration requises pour le cas d'usage. Le serveur d’autorisation renvoie un token d’accès de courte durée. La durée de vie du token dépend du cas d'usage. Certains cas d’usage ont un niveau de sécurité intrinsèquement plus élevé, ce qui peut faire varier leur durée de vie. La requête HTTP ci-dessous présente un exemple de demande de récupération de token, mais n’inclut pas les propriétés de configuration requises. Vous verrez les propriétés de configuration nécessaires dans les exemples suivants.

2. L’appelant utilise la valeur du token dans la requête API comme valeur dans le header Authorization de la requête HTTP en utilisant le schéma Bearer. La requête HTTP peut ressembler à ceci :

OAuth 2.0 comporte de nombreux aspects, alors consultez les ressources à la fin de cet article pour en savoir plus. Cet article n'aborde pas tous les détails, mais donne les informations spécifiques aux cas d’usage mentionnés et propose un résumé général pour chacun.

Examinons chaque cas d’usage pour voir comment OAuth 2.0 le prend en charge.

Interaction entre services

Il se peut que vous ayez des processus backend qui appellent d’autres API pour obtenir des données ou effectuer des actions. OAuth 2.0 prend en charge les requêtes de service à service ou de machine-to-machine sans contexte utilisateur associé à l’appel, grâce à un flux d’autorisation appelé Client Credentials.

Avantages de l’utilisation des identifiants client par rapport aux tokens d'API

L’utilisation d’OAuth 2.0 pour l’interaction entre services présente des avantages considérables par rapport aux clés API statiques, notamment en ce qui concerne les niveaux d’accès appelés scopes. Dans OAuth 2.0, vous définissez les portées que votre token d'accès obtient dans les propriétés de configuration lors d'un appel pour récupérer votre token. Vous devez vérifier que l’API que vous appelez prend en charge l’accès basé sur les portées et que vous avez accordé l’accès aux portées nécessaires. Par exemple, les API Okta ont défini plusieurs portées pour les API de ressources, telles que okta.users.read et okta.users.write. Vous pouvez accorder l’accès à l’un ou aux deux de ces champs d’application.

Le flux d’identifiants Client n’est pas équivalent à l’utilisation de comptes de service pour l’autorisation de l’API. OAuth 2.0 prend en charge l’interaction machine-à-machine dans un format standard sans occuper de licence utilisateur pour émuler un utilisateur d’automatisation. Remarquez que lorsque vous définissez des portées, vous le ferez dans la configuration de l’application de service et au sein du serveur d’autorisation, et non au niveau de l’utilisateur. L’avantage est que vous contrôlez l’accès aux ressources pour l’ensemble de l’application de service, et non via un utilisateur au sein de l’application. Vous n’avez plus à vous préoccuper de la gestion des comptes de service et pouvez avoir l’assurance que l’application n’accède pas à plus de périmètres que ceux que vous avez autorisés.

Récupérer un token d'accès à l'aide des identifiants du client

Pour obtenir un token d’accès pour ce flux, vous devez envoyer des propriétés précisant le type de flux d’autorisation, les identifiants ainsi que les scopes associés au token d’accès. Le terme OAuth 2.0 utilisé pour définir le flux d’autorisation est appelé grant_type ; pour le flux d’identifiants client, vous devez indiquer la valeur client_credentials.

Les identifiants peuvent être soit un JSON Web Token (JWT) sécurisé de manière cryptographique et signé avec la clé privée du client, soit une valeur secrète générée par votre serveur d’autorisation. Un JWT à clé privée offre une sécurité renforcée, car vous ne risquez pas d’exposer la valeur secrète, ce qui pourrait entraîner des problèmes d’accès similaires à ceux d’un token d'API statique. Vous allez générer une paire de clés publique/privée et enregistrer la clé publique dans un ensemble de clés JSON Web (JWKS) ou la charger sur le serveur d’autorisation afin que celui-ci dispose de la clé publique pour valider la signature du JWT. Pour en savoir plus sur ce processus, lisez la documentation Implémenter OAuth for Okta avec une application de service.

Un exemple d'appel HTTP pour récupérer le token d'accès peut ressembler à ceci :

Une fois que vous obtenez le token d'accès, vous l'ajoutez aux appels API en tant que header : Authorization : Bearer access_token.

En savoir plus sur les appels d’API service-à-service avec .NET et la création de JWT privés en Python dans Sécuriser votre API Web .NET 6 et Configurer le flux JWT à clé privée en trois commandes Python.

Automatisation basée sur les tâches

Les terminaux en ligne de commande, tels que Bash et PowerShell, sont des processus sans interface graphique permettant d’exécuter des commandes ou des scripts directement dans la fenêtre de votre terminal. Contrairement à l’interaction précédente entre services, ce flux intègre le contexte utilisateur. Vous souhaitez exécuter les opérations en ligne de commande avec votre contexte d’autorisation, ce qui signifie que vous n’aurez accès qu’aux ressources de l’API auxquelles vous êtes censé avoir accès. OAuth 2.0 prend en charge ce cas d’usage avec un flux appelé Device Flow.

L’obtention des tokens d’accès est un processus en plusieurs étapes avec ce flux. Avant de demander directement le token d'accès comme dans le cas d'usage service-à-service, vous obtenez d'abord des codes de vérification uniques en envoyant le client_id à un terminal spécifique sur votre serveur d'autorisation :

La réponse à l’appel /device/authorize renvoie deux codes uniques : un code appareil et un code utilisateur, ainsi qu’une URI de vérification. Confirmer la demande d’autorisation en accédant à l’URI de vérification dans votre navigateur et en saisissant le code utilisateur.

Pour récupérer le token d'accès, ajoutez la propriété grant_type afin de spécifier le flux OAuth 2.0 pour le cas d'usage ainsi que le device code en tant que propriétés de configuration dans l'appel :

Utiliser le token d'accès de la réponse dans le header Authorization : Bearer access_token.

Vous pouvez en savoir plus sur le flux Code d'appareil pour les lignes de commande dans S’authentifier depuis la ligne de commande avec Java.

Accès utilisateur via une application web

Le dernier cas d’usage garantit que l’autorisation de l’utilisateur s’applique à l’accès à l’API lors de l’utilisation d’une application web. OAuth 2.0 permet de limiter les actions d’une application à un sous-ensemble de ce que l’utilisateur ou l’utilisatrice peut faire et des données auxquelles il ou elle a accès. Dans ce flux, vous disposez du contexte utilisateur pour demander l’autorisation d’accès à la ressource, et le fait de disposer de ce contexte facilite également l’audit et la traçabilité des appels effectués par chaque utilisateur. Le flux OAuth 2.0 pour ce cas d’usage combine un flux standard, le flux Authorization Code, et une extension pour une couche de sécurité supplémentaire appelée Proof Key for Code Exchange (PKCE).

Le flux Authorization Code avec PKCE nécessite plusieurs étapes pour obtenir un token d'accès et implique une interaction de l'utilisateur via le consentement et la vérification, ce qui permet l'authentification multifacteur. Dans ce flux, vous redirigez l’utilisateur vers un serveur d’autorisation pour obtenir le code d’autorisation avant de demander un token d’accès.

L’URL de redirection inclut des propriétés propres à la requête afin de permettre la finalisation de la connexion, notamment la spécification du type de requête via la propriété response_type et le client_id, ainsi que d’autres propriétés.

Lorsque l’utilisateur ou l’utilisatrice termine la connexion avec succès, le fournisseur d’identité redirige vers l’application avec un code d’autorisation dans la réponse d’autorisation. Pour récupérer le token d'accès, vous transmettez le type de grant pour ce flux, le code d'autorisation ainsi que d'autres métadonnées propres à la requête.

Une fois le token d'accès obtenu, l'application web ajoute le token d'accès aux appels API sortants dans le header Authorization : Bearer access_token.

En savoir plus sur le flux de code d’autorisation dans Fonctionnement de l’authentification et de l’autorisation pour les applications monopage et Utiliser PKCE avec OAuth 2.0 et Spring Boot pour renforcer la sécurité.

Supprimer progressivement les tokens d'API statiques et utiliser OAuth 2.0

Les migrations logicielles nécessitent du temps et une planification rigoureuse, et disposer d’une stratégie claire est un atout. Envisager de passer à OAuth 2.0 par étapes progressives et limitées.

La première étape pour abandonner les tokens d'API statiques consiste à vérifier que les API que vous utilisez prennent en charge OAuth 2.0. Vérifiez auprès de votre fournisseur si vous faites appel à des API tierces. Si votre API est interne, vous devrez ajouter la prise en charge d’OAuth. Une fois que vous avez vérifié que les API que vous utilisez sont compatibles avec OAuth, vous aurez besoin de l'identifiant client de l’application OAuth et d'activer des mesures d’accès telles que les champs d’application.

En vous connectant à votre admin console Okta en tant qu’administrateur, vous pouvez déterminer si vous utilisez des tokens d'API statiques dans un environnement Okta. Dans la barre latérale, cliquez sur Sécurité > API et sélectionnez l’onglet Tokens pour afficher tous les tokens créés pour l'organisation Okta. Cette vue offre une visibilité sur l’utilisation des tokens d'API, les cas d’usage et le niveau d’accès (par exemple, un token créé par un super administrateur dispose d’un accès complet). Vous devrez évaluer chacun d’eux et les convertir pour utiliser OAuth.

Concentrons-nous sur le cas d'usage d'un appel automatisé entre services. Intégrer OAuth 2.0 à l’ensemble de vos API en une seule fois peut sembler complexe, examinons donc comment procéder de manière progressive. Avant de modifier le code, vous pouvez tester les étapes localement de manière manuelle et utiliser votre client HTTP préféré pour demander un token et appeler une API avec OAuth 2.0. Ce cas utilise le flux Identifiants Client avec un JWT à clé privée. Les étapes sont :

1. Générer la paire de clés publique/privée
2. Utiliser la paire de clés publique/privée pour générer le JWT de clé privée
3. Demander le token d'accès
4. Ajouter le token d'accès à votre requête API
5. Intégrer OAuth à votre système d’application

1. Générer la paire de clés publique/privée

Vous pouvez générer une paire de clés publique/privée en suivant ces instructions. La Console d’administration d’Okta peut générer une paire de clés publique/privée à des fins de test si vous ne souhaitez pas la générer vous-même.

2. Générer le JWT de clé privée

Utiliser la paire de clés publique/privée pour créer le JWT de clé privée en suivant les instructions de la documentation Implémenter OAuth for Okta avec une application de service. Il est plus important à cette étape de comprendre le fonctionnement global que d’automatiser les étapes, afin de pouvoir stocker la paire de clés publique/privée localement, utiliser les outils installés sur votre poste et, pour l’instant, coller le JWKS contenant votre clé publique dans un site web de génération de JWT pour test.

3. Demander le token d'accès

Demander le token d'accès à l'aide de votre JWT de clé privée sans ajouter de scopes en faisant la requête HTTP dans votre client HTTP préféré. Vous devriez obtenir une erreur si vous utilisez le token d'accès sans le scope approprié, mais il est recommandé de tester à la fois les cas d’erreur et les scénarios favorables. Le token d'accès expire à un moment donné, et vous verrez la date d'expiration dans la réponse du token d'accès. Le token d'accès fait partie de la réponse. Vous utiliserez l’ensemble de la chaîne comme token d’accès.

4. Ajouter le token d’accès à votre requête API

À l’aide de votre client HTTP, appeler votre API en utilisant le token d’accès. Vous allez ajouter un header Authorization et utiliser le schéma Bearer, afin que votre appel d’API comporte le header suivant, conforme au format indiqué ci-dessous :

Lorsque vous effectuez l’appel API, vous devez recevoir une erreur HTTP 403. Bravo ! Succès ? Eh bien, oui, un test de cas d’erreur réussi. Vous savez désormais quelle erreur attendre en cas de problème lors de la configuration des scopes. Ajoutons les portées à la requête de token d'accès et réessayons.

Cette fois, demandez votre token d'accès en utilisant le JWT à clé privée et ajoutez les portées nécessaires pour l'appel à l'API. Utiliser le token d'accès dans l'appel API. Le moment de vérité ! Vous devriez voir une réponse positive. Vous savez qu’il y a une erreur de configuration si vous obtenez à nouveau une erreur 403. Si cela se produit, vérifier à nouveau les portées de la requête et s’assurer que l’application OAuth 2.0 dispose bien des portées que vous demandez.

5. Ajouter l’autorisation OAuth 2.0 au sein de votre système

Maintenant que vous avez effectué avec succès l’autorisation OAuth 2.0 pour un appel serveur à service de manière manuelle, vous pouvez intégrer certains de ces éléments dans votre système. Dans un environnement de développement ou de test, essayez d’utiliser le token d’accès. Vous devrez modifier vos API pour utiliser le header Authorization au format Bearer et remplacer votre token d'API statique actuel par le token d'accès généré manuellement afin de garantir le bon fonctionnement de vos appels API sans automatiser les étapes de demande du token d'accès.

Lorsque vous estimez que votre système d’API gère correctement le token d’accès, il est temps d’ajouter les étapes permettant de le demander directement depuis votre code. Votre pile technologique peut inclure des SDK pour faciliter tout ou partie des étapes de la demande. Les SDK de gestion d’Okta peuvent gérer l’échange OAuth 2.0 pour vous. Les utilisateurs de Java Spring peuvent consulter la documentation Spring Security, et les utilisateurs de .NET Core peuvent consulter Microsoft.AspNetCore.Authentication comme exemples. Pensez à tester votre travail au fur et à mesure, aussi bien pour les parcours réussis, les cas d’erreur, que pour des scénarios comme la gestion correcte de l’expiration du token d’accès.

Avant de déployer des modifications dans votre environnement de production, vérifier que vous utilisez des outils de qualité professionnelle pour générer le JWKS en interne et gérer votre clé privée de manière sécurisée.

Bonnes pratiques lors des migrations d’autorisation API

Passer immédiatement des tokens statiques à une autre solution n’est pas toujours réalisable, en particulier dans les grandes organisations ou si vous devez mettre à jour de nombreuses API. Si vous utilisez encore des tokens SSWS avec Okta, il est recommandé de réduire les risques en attendant de passer à OAuth 2.0. Les bonnes pratiques incluent :

• Mettre en œuvre de nouveaux appels d’API ou du code en utilisant OAuth 2.0.
• Appliquer le Principe du moindre privilège. Par exemple :
  • N’utilisez pas de comptes personnels pour créer des comptes de service.
  • Utiliser un rôle d’administrateur personnalisé pour les comptes de service, en accordant uniquement les autorisations essentielles.
  • Utiliser les groupes et les stratégies de session globales pour empêcher les connexions interactives des comptes de service.

Sécuriser les appels API avec OAuth 2.0

Passer de tokens statiques à OAuth 2.0 ne consiste pas seulement à adopter une nouvelle technologie, mais à évoluer vers un écosystème plus sécurisé, flexible et adapté aux développeurs. Si les tokens statiques ont eu leur utilité à une certaine époque, il est désormais évident que l’avenir repose sur des solutions OAuth 2.0 dynamiques, centrées sur l’utilisateur et sécurisées.

N’oubliez pas : à mesure que la technologie évolue, rester informé et adopter de bonnes pratiques n’est pas seulement avantageux, c’est indispensable. Passer à OAuth 2.0 et accéder à un parcours développeur plus sécurisé, fluide et efficace.

Prochaines étapes avec OAuth 2.0

Si vous trouvez cet article intéressant, vous apprécierez sans doute ces autres articles.

• Choisir la meilleure méthode d’autorisation pour vos intégrations API
• Ajouter l’authentification à toute application avec OAuth2 Proxy
• OAuth pour les développeurs Java

Consulter les guides développeurs API Security d’Okta pour commencer votre migration vers OAuth 2.0 :

Configurer la démonstration de la preuve de possession

• Ce guide explique comment créer des tokens d’accès restreints à l’émetteur, un mécanisme au niveau de l’application permettant d’éviter la réutilisation des tokens sur différents points de terminaison.

Configurer OAuth for Okta

• Ce guide explique comment interagir avec les API Okta à l’aide de jetons d’accès OAuth 2.0 à portée définie. Configurer OAuth for Okta : Application de service
• Ce guide décrit comment interagir avec les API Okta à l’aide de jetons d’accès OAuth 2.0 à portée définie pour une application de service.

Protéger vos API endpoint

• Ajouter une autorisation avec Okta pour protéger vos API. Lorsque vous avez terminé, vous disposez d’une application API REST sécurisée qui valide les requêtes entrantes.

Intégrer le risque lié aux tiers

• Ce guide explique comment configurer une organisation Okta pour recevoir des événements liés aux risques provenant d’un fournisseur tiers. Sécuriser la connexion API entre organisations avec OAuth 2.0
• Ce guide décrit la configuration sécurisée des organisations Okta hub-and-spoke afin de synchroniser les utilisateurs et les groupes à l’aide d’OAuth 2.0 dans une solution multitenant. Connecter l’accès à l’API de l’organisation Okta à des données à portée définie en utilisant le flux d’identification par client OAuth 2.0 pour l’application Org2Org integration.

Configurer l’authentification renforcée avec des valeurs ACR

• Ce guide explique comment inclure le paramètre acr_values dans vos requêtes d’autorisation afin de renforcer la confiance accordée à l’utilisateur final.

Pour découvrir d’autres contenus, suivre @oktadev sur X, nous retrouver sur LinkedIn et s’abonner à notre chaîne YouTube.