Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página aborda algumas práticas recomendadas gerais para integração com o OAuth 2.0. Considere essas práticas recomendadas, além de orientações específicas para seu tipo de aplicativo e plataforma de desenvolvimento. Consulte também as
dicas para preparar
seu app para produção e as políticas
do OAuth 2.0 do Google.
Processar credenciais de cliente com segurança
As credenciais do cliente OAuth identificam a identidade do seu app e precisam ser tratadas com cuidado. Armazene essas credenciais apenas em um armazenamento seguro, por exemplo, usando um gerenciador de secrets como o Google Cloud Secret Manager.
Não codifique as credenciais, faça commit delas em um repositório de código nem as publique.
Processar tokens de usuário com segurança
Os tokens de usuário incluem tokens de atualização e de acesso usados pelo aplicativo. Armazene tokens de forma segura em repouso e nunca os transmita em texto simples. Use um sistema de armazenamento seguro adequado para sua plataforma, como Keystore no Android, Keychain Services no iOS e macOS ou Credential Locker no Windows.
Revogue os tokens assim que eles não forem mais necessários e exclua-os permanentemente dos seus sistemas.
Além disso, considere estas práticas recomendadas para sua plataforma:
Para aplicativos do lado do servidor que armazenam tokens de muitos usuários, criptografe-os em repouso e garanta que o repositório de dados não esteja acessível publicamente à Internet.
Processar a revogação e a expiração do token de atualização
Se o app tiver solicitado um token de atualização para acesso off-line, você também precisará processar a invalidação ou expiração dele. Os tokens
podem ser invalidados por diferentes motivos,
por exemplo, eles podem ter expirado ou o acesso dos seus apps pode ter sido revogado pelo usuário ou
por um processo automatizado. Nesse caso, considere cuidadosamente como o aplicativo deve responder, incluindo solicitar ao usuário no próximo login ou limpar os dados dele. Para receber notificações sobre
revogação de token, faça a integração com o serviço Proteção
entre contas.
Usar autorização incremental
Use a autorização incremental para solicitar os escopos do OAuth adequados quando a funcionalidade for necessária para seu aplicativo.
Não solicite acesso a dados quando o usuário se autenticar pela primeira vez, a menos que seja essencial
para a funcionalidade principal do app. Em vez disso, solicite apenas os escopos específicos necessários
para uma tarefa, seguindo o princípio de
selecionar os escopos menores e mais limitados possíveis.
Sempre solicite escopos de acordo com o contexto para ajudar os usuários a entender por que o app está pedindo acesso e como os dados serão usados.
Por exemplo, seu aplicativo pode seguir este modelo:
O usuário se autentica com seu app
Nenhum escopo adicional é solicitado. O app oferece funcionalidades básicas para que o usuário
explore e use recursos que não exigem dados ou acesso adicionais.
O usuário seleciona um recurso que exige acesso a dados adicionais
Seu aplicativo faz uma solicitação de autorização para esse escopo específico do OAuth necessário
para esse recurso. Se esse recurso exigir vários escopos, siga
as práticas recomendadas abaixo.
Se o usuário negar a solicitação, o app vai desativar o recurso e dar a ele
mais contexto para solicitar acesso novamente.
Processar o consentimento para vários escopos
Ao solicitar vários escopos de uma vez, os usuários podem não conceder todos os escopos do OAuth que você solicitou. O app precisa processar a negação de escopos desativando a funcionalidade relevante.
Se a funcionalidade básica do app exigir vários escopos, explique isso ao usuário antes de
pedir consentimento.
Você só pode pedir novamente quando o usuário indicar claramente a intenção de usar o
recurso específico que exige o escopo. Seu app precisa fornecer ao usuário contexto e justificativa relevantes antes de solicitar escopos do OAuth.
É preciso minimizar o número de escopos que o app solicita de uma só vez. Em vez disso, use a autorização incremental para solicitar escopos no contexto de recursos e funcionalidades.
Usar navegadores seguros
Na Web, as solicitações de autorização do OAuth 2.0 só podem ser feitas em navegadores da Web completos.
Em outras plataformas, selecione o tipo de cliente OAuth correto e integre o OAuth conforme apropriado para sua plataforma. Não redirecione a solicitação por ambientes de navegação incorporados, incluindo webviews em plataformas móveis, como WebView no Android ou WKWebView no iOS. Em vez disso, use bibliotecas OAuth nativas
ou o Login do Google para sua plataforma.
Criação e configuração manual de clientes OAuth
Para evitar abusos, não é possível criar ou modificar clientes OAuth de maneira programática. Você
precisa usar o Google Developers Console para reconhecer explicitamente os Termos de Serviço, configurar
seu cliente OAuth e se preparar para a verificação do OAuth.
Para fluxos de trabalho automatizados, considere usar
contas de serviço.
Remover clientes OAuth não usados
Audite regularmente seus clientes OAuth 2.0 e exclua proativamente aqueles que não são mais necessários para seu aplicativo ou que se tornaram obsoletos. Deixar clientes não usados configurados representa um risco de segurança em potencial, já que o cliente pode ser usado indevidamente se as credenciais forem comprometidas.
Para reduzir ainda mais os riscos de clientes não utilizados, os clientes OAuth 2.0 inativos por seis
meses são
excluídos automaticamente.
A prática recomendada é não esperar a exclusão automática, mas remover proativamente
clientes não utilizados. Essa prática minimiza a superfície de ataque do aplicativo e garante
uma boa higiene de segurança.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
