Esta página foi traduzida pela API Cloud Translation.

Como usar o OAuth 2.0 para acessar as APIs do Google
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

As APIs do Google usam o protocolo OAuth 2.0 para autenticação e autorização. O Google oferece suporte a cenários comuns do OAuth 2.0, como aqueles para aplicativos de servidor da Web, do lado do cliente, instalados e de dispositivos de entrada limitada.

Para começar, obtenha as credenciais do cliente OAuth 2.0 no Google API Console. Em seguida, o aplicativo cliente solicita um token de acesso do servidor de autorização do Google, extrai um token da resposta e o envia para a API do Google que você quer acessar. Para uma demonstração interativa do uso do OAuth 2.0 com o Google (incluindo a opção de usar suas próprias credenciais de clientes), teste o OAuth 2.0 Playground.

Esta página oferece uma visão geral dos cenários de autorização OAuth 2.0 compatíveis com o Google e fornece links para conteúdo mais detalhado. Para detalhes sobre como usar o OAuth 2.0 para autenticação, consulte OpenID Connect.

Etapas básicas

Todos os aplicativos seguem um padrão básico ao acessar uma API do Google usando o OAuth 2.0. Em um nível alto, você segue cinco etapas:

1. Receba credenciais OAuth 2.0 do Google API Console.

Acesse o Google API Console para receber credenciais do OAuth 2.0, como um ID e uma chave secreta do cliente conhecidos pelo Google e pelo seu aplicativo. O conjunto de valores varia de acordo com o tipo de aplicativo que você está criando. Por exemplo, um aplicativo JavaScript não exige um secret, mas um aplicativo de servidor da Web exige.

É necessário criar um cliente OAuth adequado para a plataforma em que o app será executado, por exemplo:

Para do lado do servidor ou apps da Web em JavaScript, use o tipo de cliente "Web". Não use esse tipo de cliente para nenhum outro aplicativo, como apps nativos ou para dispositivos móveis.
Para apps Android, use o tipo de cliente "Android".
Para apps iOS e macOS, use o tipo de cliente "iOS".
Para apps da Plataforma Universal Windows, use o tipo de cliente "Plataforma Universal Windows".
Para dispositivos de entrada limitados, como TVs ou dispositivos incorporados, use o tipo de cliente "TVs e dispositivos de entrada limitada".
Para interações entre servidores, use contas de serviço.

2. Receba um token de acesso do servidor de autorização do Google.

Antes que seu aplicativo possa acessar dados privados usando uma API do Google, ele precisa receber um token de acesso que conceda acesso a essa API. Um único token de acesso pode conceder diferentes níveis de acesso a várias APIs. Um parâmetro variável chamado scope controla o conjunto de recursos e operações que um token de acesso permite. Durante a solicitação de token de acesso, seu app envia um ou mais valores no parâmetro scope.

Há várias maneiras de fazer essa solicitação, e elas variam de acordo com o tipo de aplicativo que você está criando. Por exemplo, um aplicativo JavaScript pode solicitar um token de acesso usando um redirecionamento do navegador para o Google, enquanto um aplicativo instalado em um dispositivo que não tem navegador usa solicitações de serviço da Web.

Algumas solicitações exigem uma etapa de autenticação em que o usuário faz login com a Conta do Google. Depois de fazer login, o usuário é questionado se ele quer conceder uma ou mais permissões que seu app está solicitando. Esse processo é chamado de consentimento do usuário.

Se o usuário conceder pelo menos uma permissão, o servidor de autorização do Google vai enviar ao seu aplicativo um token de acesso (ou um código de autorização que o aplicativo pode usar para receber um token de acesso) e uma lista de escopos de acesso concedidos por esse token. Se o usuário não conceder a permissão, o servidor retornará um erro.

Geralmente, é recomendável solicitar escopos de forma incremental, no momento em que o acesso é necessário, em vez de fazer isso de antemão. Por exemplo, um app que quer oferecer suporte para salvar um evento em uma agenda não deve solicitar acesso ao Google Agenda até que o usuário pressione o botão "Adicionar à agenda". Consulte Autorização incremental.

