Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describen algunas prácticas recomendadas generales para la integración con OAuth 2.0. Considera estas prácticas recomendadas, además de cualquier orientación específica para tu tipo de aplicación y plataforma de desarrollo. Consulta también el asesoramiento para preparar tu app para producción y las políticas de OAuth 2.0 de Google.
Administra las credenciales de cliente de forma segura
Las credenciales de cliente de OAuth identifican la identidad de tu app y deben manejarse con cuidado. Solo almacena estas credenciales en un almacenamiento seguro, por ejemplo, con un administrador de secretos como Google Cloud Secret Manager.
No codifiques de forma rígida las credenciales, no las confirmes en un repositorio de código ni las publiques de forma pública.
Cómo controlar los tokens de usuario de forma segura
Los tokens de usuario incluyen tanto los tokens de actualización como los tokens de acceso que usa tu aplicación. Almacena los tokens de forma segura en reposo y nunca los transmitas como texto sin formato. Usa un sistema de almacenamiento seguro adecuado para tu plataforma, como Keystore en Android, Keychain Services en iOS y macOS, o Credential Locker en Windows.
Revoca los tokens en cuanto ya no los necesites y bórralos de forma permanente de tus sistemas.
Además, considera estas prácticas recomendadas para tu plataforma:
En el caso de las aplicaciones del servidor que almacenan tokens para muchos usuarios, encripta los tokens en reposo y asegúrate de que tu almacén de datos no sea accesible públicamente a través de Internet.
Cómo controlar la revocación y el vencimiento de tokens de actualización
Si tu app solicitó un token de actualización para el acceso sin conexión, también debes controlar su invalidación o vencimiento. Los tokens se pueden invalidar por diferentes motivos, por ejemplo, porque vencieron o porque el usuario o un proceso automatizado revocaron el acceso de tus apps. En este caso, considera cuidadosamente cómo debería responder tu aplicación, lo que incluye solicitarle al usuario que acceda la próxima vez o limpiar sus datos. Para recibir notificaciones sobre la revocación de tokens, realiza la integración con el servicio de Protección integral de la cuenta.
Usa la autorización incremental
Usa la autorización incremental para solicitar los alcances de OAuth adecuados cuando tu aplicación necesite la funcionalidad.
No debes solicitar acceso a los datos cuando el usuario se autentica por primera vez, a menos que sea esencial para la funcionalidad principal de tu app. En cambio, solicita solo los permisos específicos que se necesiten para una tarea, siguiendo el principio de seleccionar los permisos más pequeños y limitados posibles.
Siempre solicita permisos en contexto para ayudar a los usuarios a comprender por qué tu app solicita acceso y cómo se usarán los datos.
Por ejemplo, tu aplicación podría seguir este modelo:
El usuario se autentica con tu app.
No se solicitan permisos adicionales. La app proporciona funciones básicas para que el usuario
explore y use funciones que no requieren datos ni acceso adicionales.
El usuario selecciona una función que requiere acceso a datos adicionales.
Tu aplicación realiza una solicitud de autorización para este permiso de OAuth específico que se requiere para esta función. Si esta función requiere varios permisos, sigue las prácticas recomendadas que se indican a continuación.
Si el usuario rechaza la solicitud, la app inhabilita la función y le brinda contexto adicional para que vuelva a solicitar acceso.
Cómo controlar el consentimiento para varios permisos
Cuando solicitas varios permisos a la vez, es posible que los usuarios no otorguen todos los permisos de OAuth que solicitaste. Tu app debe controlar el rechazo de los permisos inhabilitando la funcionalidad pertinente.
Si la funcionalidad básica de tu app requiere varios permisos, explícale esto al usuario antes de solicitar su consentimiento.
Solo puedes volver a solicitarle al usuario que realice la acción una vez que haya indicado claramente su intención de usar la función específica que requiere el alcance. Tu app debe proporcionar al usuario contexto y justificación relevantes antes de solicitar permisos de OAuth.
Debes minimizar la cantidad de permisos que tu app solicita a la vez. En su lugar, utiliza la autorización incremental para solicitar permisos en el contexto de las funciones y la funcionalidad.
Usa navegadores seguros
En la Web, las solicitudes de autorización de OAuth 2.0 solo se deben realizar desde navegadores web con todas las funciones.
En otras plataformas, asegúrate de seleccionar el tipo de cliente de OAuth correcto y de integrar OAuth según corresponda a tu plataforma. No redirecciones la solicitud a través de entornos de navegación incorporados, incluidas las WebView en plataformas para dispositivos móviles, como WebView en Android o WKWebView en iOS. En su lugar, utiliza bibliotecas de OAuth nativas o Acceder con Google para tu plataforma.
Creación y configuración manuales de clientes de OAuth
Para evitar abusos, los clientes de OAuth no se pueden crear ni modificar de forma programática. Debes usar la consola de Google Developers para confirmar explícitamente las condiciones del servicio, configurar tu cliente de OAuth y prepararte para la verificación de OAuth.
Para los flujos de trabajo automatizados, considera usar cuentas de servicio.
Quita los clientes de OAuth que no se usen
Audita periódicamente tus clientes de OAuth 2.0 y borra de forma proactiva los que tu aplicación ya no necesite o los que hayan quedado obsoletos. Dejar configurados clientes sin usar representa un riesgo de seguridad potencial, ya que el cliente se puede usar de forma inadecuada si alguna vez se vulneran tus credenciales de cliente.
Para mitigar aún más los riesgos de los clientes no utilizados, los clientes de OAuth 2.0 que hayan estado inactivos durante seis meses se
borran automáticamente.
La práctica recomendada es no esperar a que se borren automáticamente los clientes, sino quitarlos de forma proactiva. Esta práctica minimiza la superficie de ataque de tu aplicación y garantiza una buena higiene de seguridad.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]