Cette page présente quelques bonnes pratiques générales concernant l'intégration d'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 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 ou ne les publiez pas publiquement.
Gérer les jetons utilisateur de manière sécurisée
Les jetons utilisateur incluent à la fois des jetons d'actualisation et des 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 sous 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 data store 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) 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. Il est par exemple possible qu'ils aient expiré, ou que l'accès à vos applications ait é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, y compris en invitant l'utilisateur à sa prochaine connexion ou en nettoyant ses données. Pour être informé de la révocation du jeton, intégrez le service de protection multicompte.
Utiliser une 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 à 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 pour aider vos utilisateurs à comprendre pourquoi votre application demande l'accès et comment les données seront utilisées.
Votre application peut par exemple suivre ce modèle:
- L'utilisateur s'authentifie auprès de votre application.
- Aucun champ d'application supplémentaire n'est demandé. L'appli fournit 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é qui nécessite d'accéder à des données supplémentaires.
- Votre application envoie une demande d'autorisation pour ce champ d'application OAuth spécifique, requis pour cette fonctionnalité. Si cette fonctionnalité nécessite plusieurs niveaux d'accès, suivez les bonnes pratiques ci-dessous.
- Si l'utilisateur refuse la requête, l'application désactive la fonctionnalité et lui fournit davantage de contexte pour demander à nouveau l'accès.
Gérer le consentement pour plusieurs champs d'application
Lorsqu'ils demandent 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 les fonctionnalités de base de votre application nécessitent plusieurs niveaux d'accès, expliquez-les à l'utilisateur avant de demander son consentement.
Vous ne pouvez inviter l'utilisateur qu'une fois qu'il a clairement indiqué son intention d'utiliser la fonctionnalité spécifique nécessitant le champ d'application. Votre application doit fournir à l'utilisateur le contexte et la justification pertinents avant de demander des champs d'application OAuth.
Nous vous conseillons de réduire le nombre de champs d'application demandés simultanément par votre application. Utilisez plutôt une autorisation incrémentielle pour demander des champs d'application dans le contexte de fonctionnalités et de fonctionnalités.
Utilisez 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 WebView 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 par programmation. 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.