3. Examine os escopos de acesso concedidos pelo usuário.

Compare os escopos incluídos na resposta do token de acesso com os escopos necessários para acessar recursos e funcionalidades do seu aplicativo que dependem do acesso a uma API do Google relacionada. Desative os recursos do app que não funcionam sem acesso à API relacionada.

O escopo incluído na solicitação pode não corresponder ao escopo incluído na resposta, mesmo que o usuário tenha concedido todos os escopos solicitados. Consulte a documentação de cada API do Google para ver os escopos necessários para o acesso. Uma API pode mapear vários valores de string de escopo para um único escopo de acesso, retornando a mesma string de escopo para todos os valores permitidos na solicitação. Exemplo: a API Google People pode retornar um escopo de https://www.googleapis.com/auth/contacts quando um app solicita que um usuário autorize um escopo de https://www.google.com/m8/feeds/. O método people.updateContact da API Google People requer um escopo concedido de https://www.googleapis.com/auth/contacts.

4. Enviar o token de acesso para uma API.

Depois que um aplicativo recebe um token de acesso, ele o envia para uma API do Google em um cabeçalho de solicitação de autorização HTTP. É possível enviar tokens como parâmetros de string de consulta do URI, mas não recomendamos, porque os parâmetros do URI podem acabar em arquivos de registro que não são totalmente seguros. Além disso, é uma boa prática do REST evitar a criação de nomes de parâmetros de URI desnecessários.

Os tokens de acesso são válidos apenas para o conjunto de operações e recursos descritos no scope da solicitação de token. Por exemplo, se um token de acesso for emitido para a API Google Agenda, ele não vai conceder acesso à API Google Contatos. No entanto, é possível enviar esse token de acesso para a API Google Agenda várias vezes para operações semelhantes.

5. Atualize o token de acesso, se necessário.

Os tokens de acesso têm duração limitada. Se o aplicativo precisar de acesso a uma API do Google além da validade de um único token de acesso, ele poderá receber um token de atualização. Um token de atualização permite que seu aplicativo receba novos tokens de acesso.

Cenários

Aplicativos do servidor da Web

O endpoint do Google OAuth 2.0 oferece suporte a aplicativos de servidor da Web que usam linguagens e frameworks como PHP, Java, Go, Python, Ruby e ASP.NET.

A sequência de autorização começa quando seu aplicativo redireciona um navegador para um URL do Google. Esse URL inclui parâmetros de consulta que indicam o tipo de acesso solicitado. O Google lida com a autenticação do usuário, a seleção de sessão e o consentimento do usuário. O resultado é um código de autorização, que o aplicativo pode trocar por um token de acesso e um token de atualização.

O aplicativo precisa armazenar o token de atualização para uso futuro e usar o token de acesso para acessar uma API do Google. Quando o token de acesso expirar, o aplicativo vai usar o token de atualização para receber um novo.

O aplicativo envia uma solicitação de token para o servidor de autorização do Google,
recebe um código de autorização, troca o código por um token e usa o token
para chamar um endpoint da API do Google.

Para mais detalhes, consulte Usar o OAuth 2.0 para aplicativos de servidor da Web.

Aplicativos instalados

O endpoint do Google OAuth 2.0 oferece suporte a aplicativos instalados em dispositivos como computadores, dispositivos móveis e tablets. Ao criar um ID de cliente pelo Google API Console, especifique que ele é um aplicativo instalado e selecione Android, app do Chrome, iOS, plataforma universal do Windows (UWP) ou app para computador como o tipo de aplicativo.

O processo resulta em um ID do cliente e, em alguns casos, em uma chave secreta do cliente, que você incorpora no código-fonte do seu aplicativo. Nesse contexto, a chave secreta do cliente obviamente não é tratada como uma chave secreta.

