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 de client OAuth permettent d'identifier 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 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 que vous n'en avez plus besoin 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 natives, il est vivement recommandé d'utiliser le protocole PKCE (Proof Key for Code Exchange) pour obtenir des codes d'autorisation pouvant être échangés contre des jetons d'accès.
Gérer la révocation et l'expiration du jeton 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 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 averti de la révocation d'un jeton, intégrez le service Protection multicompte.
Utiliser l'autorisation incrémentielle
Utilisez l'autorisation incrémentielle pour demander les niveaux d'accès 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 niveaux d'accès spécifiques nécessaires à une tâche, en suivant le principe de sélection des niveaux d'accès les plus petits et les plus limités possible.
Demandez toujours les niveaux d'accès 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 :
- L'utilisateur s'authentifie auprès de votre application.
- Aucun autre champ d'application n'est demandé. L'application fournit des fonctionnalités de base permettant à l'utilisateur d'explorer et d'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 envoie une demande d'autorisation pour cette habilitation OAuth spécifique requise pour cette fonctionnalité. Si cette fonctionnalité nécessite plusieurs niveaux d'accès, suivez les bonnes pratiques ci-dessous.
- Si l'utilisateur refuse la demande, l'application désactive la fonctionnalité et lui fournit des informations supplémentaires pour qu'il puisse demander à nouveau l'accès.
Gérer le consentement pour plusieurs niveaux d'accès
Lorsque vous demandez plusieurs habilitations à la fois, il est possible que les utilisateurs n'accordent pas toutes celles que vous avez demandées. Votre application doit gérer le refus des autorisations en désactivant les fonctionnalités concernées.
Si la fonctionnalité de base de votre application nécessite plusieurs autorisations, expliquez-le à l'utilisateur avant de lui demander son consentement.
Vous ne pouvez de nouveau inviter l'utilisateur à accorder l'autorisation que s'il a clairement indiqué qu'il souhaitait 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 les niveaux d'accès OAuth.
Vous devez réduire au minimum le nombre de niveaux d'accès demandés par votre application à la fois. À la place, utilisez l'autorisation incrémentielle pour demander des autorisations 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 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 demande via des environnements de navigation intégrés, y compris les WebViews sur les plates-formes mobiles, telles que WebView sur Android ou WKWebView sur iOS. Utilisez plutôt les bibliothèques OAuth natives ou Se connecter avec Google pour votre plate-forme.
Créer et configurer manuellement des clients OAuth
Pour éviter tout abus, il est impossible de créer ou de modifier des clients OAuth par programmation. Vous devez utiliser la console Google Developers 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
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é à mauvais escient 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 supprimés automatiquement.
La bonne pratique recommandée consiste à ne pas attendre la suppression automatique, mais à supprimer de manière proactive les clients inutilisés. Cette pratique permet de réduire au minimum la surface d'attaque de votre application et de garantir une bonne hygiène de sécurité.