Cette page présente quelques bonnes pratiques générales pour l'intégration avec OAuth 2.0. Tenez compte de ces bonnes pratiques en plus des conseils spécifiques à votre type d'application et de 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 identifient l'identité de votre application et doivent être traité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 ni ne les publiez publiquement.
Gérer les jetons utilisateur de manière sécurisée
Les jetons utilisateur incluent à la fois 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 le 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.
En outre, tenez 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 entrepôt de données n'est pas accessible publiquement sur Internet.
- Pour les applications natives pour ordinateur, il est vivement recommandé 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.
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 s'ils ont expiré ou si l'accès de vos applications a été révoqué par l'utilisateur ou par un processus automatisé. Dans ce cas, réfléchissez attentivement à la façon 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 du jeton, intégrez le service Protection multicompte.
Utiliser l'autorisation incrémentielle
Utilisez l'autorisation incrémentielle pour demander les portées OAuth appropriées lorsque la fonctionnalité est nécessaire à votre application.
Vous ne devez pas demander l'accès aux données lorsque l'utilisateur s'authentifie pour la première fois, sauf si cela est essentiel pour la fonctionnalité de base de votre application. Demandez plutôt uniquement les portées spécifiques nécessaires à une tâche, en suivant le principe de sélection des portées les plus petites et les plus limitées possibles.
Demandez toujours des portées 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 le modèle suivant:
- L'utilisateur s'authentifie auprès de votre application.
- Aucun champ d'application supplémentaire 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 requête 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 fournit un contexte supplémentaire pour demander à nouveau l'accès.
Gérer le consentement pour plusieurs champs d'application
Lorsque vous demandez plusieurs champs d'application à la fois, il est possible que les utilisateurs n'accordent pas 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 la fonctionnalité concernée.
Si les fonctionnalités de base de votre application nécessitent plusieurs champs d'application, expliquez-le à l'utilisateur avant de lui demander son consentement.
Vous ne pouvez inviter l'utilisateur à nouveau qu'une fois qu'il a clairement indiqué son intention d'utiliser la fonctionnalité spécifique nécessitant la portée. Votre application doit fournir à l'utilisateur un contexte et une justification pertinents avant de demander des champs d'application OAuth.
Vous devez réduire au maximum le nombre de champs d'application que votre application demande en même temps. À la place, utilisez l'autorisation incrémentielle pour demander des champs d'application en fonction 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 que depuis des navigateurs Web complets. Sur d'autres plates-formes, veillez à sélectionner le bon type de client OAuth 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 WebView sur les plates-formes mobiles, telles que WebView sur Android ou WKWebView sur iOS. Utilisez plutôt des bibliothèques OAuth natives ou Google Sign-In pour votre plate-forme.
Créer et configurer manuellement des clients OAuth
Pour éviter toute utilisation abusive, il est impossible de créer ou de modifier des clients OAuth par programmation. Vous devez utiliser la console pour les développeurs Google 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.