Para mais detalhes, consulte Como usar o OAuth 2.0 para aplicativos instalados.

Aplicativos do lado do cliente (JavaScript)

O endpoint do Google OAuth 2.0 oferece suporte a aplicativos JavaScript executados em um navegador.

O resultado é um token de acesso, que o cliente precisa validar antes de incluí-lo em uma solicitação da API do Google. Quando o token expirar, o aplicativo vai repetir o processo.

O aplicativo em JS envia uma solicitação de token para o servidor de autorização do Google,
recebe um token, o valida e o usa para chamar um endpoint da API
do Google.

Para mais detalhes, consulte Usar o OAuth 2.0 para aplicativos do lado do cliente.

Aplicativos em dispositivos de entrada limitada

O endpoint do Google OAuth 2.0 oferece suporte a aplicativos executados em dispositivos de entrada limitada, como consoles de jogos, câmeras de vídeo e impressoras.

A sequência de autorização começa com o aplicativo fazendo uma solicitação de serviço da Web para um URL do Google para um código de autorização. A resposta contém vários parâmetros, incluindo um URL e um código que o aplicativo mostra ao usuário.

O usuário recebe o URL e o código do dispositivo e depois alterna para um dispositivo ou computador separado com recursos de entrada mais avançados. O usuário abre um navegador, navega até o URL especificado, faz login e insere o código.

Enquanto isso, o aplicativo pesquisa um URL do Google em um intervalo especificado. Depois que o usuário aprova o acesso, a resposta do servidor do Google contém um token de acesso e um token de atualização. O aplicativo precisa armazenar o token de atualização para uso futuro e usar o token de acesso para acessar uma API do Google. Quando o token de acesso expirar, o aplicativo vai usar o token de atualização para receber um novo.

O usuário faz login em um dispositivo separado que tem um navegador

Para mais detalhes, consulte Como usar o OAuth 2.0 para dispositivos.

Contas de serviço

APIs do Google, como a Prediction API e o Google Cloud Storage, podem agir em nome do seu aplicativo sem acessar as informações do usuário. Nessas situações, seu app precisa provar a própria identidade para a API, mas não é necessário o consentimento do usuário. Da mesma forma, em cenários corporativos, seu aplicativo pode solicitar acesso delegado a alguns recursos.

Para esses tipos de interações entre servidores, você precisa de uma conta de serviço, que é uma conta que pertence ao seu aplicativo em vez de um usuário final individual. O aplicativo chama as APIs do Google em nome da conta de serviço, e o consentimento do usuário não é necessário. Em cenários que não são de conta de serviço, o aplicativo chama as APIs do Google em nome dos usuários finais, e o consentimento do usuário às vezes é necessário.

As credenciais de uma conta de serviço, que você recebe do Google API Console, incluem um endereço de e-mail gerado que é exclusivo, um ID do cliente e pelo menos um par de chaves públicas/privadas. Você usa o ID do cliente e uma chave privada para criar um JWT assinado e criar uma solicitação de token de acesso no formato apropriado. Em seguida, o aplicativo envia a solicitação de token para o servidor de autorização do Google OAuth 2.0, que retorna um token de acesso. O aplicativo usa o token para acessar uma API do Google. Quando o token expirar, o aplicativo repete o processo.

O aplicativo do servidor usa um JWT para solicitar um token do servidor de autorização do Google e, em seguida, usa o token para chamar um endpoint da API do Google. Nenhum
usuário final está envolvido.

Para mais detalhes, consulte a documentação da conta de serviço.

Tamanho do token

O tamanho dos tokens pode variar até os seguintes limites:

Códigos de autorização: 256 bytes
Tokens de acesso: 2.048 bytes
Tokens de atualização: 512 bytes

Os tokens de acesso retornados pela API Security Token Service do Google Cloud são estruturados de maneira semelhante aos tokens de acesso OAuth 2.0 da API do Google, mas têm limites de tamanho diferentes. Para mais detalhes, consulte a documentação da API.

