Bonnes pratiques

Gérer les identifiants client de manière sécurisée

Les identifiants du client OAuth identifient votre application et doivent être traités avec précaution. Stockez ces identifiants uniquement 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 les identifiants en dur, ne les enregistrez 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, Keychain Services 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, nous vous recommandons vivement d'utiliser le protocole PKCE (Proof Key for Code Exchange) afin d'obtenir des codes d'autorisation pouvant être échangés contre des jetons d'accès.

Limiter les jetons à l'expéditeur avec DPoP

Pour protéger votre application contre le vol de jetons et les attaques par rejeu, envisagez de limiter l'expéditeur de vos jetons à l'aide de DPoP (Demonstrating Proof-of-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.

Lorsqu'il utilise DPoP, le client présente une preuve (un jeton Web JSON signé) au point de terminaison de jeton lorsqu'il demande ou actualise 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é, un pirate informatique ne peut pas le rejouer sans cette clé privée.

DPoP fonctionne avec PKCE pour fournir une protection complète :

• PKCE protège le code d'autorisation lors du flux de redirection initial.
• DPoP protège le jeton d'actualisation de longue durée, ce qui empêche les attaques par rejeu s'il est compromis.

Nous vous recommandons vivement d'adopter le protocole DPoP si votre application :

• Fonctionne comme une application installée ou de bureau (ou une application monopage associée à un serveur Backend-for-Frontend) où les jetons d'actualisation peuvent être plus susceptibles d'être exfiltrés.
• Accède à des données hautement sensibles ou à des API de grande valeur, où l'impact d'une fuite de jeton est important.
• Vous devez 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 le guide d'adoption de DPoP.

Utiliser le paramètre d'état

Avant de traiter 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 l'utilisateur, et non un script malveillant, effectue la requête, et réduit le risque d'attaques par falsification 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 l'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 par un processus automatisé. Dans ce cas, réfléchissez bien à la manière dont votre application doit réagir, par exemple en invitant l'utilisateur à se connecter lors de sa prochaine connexion ou en nettoyant ses données. Pour être informé de la révocation d'un jeton, intégrez le service de protection multicompte.

Utiliser l'autorisation incrémentielle

Utilisez l'autorisation incrémentielle pour demander les champs d'application OAuth appropriés 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. Demandez plutôt uniquement les champs d'application spécifiques nécessaires à une tâche, en suivant le principe de sélection des champs d'application les plus petits et les plus limités possible.

Demandez toujours des champs d'application en 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 :

1. L'utilisateur s'authentifie auprès de votre application.
   1. Aucun niveau d'accès supplémentaire n'est demandé. L'application fournit des fonctionnalités de base pour permettre à l'utilisateur d'explorer et d'utiliser des fonctionnalités qui ne nécessitent pas de données ni d'accès supplémentaires.
2. L'utilisateur sélectionne une fonctionnalité qui nécessite l'accès à des données supplémentaires.
   1. Votre application envoie une demande d'autorisation pour le niveau d'accès OAuth spécifique requis pour cette fonctionnalité. Si cette fonctionnalité nécessite plusieurs champs d'application, suivez les bonnes pratiques pour les champs d'application multiples.
   2. Si l'utilisateur refuse la demande, l'application désactive la fonctionnalité et fournit à l'utilisateur des informations supplémentaires pour demander à nouveau l'accès.

Gérer le consentement pour plusieurs champs d'application

Lorsque vous demandez plusieurs champs d'application à la fois, les utilisateurs peuvent ne pas accorder tous les champs d'application OAuth que vous avez demandés. Votre application doit gérer le refus des champs d'application en désactivant les fonctionnalités concernées.

Si la fonctionnalité de base de votre application nécessite plusieurs champs d'application, expliquez-le à l'utilisateur avant de lui demander son consentement.

Vous ne pouvez inviter à nouveau l'utilisateur que lorsqu'il a clairement indiqué son intention d'utiliser la fonctionnalité spécifique qui nécessite le champ d'application. Votre application doit fournir à l'utilisateur le contexte et la justification appropriés avant de demander des champs d'application OAuth.

Vous devez réduire le nombre de champs d'application que votre application demande simultanément. Utilisez plutôt l'autorisation incrémentielle pour demander des champs d'application dans le contexte des fonctionnalités.

Utiliser des navigateurs sécurisés

Sur le Web, les requêtes d'autorisation OAuth 2.0 ne doivent être effectuées qu'à partir de navigateurs Web complets. Sur les autres plates-formes, veillez à sélectionner le type de client OAuth approprié et à intégrer OAuth en fonction de votre plate-forme. Ne redirigez pas la requête via des environnements de navigation intégrés, y compris les composants WebView sur les plates-formes mobiles, tels 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

Pour éviter les abus, les clients OAuth ne peuvent pas être créés ni modifiés de manière programmatique. Vous devez utiliser la console Google Cloud pour accepter explicitement les conditions d'utilisation, configurer votre client OAuth et 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

Auditez 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é de manière abusive si vos identifiants client sont compromis.

Pour limiter 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é.