Gestion des identifiants

Obtenir votre premier jeton n’est qu’un début. Une fois une application OAuth en production, ses identifiants doivent être stockés en toute sécurité, tournés de temps en temps, et révoqués rapidement en cas de problème. Ce sont exactement les questions que pose un audit de sécurité. Cette page couvre ces trois points, ainsi que ce qu’un jeton compromis peut réellement atteindre et que faire en cas de fuite.

Où doit vivre un client secret

Stockez-le dans une variable d’environnement ou un gestionnaire de secrets (AWS Secrets Manager, Vault, etc.), jamais dans le contrôle de version, et jamais dans un fichier de configuration committé avec votre code.
Ne l’intégrez jamais dans une application desktop ou un client basé navigateur. Tout ce qui est installé sur la machine d’un utilisateur ou servi à un navigateur peut voir son binaire ou son bundle inspecté, donc tout secret qui y est intégré doit être considéré comme public dès sa mise en production.
C’est exactement pour cette raison que le flux Native Application n’émet aucun client secret : il est conçu pour des intégrations desktop et CLI qui n’ont aucun moyen d’en garder un confidentiel, et s’appuie à la place sur PKCE (une preuve par requête liée au code d’autorisation). Le flux Authorization Code + redirection HTTPS personnalisée utilise aussi PKCE, et permet d’ajouter un client secret uniquement pour les clients confidentiels dont le gestionnaire de redirection tourne sur un serveur que vous contrôlez. Une implémentation purement navigateur (SPA) de ce flux devrait se passer du secret, pour la même raison que le flux Native n’en a jamais eu. Voir Premiers pas : Choisir un flux OAuth.
Client Credentials est un flux serveur à serveur et exige toujours un secret : stockez-le selon les mêmes règles que tout autre identifiant côté serveur.

Faire pivoter un client secret sans interruption

Régénérer un secret depuis Settings → OAuth sur votre application le remplace purement et simplement. Il n’y a pas de fenêtre où l’ancien et le nouveau secret sont valides en même temps : un appelant présentant encore l’ancien secret est rejeté dès sa prochaine requête de jeton ou de rafraîchissement.

Cela ne signifie pas pour autant que toute requête en cours échoue à l’instant de la rotation. Un jeton d’accès déjà émis continue de fonctionner jusqu’à l’expiration de sa propre durée de vie (environ une heure, voir Cycle de vie des jetons), quoi qu’il advienne ensuite du secret qui l’a émis à l’origine. Seule une nouvelle demande de jeton ou un rafraîchissement a besoin du nouveau secret.

Séquence de bascule recommandée :

Régénérer le secret.
Dans la même opération, mettre à jour chaque endroit où votre intégration stocke le secret (configuration, gestionnaire de secrets, chaque instance ou worker) avant que l’une d’entre elles ne doive émettre ou rafraîchir un jeton.
Confirmer que les nouvelles demandes de jeton réussissent avec le nouveau secret.

Si vous ne pouvez pas mettre à jour chaque instance de façon atomique, planifiez la rotation comme un déploiement coordonné plutôt qu’un déploiement progressif : une instance qui détient encore l’ancien secret échoue purement et simplement la prochaine fois qu’elle a besoin d’un jeton, elle ne bascule pas gracieusement sur l’ancien.

Révoquer un accès

Il existe deux façons de couper l’accès, et toutes deux arrêtent le nouvel accès :

Révoquer une autorisation précise depuis Settings → Third-party access. L’application ne peut alors plus rafraîchir ni obtenir de jetons via cette autorisation, sans que cela l’affecte pour les autres utilisateurs.
Supprimer l’application OAuth depuis Settings → OAuth. Elle est alors révoquée pour tout le monde : plus aucun jeton d’accès ou de rafraîchissement ne peut être émis pour elle, et son client secret cesse de fonctionner de la même façon qu’après une rotation. Pour une application qui utilise les client credentials, cela désactive aussi son utilisateur de service dans la même opération.

Révoquer une autorisation, supprimer l’application et faire pivoter son secret n’affectent pas un jeton d’accès déjà émis : aucune de ces actions ne force son expiration. Considérez ce jeton comme utilisable, avec ses scopes d’origine, jusqu’à l’expiration de sa propre durée de vie. Voir Cycle de vie des jetons pour le tableau complet de ce qui affecte, ou non, un jeton actif.

Ce qu’un jeton compromis peut atteindre

Un jeton compromis n’est pas une fuite de toute votre organisation : il est doublement limité, selon le modèle de sécurité à trois couches :

Ses scopes OAuth (couche 1) : fixés dans le jeton au moment de son émission. Retirer un scope de l’application plus tard ne réduit pas un jeton déjà émis ; cela ne prend effet qu’au prochain rafraîchissement ou à la prochaine émission.
L’accès au contenu et le rôle de l’utilisateur de service (couches 2 et 3) : quels nœuds (organisations, divisions, sites) l’utilisateur de service du jeton peut voir, et ce qu’il est autorisé à y faire. Contrairement aux scopes, ceci n’est pas figé dans le jeton : c’est évalué par rapport à votre configuration actuelle à chaque requête.

À retenir en pratique : plus vous limitez étroitement l’application et son utilisateur de service dès le départ, moins un jeton compromis a de valeur.

En cas de fuite suspectée

Procédez dans cet ordre :

Faites pivoter le client secret immédiatement (Settings → OAuth → votre application). C’est l’action la plus rapide possible, et elle empêche immédiatement toute nouvelle demande de jeton ou de rafraîchissement de réussir avec l’ancien secret.
Supprimez l’application OAuth si vous ne comptez plus l’utiliser, ou si vous soupçonnez que la compromission dépasse un simple secret. Pour une application client credentials, cela désactive aussi son utilisateur de service, coupant totalement l’émission de nouveaux jetons.
Restreignez ou retirez l’accès au contenu de l’utilisateur de service. Comme l’accès au contenu et aux rôles (couches 2-3) est vérifié en temps réel plutôt que figé dans le jeton, cela réduit immédiatement ce qu’un jeton compromis encore valide peut atteindre, même avant l’expiration de sa durée de vie.
Considérez le jeton comme actif pour une fenêtre de durée de vie supplémentaire (environ une heure). Aucune des étapes ci-dessus ne force l’expiration d’un jeton déjà émis.
Émettez de nouveaux identifiants (un nouveau secret, ou une nouvelle application) et mettez à jour votre intégration avant de reprendre une utilisation normale.

Et ensuite ?

Cycle de vie des jetons pour les durées de vie, la mise en cache et le comportement de rafraîchissement
Premiers pas : Modèle de sécurité pour comprendre comment scopes, accès au contenu et rôles s’articulent