Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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é.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/31 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/31 (UTC)."],[[["\u003cp\u003eSecurely store and manage OAuth client credentials, avoiding hardcoding or public exposure.\u003c/p\u003e\n"],["\u003cp\u003eProtect user tokens (refresh and access) by storing them securely and revoking them when no longer needed.\u003c/p\u003e\n"],["\u003cp\u003eImplement proper handling of refresh token revocation and expiration scenarios, including user notification and data cleanup.\u003c/p\u003e\n"],["\u003cp\u003eUtilize incremental authorization to request only necessary OAuth scopes in context, minimizing initial requests and enhancing user privacy.\u003c/p\u003e\n"],["\u003cp\u003eEmploy secure browsing environments for OAuth authorization requests, avoiding embedded browsers like webviews and opting for native libraries or Google Sign-in.\u003c/p\u003e\n"]]],[],null,["This page covers some general best practices for integrating with OAuth 2.0. Consider these best\npractices in addition to any specific guidance for your type of application and development\nplatform. Also refer to the\n[advice for getting\nyour app ready for production](/identity/protocols/oauth2/production-readiness/policy-compliance) and [Google's\nOAuth 2.0 policies](/identity/protocols/oauth2/policies).\n\nHandle client credentials securely\n\n\nThe OAuth client credentials identify your app's identity and should be handled carefully. Only\nstore these credentials in secure storage, for example using a secret manager such as\n[Google Cloud Secret Manager](https://cloud.google.com/secret-manager/docs/overview).\nDo not hardcode the credentials, commit them to a code repository or publish them publicly.\n\nHandle user tokens securely\n\n\nUser tokens include both refresh tokens and access tokens used by your application. Store\ntokens securely [at rest](https://wikipedia.org/wiki/Data_at_rest)\nand never transmit them in plain text. Use a secure storage system appropriate for your\nplatform, such as\n[Keystore](https://developer.android.com/training/articles/keystore) on Android,\nKeychain Services on iOS and macOS, or Credential Locker on Windows.\n\n\n[Revoke tokens](/identity/protocols/oauth2/web-server#tokenrevoke) as soon as they\nare no longer needed and delete them permanently from your systems.\n\n\nIn addition, also consider these best practices for your platform:\n\n- For [server-side](/identity/protocols/oauth2/web-server) applications that store tokens for many users, encrypt them at rest and ensure that your data store is not publicly accessible to the Internet.\n- For native desktop apps, using the [Proof Key for Code\n Exchange (PKCE) protocol](/identity/protocols/oauth2/native-app#obtainingaccesstokens) is strongly recommended to obtain authorization codes that can be exchanged for access tokens.\n\nHandle refresh token revocation and expiration\n\n\nIf your app has requested a [refresh\ntoken for offline access](/identity/protocols/oauth2/web-server#offline), you must also handle their invalidation or expiration. Tokens\ncould be [invalidated for different reasons](/identity/protocols/oauth2#expiration),\nfor example it could have expired or your apps' access could have been revoked by the user or\nan automated process. In this case, consider carefully how your application should respond,\nincluding prompting the user at their next log in or cleaning up their data. To be notified of\ntoken revocation, integrate with the [Cross-Account\nProtection](/identity/protocols/risc) service.\n\nUse incremental authorization\n\n\nUse [incremental\nauthorization](/identity/protocols/oauth2/web-server#incrementalAuth) to request appropriate OAuth scopes when the functionality is needed by your\napplication.\n\n\nYou should not request access to data when the user first authenticates, unless it is essential\nfor the core functionality of your app. Instead, request only the specific scopes that are\nneeded for a task, following the principle to\n[select the smallest, most limited scopes possible](/identity/protocols/oauth2/production-readiness/policy-compliance#only-request-needed-scopes).\n\n\nAlways request scopes in context to help your users understand why your app is requesting access\nand how the data will be used.\n\n\nFor example, your application may follow this model:\n\n1. The user authenticates with your app\n 1. No additional scopes are requested. The app provides basic functionality to let the user explore and use features that do not require any additional data or access.\n2. The user selects a feature that requires access to additional data\n 1. Your application makes an authorization request for this specific OAuth scope required for this feature. If this feature requires multiple scopes, follow [the best practices below](#multiple-scopes).\n 2. If the user denies the request, the app disables the feature and gives the user additional context to request access again.\n\nHandle consent for multiple scopes\n\n\nWhen requesting multiple scopes at once, users may not grant all OAuth scopes you have\nrequested. Your app should handle the denial of scopes by disabling relevant functionality.\n\n\nIf your app's basic functionality requires multiple scopes, explain this to the user before\nprompting for consent.\n\n\nYou may only prompt the user again once they have clearly indicated an intent to use the\nspecific feature that requires the scope. Your app should provide the user with relevant context\nand justification before requesting OAuth scopes.\n\n\nYou should minimize the number of scopes your app requests at once. Instead,\n[utilize incremental authorization](#use-incremental-authorization) to request scopes\nin context of features and functionality.\n\nUse secure browsers\n\n\nOn the web, OAuth 2.0 authorization requests must only be made from full-featured web browsers.\nOn other platforms, make sure to select the\n[correct OAuth client type](/identity/protocols/oauth2#basicsteps) and integrate\nOAuth as appropriate for your platform. Do not redirect the request through embedded browsing\nenvironments, including webviews on mobile platforms, such as WebView on Android or WKWebView on\niOS. Instead, utilize [native OAuth libraries](/identity/protocols/oauth2/native-app)\nor [Google Sign-in](/identity/authorization) for your platform.\n\nManual creation and configuration of OAuth clients\n\n\nIn order to prevent abuse, OAuth clients cannot be created or modified programmatically. You\nmust use the Google Developers console to explicitly acknowledge the terms of service, configure\nyour OAuth client and prepare for OAuth verification.\n\n\nFor automated workflows, consider using\n[service accounts](/identity/protocols/oauth2/service-account) instead.\n\nRemove unused OAuth clients\n\n\nRegularly audit your OAuth 2.0 clients and proactively delete any that are no longer required by\nyour application or have become obsolete. Leaving unused clients configured represents a\npotential security risk as the client can be misused if your client credentials are ever\ncompromised.\n\n\nTo further mitigate risks from unused clients, OAuth 2.0 clients that have been inactive for six\nmonths are [automatically deleted](https://support.google.com/cloud/answer/15549257#unused-client-deletion).\n\n\nThe recommended best practice is to not wait for automatic deletion but rather proactively\nremove unused clients. This practice minimizes your application's attack surface and ensures\ngood security hygiene."]]
