Cette page présente quelques bonnes pratiques générales concernant l'intégration à 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. Reportez-vous également aux conseils pour préparer votre application pour la production et aux règles OAuth 2.0 de Google.
Gérer les identifiants client de manière sécurisée
Les identifiants du client OAuth identifient l'identité de votre application et doivent être manipulés avec le plus grand 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 les identifiants en dur, ne les validez 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 en toute sécurité 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 trousseaux sur iOS et macOS ou Credential Locker sous 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 data store n'est pas accessible publiquement sur Internet.
- Pour les applications de bureau natives, il est vivement recommandé d'utiliser le protocole PKCE (clé de vérification pour l'échange de code) 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 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 à vos applications peut avoir été révoqué par l'utilisateur ou un processus automatisé. Dans ce cas, réfléchissez bien à la manière dont votre application doit répondre, par exemple en invitant l'utilisateur à se connecter ou en nettoyant ses données. Pour recevoir une notification en cas de 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 en a besoin.
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 champs d'application spécifiques nécessaires pour une tâche, selon le principe qui consiste à sélectionner les champs d'application les plus petits et les plus limités possibles.
Demandez toujours les champs d'application en contexte afin d'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 champ d'application supplémentaire n'est demandé. L'appli offre des fonctionnalités de base permettant à l'utilisateur d'explorer et d'utiliser des fonctionnalités qui ne nécessitent aucun accès ni aucune donnée supplémentaire.
- L'utilisateur sélectionne une fonctionnalité nécessitant l'accès à des données supplémentaires.
- Votre application envoie une demande d'autorisation pour le champ d'application OAuth spécifique requis pour cette fonctionnalité. Si cette fonctionnalité nécessite plusieurs champs d'application, suivez les bonnes pratiques ci-dessous.
- Si l'utilisateur refuse la requête, l'application désactive la fonctionnalité et lui fournit du contexte supplémentaire pour redemander 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 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 demander son consentement.
Vous ne pouvez redemander à l'utilisateur qu'une fois qu'il a clairement indiqué qu'il souhaitait utiliser la fonctionnalité spécifique qui nécessite ce champ d'application. Votre application doit fournir à l'utilisateur le contexte et la justification pertinents avant de demander des champs d'application OAuth.
Vous devez réduire le nombre de champs d'application demandés par votre application en même temps. Utilisez plutôt une autorisation incrémentielle pour demander des niveaux d'accès selon les 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 d'un navigateur Web complet. Sur les autres plates-formes, assurez-vous de sélectionner le type de client OAuth approprié et d'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 des WebViews sur des 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éation et configuration manuelles de clients OAuth
Pour éviter toute utilisation abusive, les clients OAuth ne peuvent pas être créés ni modifiés de manière programmatique. Vous devez utiliser la Google Developers Console 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.