Esta página aborda algumas práticas recomendadas gerais para a integração com o OAuth 2.0. Considere estas práticas recomendadas, além de orientações específicas para seu tipo de aplicativo e plataforma de desenvolvimento. Consulte também as recomendações para preparar seu app para produção e as políticas do OAuth 2.0 do Google.
Gerenciar credenciais de cliente com segurança
As credenciais do cliente OAuth identificam a identidade do seu app e precisam ser gerenciadas com cuidado. Armazene essas credenciais apenas em um armazenamento seguro, por exemplo, usando um gerenciador de secrets, como o Secret Manager do Google Cloud. Não codifique as credenciais, faça commit delas em um repositório de código ou as publique publicamente.
Gerenciar 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 com segurança em repouso e nunca os transmita em texto simples. Use um sistema de armazenamento seguro adequado para sua plataforma, como Keystore no Android, Serviços de conjunto de chaves 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 também estas práticas recomendadas para sua plataforma:
- Para aplicativos do lado do servidor que armazenam tokens para muitos usuários, criptografe-os em repouso e garanta que o repositório de dados não seja acessível publicamente à Internet.
- Para apps de computador, é altamente recomendável usar o protocolo de chave de prova para troca de código (PKCE, na sigla em inglês) para receber códigos de autorização que podem ser trocados por tokens de acesso.
Tokens de restrição do remetente com DPoP
Para proteger seu aplicativo contra roubo de tokens e ataques de repetição, considere restringir os tokens do remetente usando o DPoP (Demonstrating Proof-of-Possession). Embora os tokens de portador padrão possam ser usados por qualquer parte que os intercepte, os tokens DPoP são criptograficamente vinculados a um par de chaves exclusivo gerado e mantido pelo cliente.
Ao usar o DPoP, o cliente apresenta uma prova (um JSON Web Token assinado) ao endpoint do token ao solicitar ou atualizar tokens. Essa prova demonstra que o cliente está de posse da chave privada que corresponde à chave pública vinculada ao token. Se um token de atualização vinculado ao DPoP vazar, ele não poderá ser reproduzido por um invasor sem essa chave privada.
O DPoP funciona com o PKCE para oferecer proteção abrangente:
- O PKCE protege o código de autorização durante o fluxo de redirecionamento inicial.
- O DPoP protege o token de atualização de longa duração, impedindo ataques de repetição se ele for comprometido.
É altamente recomendável adotar o DPoP se o aplicativo:
- Funciona como um cliente público (como um aplicativo de página única ou app instalado) em que os tokens de atualização podem ser mais suscetíveis à exfiltração.
- Acessar dados altamente sensíveis ou APIs de alto valor, em que o impacto do vazamento de tokens é significativo.
- Precisar atender a padrões rigorosos de compliance ou segurança que exigem tokens restritos ao remetente.
Para instruções detalhadas sobre como criar provas de DPoP e solicitar tokens vinculados ao DPoP, consulte a documentação do DPoP.
Usar o parâmetro de estado
Antes de processar uma resposta do OAuth 2.0, confirme se o state recebido do
Google corresponde ao state enviado na solicitação de autorização. O parâmetro
state precisa ser um valor exclusivo e não adivinhável gerado pelo
aplicativo.
O uso do parâmetro state ajuda a garantir que o usuário, e não um script malicioso, esteja fazendo a solicitação e reduz o risco de ataques de falsificação de solicitações entre sites
(CSRF, na sigla em inglês).
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 de revogação de token, faça a integração com o serviço de proteção entre contas.
Usar a autorização incremental
Use a autorização incremental para solicitar os escopos do OAuth adequados quando a funcionalidade for necessária para o seu aplicativo.
Não solicite acesso a dados quando o usuário fizer a autenticação 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 no contexto para ajudar os usuários a entender por que o app está solicitando acesso e como os dados serão usados.
Por exemplo, seu aplicativo pode seguir este modelo:
- O usuário faz a autenticação com o 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
- O 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 para vários escopos.
- Se o usuário negar a solicitação, o app vai desativar o recurso e fornecer mais contexto para que o usuário solicite acesso novamente.
Processar a permissão para vários escopos
Ao solicitar vários escopos de uma vez, os usuários podem não conceder todos os escopos do OAuth solicitados. 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 solicitar a permissão.
Só é possível solicitar ao usuário novamente quando ele indicar claramente a intenção de usar o recurso específico que exige o escopo. O app precisa fornecer ao usuário contexto relevante e justificativa antes de solicitar escopos do OAuth.
É preciso minimizar o número de escopos que o app solicita de uma 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 com todos os recursos. Em outras plataformas, selecione o tipo de cliente OAuth correto e integre 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 biblipostas OAuth recomendadas ou o Login do Google para sua plataforma.
Criação e configuração manual de clientes OAuth
Para evitar abusos, os clientes OAuth não podem ser criados ou modificados de maneira programática. É necessário usar o console do Google Cloud para reconhecer explicitamente os Termos de Serviço, configurar o cliente OAuth e se preparar para a verificação do OAuth.
Para fluxos de trabalho automatizados, considere usar contas de serviço em vez disso.
Remover clientes OAuth não utilizados
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 utilizados configurados representa um risco de segurança potencial, já que o cliente pode ser usado indevidamente se as credenciais do cliente forem comprometidas.
Para reduzir ainda mais os riscos de clientes não utilizados, os clientes OAuth 2.0 que estiverem inativos por seis meses serã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 boa higiene de segurança.