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 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 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 natives, il est fortement recommandé d'utiliser le protocole PKCE (Proof Key for Code Exchange, clé de vérification pour l'échange de code) afin d'obtenir des codes d'autorisation qui peuvent être échangés contre des jetons d'accès.
Utiliser le paramètre d'état
Avant de gérer 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étrage state permet de s'assurer que la requête est effectuée par l'utilisateur et non par un script malveillant, et réduit le risque d'attaques Cross-Site Request Forgery
(CSRF).
Gérer la révocation et l'expiration des jetons d'actualisation
Si votre application a demandé un jeton d'actualisation pour un 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 informé de la révocation des jetons, intégrez-vous au 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. Au lieu de cela, ne demandez que les champs d'application spécifiques nécessaires à une tâche, en suivant le principe de sélectionner les champs d'application les plus petits et les plus limités possibles.
Demandez toujours les champs d'application dans le 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 champ d'application supplémentaire n'est demandé. L'application fournit des fonctionnalités de base pour permettre à l'utilisateur explorer et 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 effectue une demande d'autorisation pour ce 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 demande, l'application désactive la fonctionnalité et lui 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, 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 pertinentes.
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 l'utilisateur à nouveau 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 un contexte et une justification pertinents avant de demander les champs d'application OAuth.
Vous devez réduire le nombre de champs d'application que votre application demande à la fois. 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 demandes d'autorisation OAuth 2.0 ne doivent être effectuées qu'à partir de navigateurs Web complets. Sur d'autres plates-formes, veillez à sélectionner le type de client OAuth approprié et à intégrer OAuth de manière appropriée pour votre plate-forme. Ne redirigez pas la requête via des environnements de navigation intégrés y compris des vues Web 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
Afin d'éviter les abus, les clients OAuth ne peuvent pas être créés ni modifiés 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
Vérifiez 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 réduire 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é.