Práticas recomendadas

Processar credenciais de cliente com segurança

As credenciais do cliente OAuth identificam 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 Secret Manager do Google Cloud. Não fixe as credenciais no código, não as envie para um repositório de código nem as publique publicamente.

Processar tokens de usuário com segurança

Os tokens de usuário incluem os tokens de atualização e os tokens 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 o Keystore no Android, os serviços de conjunto de chaves no iOS e no macOS ou o 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 seu armazenamento de dados não seja acessível publicamente pela Internet.
• Para apps para computador, é altamente recomendável usar o protocolo Proof Key for Code Exchange (PKCE) para receber códigos de autorização que podem ser trocados por tokens de acesso.

Tokens de restrição de remetente com DPoP

Para proteger seu aplicativo contra roubo de tokens e ataques de repetição, considere restringir o remetente dos tokens usando DPoP (Demonstrating Proof-of-Possession). Enquanto os tokens do portador padrão podem ser usados por qualquer parte que os intercepte, os tokens DPoP são vinculados criptograficamente 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 de token ao solicitar ou atualizar tokens de atualização. 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 for vazado, ele não poderá ser reproduzido por um invasor sem essa chave privada.

O DPoP funciona com o PKCE para oferecer uma proteção abrangente:

• A PKCE protege o código de autorização durante o fluxo de redirecionamento inicial.
• A DPoP protege o token de atualização de longa duração, evitando ataques de repetição se ele for comprometido.

Recomendamos adotar o DPoP se o aplicativo:

• Opera como um aplicativo instalado ou para computador (ou um aplicativo de página única pareado com um servidor de back-end para front-end) em que os tokens de atualização podem ser mais suscetíveis à exfiltração.
• Acessa dados altamente sensíveis ou APIs de alto valor, em que o impacto do vazamento de tokens é significativo.
• Precisa 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 a DPoP, consulte o Guia de adoção de 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 sobre a revogação de tokens, faça a integração com o serviço de 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 o aplicativo.

Não solicite acesso aos 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á solicitando acesso e como os dados serão usados.

Por exemplo, seu aplicativo pode seguir este modelo:

1. O usuário se autentica no app
   1. Nenhum escopo adicional é solicitado. O app oferece uma funcionalidade básica para que o usuário explore e use recursos que não exigem mais dados ou acesso.
2. O usuário seleciona um recurso que requer acesso a mais dados.
   1. Seu aplicativo faz uma solicitação de autorização para esse escopo específico do OAuth, que é necessário para esse recurso. Se esse recurso exigir vários escopos, siga as práticas recomendadas para vários escopos.
   2. Se o usuário negar a solicitação, o app vai desativar o recurso e fornecer mais contexto para que ele peça acesso novamente.

Processar o consentimento para vários escopos

Ao solicitar vários escopos de uma só vez, os usuários podem não conceder todos os escopos do OAuth que você pediu. Seu app precisa lidar com 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 o consentimento.

Você só poderá solicitar novamente quando o usuário indicar claramente que pretende usar o recurso específico que requer o escopo. Seu app precisa fornecer ao usuário contexto e justificativa relevantes antes de solicitar escopos do OAuth.

Minimize 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 com todos os recursos. 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 as bibliotecas OAuth ou o Login do Google recomendados 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 forma programática. É necessário usar o console do Google Cloud para aceitar explicitamente os Termos de Serviço, configurar seu cliente OAuth e se preparar para a verificação OAuth.

Para fluxos de trabalho automatizados, use contas de serviço.

Remover clientes OAuth não utilizados

Faça auditorias regulares nos clientes OAuth 2.0 e exclua proativamente aqueles que não são mais necessários para o aplicativo ou que se tornaram obsoletos. Deixar clientes não utilizados configurados representa um risco de segurança em potencial, já que o cliente pode ser usado de maneira indevida se as credenciais dele forem comprometidas.

Para reduzir ainda mais os riscos de clientes não utilizados, os clientes do OAuth 2.0 que estiverem inativos por seis meses serão excluídos automaticamente.

A prática recomendada é não esperar pela exclusão automática, mas remover proativamente os clientes não utilizados. Essa prática minimiza a superfície de ataque do aplicativo e garante uma boa higiene de segurança.