Cette page présente quelques bonnes pratiques générales pour l'intégration à OAuth 2.0. Tenez compte de ces bonnes pratiques en plus des conseils spécifiques pour votre type d'application et votre plate-forme de développement. Consultez également les conseils pour préparer votre application à la production et les règles OAuth 2.0 de Google.
Gérer les identifiants client de manière sécurisée
Les identifiants client OAuth identifient l'identité de votre application et doivent être gérés avec soin. Ne stockez ces identifiants que dans un espace de stockage sécurisé, par exemple à l'aide d'un gestionnaire de secrets tel que Google Cloud Secret Manager. Ne codez pas en dur les identifiants, ne les validez pas dans un dépôt de code et ne les publiez pas publiquement.
Gérer les jetons utilisateur de manière sécurisée
Les jetons utilisateur incluent les jetons d'actualisation et les jetons d'accès utilisés par votre application. Stockez les jetons de manière sécurisée au repos et ne les transmettez jamais en texte brut. Utilisez un système de stockage sécurisé adapté à votre plate-forme, tel que Keystore sur Android, les services de trousseau sur iOS et macOS, ou Credential Locker sur Windows.
Révoquez les jetons dès qu'ils ne sont plus nécessaires et supprimez-les définitivement de vos systèmes.
Tenez également compte des bonnes pratiques suivantes pour votre plate-forme :
- Pour les applications côté serveur qui stockent des jetons pour de nombreux utilisateurs, chiffrez-les au repos et assurez-vous que votre datastore n'est pas accessible publiquement sur Internet.
- Pour les applications de bureau, il est fortement recommandé d'utiliser le protocole PKCE (Proof Key for Code Exchange, clé de vérification pour l'échange de code) afin d'obtenir des codes d'autorisation qui peuvent être échangés contre des jetons d'accès.
Limiter les jetons de l'expéditeur avec DPoP
Pour protéger votre application contre le vol de jetons et les attaques par rejeu, envisagez de limiter les jetons de l'expéditeur à l'aide de DPoP (Demonstrating Proof-of-Possession, démonstration de la preuve de possession). Alors que les jetons de support standards peuvent être utilisés par toute partie qui les intercepte, les jetons DPoP sont liés de manière cryptographique à une paire de clés unique générée et détenue par le client.
Lorsque vous utilisez DPoP, le client présente une preuve (un jeton Web JSON signé) au point de terminaison du jeton lors de la demande ou de l'actualisation des jetons. Cette preuve démontre que le client est en possession de la clé privée qui correspond à la clé publique liée au jeton. Si un jeton d'actualisation lié à DPoP est divulgué, il ne peut pas être rejoué par un attaquant sans cette clé privée.
DPoP fonctionne avec PKCE pour offrir une protection complète :
- PKCE protège le code d'autorisation lors du flux de redirection initial.
- DPoP protège le jeton d'actualisation à longue durée de vie, empêchant les attaques par rejeu en cas de compromission.
L'adoption de DPoP est fortement recommandée si votre application :
- fonctionne en tant que client public (par exemple, une application à page unique ou une application installée) où les jetons d'actualisation peuvent être plus susceptibles d'être exfiltrés ;
- accède à des données très sensibles ou à des API à forte valeur ajoutée, où l'impact de la fuite de jetons est important ;
- doit respecter des normes de conformité ou de sécurité strictes qui imposent des jetons limités à l'expéditeur.
Pour obtenir des instructions détaillées sur la création de preuves DPoP et la demande de jetons liés à DPoP, consultez la documentation DPoP.
Utiliser le paramètre d'état
Avant de gérer une réponse OAuth 2.0, vérifiez que le state reçu de
Google correspond au state envoyé dans votre demande d'autorisation. Le paramètre
state doit être une valeur unique et non devinable générée par votre
application.
L'utilisation du paramètre state permet de s'assurer que la requête est effectuée par l'utilisateur et non par un script malveillant, et réduit le risque d'attaques par contrefaçon de requêtes intersites
(CSRF).
Gérer la révocation et l'expiration des jetons d'actualisation
Si votre application a demandé un jeton d'actualisation pour un accès hors connexion, vous devez également gérer son invalidation ou son expiration. Les jetons peuvent être invalidés pour différentes raisons, par exemple, ils peuvent avoir expiré ou l'accès de vos applications peut avoir été révoqué par l'utilisateur ou un processus automatisé. Dans ce cas, réfléchissez attentivement à la manière dont votre application doit répondre, y compris en invitant l’utilisateur à se connecter à nouveau ou en nettoyant ses données. Pour être informé de la révocation des jetons, intégrez le service de protection multicompte.
Utiliser l'autorisation incrémentielle
Utilisez l'autorisation incrémentielle pour demander les habilitations OAuth appropriées lorsque votre application a besoin de la fonctionnalité.
Vous ne devez pas demander l'accès aux données lors de la première authentification de l'utilisateur, sauf si cela est essentiel pour la fonctionnalité de base de votre application. Au lieu de cela, ne demandez que les habilitations spécifiques nécessaires à une tâche, en suivant le principe de sélectionner les habilitations les plus petites et les plus limitées possibles.
Demandez toujours des habilitations dans le contexte pour aider vos utilisateurs à comprendre pourquoi votre application demande l'accès et comment les données seront utilisées.
Par exemple, votre application peut suivre ce modèle :
- L'utilisateur s'authentifie auprès de votre application.
- Aucune habilitation supplémentaire n'est demandée. L'application fournit des fonctionnalités de base pour permettre à l'utilisateur explorer et utiliser des fonctionnalités qui ne nécessitent aucune donnée ni aucun accès supplémentaires.
- L'utilisateur sélectionne une fonctionnalité qui nécessite l'accès à des données supplémentaires.
- Votre application effectue une demande d'autorisation pour cette habilitation OAuth spécifique requise pour cette fonctionnalité. Si cette fonctionnalité nécessite plusieurs habilitations, suivez les bonnes pratiques pour plusieurs habilitations.
- Si l'utilisateur refuse la demande, l'application désactive la fonctionnalité et lui fournit un contexte supplémentaire pour demander à nouveau l'accès.
Gérer le consentement pour plusieurs habilitations
Lorsque vous demandez plusieurs habilitations à la fois, les utilisateurs peuvent ne pas accorder toutes les habilitations OAuth que vous avez demandées. Votre application doit gérer le refus des habilitations en désactivant les fonctionnalités concernées.
Si la fonctionnalité de base de votre application nécessite plusieurs habilitations, expliquez-le à l'utilisateur avant de lui demander son consentement.
Vous ne pouvez inviter l'utilisateur à nouveau que lorsqu'il a clairement indiqué son intention d'utiliser la fonctionnalité spécifique qui nécessite l'habilitation. Votre application doit fournir à l'utilisateur un contexte pertinent et une justification avant de demander des habilitations OAuth.
Vous devez réduire le nombre d'habilitations que votre application demande à la fois. Utilisez plutôt l'autorisation incrémentielle pour demander des habilitations dans le contexte des fonctionnalités.
Utiliser des navigateurs sécurisés
Sur le Web, les demandes d'autorisation OAuth 2.0 ne doivent être effectuées qu'à partir de navigateurs Web complets. Sur d'autres plates-formes, veillez à sélectionner le type de client OAuth approprié et à intégrer OAuth de manière appropriée à votre plate-forme. Ne redirigez pas la requête via des environnements de navigation intégrés y compris des vues Web sur des plates-formes mobiles, telles que WebView sur Android ou WKWebView sur iOS. Utilisez plutôt les bibliothèques OAuth recommandées ou Google Sign-in pour votre plate-forme.
Création et configuration manuelles de clients OAuth
Afin d'éviter les abus, les clients OAuth ne peuvent pas être créés ni modifiés par programmation. Vous devez utiliser la console Google Cloud pour accepter explicitement les conditions d'utilisation, configurer votre client OAuth et vous préparer à la validation OAuth.
Pour les workflows automatisés, envisagez plutôt d'utiliser des comptes de service.
Supprimer les clients OAuth inutilisés
Vérifiez régulièrement vos clients OAuth 2.0 et supprimez de manière proactive ceux qui ne sont plus requis par votre application ou qui sont devenus obsolètes. Laisser des clients inutilisés configurés représente un risque de sécurité potentiel, car le client peut être utilisé à mauvais escient si vos identifiants client sont compromis.
Pour réduire davantage les risques liés aux clients inutilisés, les clients OAuth 2.0 inactifs depuis six mois sont automatiquement supprimés.
La bonne pratique recommandée consiste à ne pas attendre la suppression automatique, mais à supprimer de manière proactive les clients inutilisés. Cette pratique réduit la surface d'attaque de votre application et garantit une bonne hygiène de sécurité.