O Google se reserva o direito de mudar o tamanho do token dentro desses limites, e seu aplicativo precisa oferecer suporte a tamanhos de token variáveis.

Atualizar a validade do token

Você precisa escrever seu código para antecipar a possibilidade de que um token de atualização concedido não funcione mais. Um token de atualização pode parar de funcionar por um destes motivos:

O usuário revogou o acesso do app.
O token de atualização não foi usado há seis meses.
O usuário mudou as senhas, e o token de atualização contém escopos do Gmail.
A conta do usuário excedeu o número máximo de tokens de atualização concedidos (ativos).
O usuário concedeu acesso baseado em tempo ao app, e o acesso expirou.
Se um administrador definir qualquer um dos serviços solicitados nos escopos do app como "Restrito" (o erro é admin_policy_enforced).
Para as APIs do Google Cloud Platform, a duração da sessão definida pelo administrador pode ter sido excedida.

Um projeto do Google Cloud Platform com uma tela de consentimento do OAuth configurada para um tipo de usuário externo e um status de publicação "Em teste" recebe um token de atualização que expira em 7 dias, a menos que os únicos escopos do OAuth solicitados sejam um subconjunto de nome, endereço de e-mail e perfil do usuário (através dos escopos userinfo.email, userinfo.profile, openid ou os equivalentes do OpenID Connect).

Atualmente, há um limite de 100 tokens de atualização por Conta do Google e ID do cliente do OAuth 2.0. Se o limite for atingido, a criação de um novo token de atualização vai invalidar automaticamente o token de atualização mais antigo sem aviso prévio. Esse limite não se aplica a contas de serviço.

Há também um limite maior no número total de tokens de atualização que uma conta de usuário ou conta de serviço pode ter em todos os clientes. A maioria dos usuários normais não vai exceder esse limite, mas uma conta de desenvolvedor usada para testar uma implementação pode.

Se você precisar autorizar vários programas, máquinas ou dispositivos, uma solução alternativa é limitar o número de clientes autorizados por Conta do Google a 15 ou 20. Se você for um administrador do Google Workspace, poderá criar outros usuários com privilégios administrativos e usá-los para autorizar alguns dos clientes.

Como lidar com políticas de controle de sessão para organizações do Google Cloud Platform (GCP)

Os administradores de organizações do GCP podem exigir a reautenticação frequente dos usuários enquanto eles acessam recursos do GCP usando o recurso de controle de sessão do Google Cloud. Essa política afeta o acesso ao Console do Google Cloud, ao SDK do Google Cloud (também conhecido como a CLI gcloud) e a qualquer aplicativo OAuth de terceiros que exija o escopo do Cloud Platform. Se um usuário tiver uma política de controle de sessão em vigor, no vencimento da duração da sessão, suas chamadas de API vão gerar um erro semelhante ao que aconteceria se o token de atualização fosse revogado. A chamada vai falhar com um tipo de erro invalid_grant. O campo error_subtype pode ser usado para distinguir entre um token revogado e uma falha devido a uma política de controle de sessão (por exemplo, "error_subtype": "invalid_rapt"). Como as durações de sessão podem ser muito limitadas (entre 1 hora e 24 horas), esse cenário precisa ser tratado corretamente, reiniciando uma sessão de autenticação.

Da mesma forma, não use nem incentive o uso de credenciais de usuário para implantação entre servidores. Se as credenciais do usuário forem implantadas em um servidor para trabalhos ou operações de longa duração e um cliente aplicar políticas de controle de sessão a esses usuários, o aplicativo do servidor vai falhar, porque não será possível reautenticar o usuário quando a duração da sessão expirar.

Para mais informações sobre como ajudar seus clientes a implantar esse recurso, consulte este artigo de ajuda voltado a administradores.

Bibliotecas de cliente

As bibliotecas de cliente a seguir são integradas a frameworks conhecidos, o que simplifica a implementação do OAuth 2.0. Mais recursos serão adicionados às bibliotecas com o tempo.