OAuth 2.0 para apps para dispositivos móveis e de computador

Este documento explica como os aplicativos instalados em dispositivos como smartphones, tablets e computadores usam endpoints OAuth 2.0 do Google para autorizar o acesso às APIs do Google.

O OAuth 2.0 permite que os usuários compartilhem dados específicos com um aplicativo, mantendo a privacidade de nomes de usuário, senhas e outras informações. Por exemplo, um aplicativo pode usar o OAuth 2.0 para conseguir permissão dos usuários para armazenar arquivos no Google Drive deles.

Os apps instalados são distribuídos para dispositivos individuais, e presume-se que esses apps não possam manter secrets. Eles podem acessar as APIs do Google enquanto o usuário está no app ou quando o app está sendo executado em segundo plano.

Esse fluxo de autorização é semelhante ao usado para aplicativos de servidor da Web. A principal diferença é que os apps instalados precisam abrir o navegador do sistema e fornecer um URI de redirecionamento local para processar as respostas do servidor de autorização do Google.

Alternativas

No caso de apps para dispositivos móveis, use o Login do Google no Android ou no iOS. As bibliotecas de cliente do Login do Google lidam com a autenticação e a autorização do usuário e podem ser mais simples de implementar do que o protocolo de nível inferior descrito aqui.

Para apps executados em dispositivos sem suporte a um navegador do sistema ou com recursos de entrada limitados, como TVs, consoles de jogos, câmeras ou impressoras, consulte OAuth 2.0 para TVs e dispositivos ou Login em TVs e dispositivos de entrada limitados.

Bibliotecas e amostras

Recomendamos as seguintes bibliotecas e amostras para ajudar você a implementar o fluxo do OAuth 2.0 descrito neste documento:

• Biblioteca AppAuth para Android
• Biblioteca AppAuth para iOS
• OAuth para apps: exemplos do Windows

Pré-requisitos

Ativar as APIs do projeto

Qualquer aplicativo que chame APIs do Google precisa ativá-las no API Console.

Para ativar uma API para um projeto, faça o seguinte:

1. Open the API Library no arquivo Google API Console.
2. If prompted, select a project, or create a new one.
3. API Library lista todas as APIs disponíveis agrupadas por família de produtos e popularidade. Se a API que você quer ativar não estiver visível na lista, use a pesquisa para encontrá-la ou clique em Ver tudo na família de produtos a que ela pertence.
4. Selecione aquela que você quer habilitar e clique no botão Ativar.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

Criar credenciais de autorização

Qualquer aplicativo que use o OAuth 2.0 para acessar as APIs do Google precisa ter credenciais de autorização que identifiquem o aplicativo para o servidor OAuth 2.0 do Google. As etapas a seguir explicam como criar credenciais para seu projeto. Os aplicativos podem usar as credenciais para acessar as APIs ativadas para esse projeto.

1. Go to the Credentials page.
2. Clique em Criar credenciais > ID do cliente OAuth.
3. As seções abaixo descrevem os tipos de cliente e os métodos de redirecionamento compatíveis com o servidor de autorização do Google. Escolha o tipo de cliente recomendado para seu aplicativo, nomeie o cliente OAuth e defina os outros campos do formulário conforme apropriado.

Identificar escopos de acesso

Os escopos permitem que seu aplicativo solicite acesso apenas aos recursos necessários e, ao mesmo tempo, permitem que os usuários controlem o nível de acesso que concedem ao aplicativo. Assim, pode haver uma relação inversa entre o número de escopos solicitados e a probabilidade de obter o consentimento do usuário.

Antes de começar a implementar a autorização do OAuth 2.0, recomendamos que você identifique os escopos que seu app vai precisar de permissão de acesso.

O documento Escopos da API OAuth 2.0 contém uma lista completa dos escopos que podem ser usados para acessar as APIs do Google.

Como conseguir tokens de acesso do OAuth 2.0

As etapas a seguir mostram como seu aplicativo interage com o servidor OAuth 2.0 do Google para conseguir o consentimento de um usuário para executar uma solicitação de API em nome dele. Seu aplicativo precisa ter esse consentimento antes de executar uma solicitação de API do Google que requer a autorização do usuário.

Etapa 1: gerar um desafio e um verificador de código

O Google oferece suporte ao protocolo Chave de prova para troca de código (PKCE, na sigla em inglês) para tornar o fluxo de apps instalados mais seguro. Um verificador de código exclusivo é criado para cada solicitação de autorização, e o valor transformado, chamado "code_challenge", é enviado ao servidor de autorização para receber o código.

Criar o verificador de código

Um code_verifier é uma string aleatória criptográfica de alta entropia que usa os caracteres não reservados [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", com comprimento mínimo de 43 e máximo de 128 caracteres.

O verificador de código precisa ter entropia suficiente para não ser possível adivinhar o valor.

Criar o desafio do código

Há suporte para dois métodos de criação do desafio de código.

code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

code_challenge = code_verifier

Etapa 2: enviar uma solicitação ao servidor OAuth 2.0 do Google

Para receber a autorização do usuário, envie uma solicitação ao servidor de autorização do Google em https://accounts.google.com/o/oauth2/v2/auth. Esse endpoint processa a pesquisa de sessão ativa, autentica o usuário e recebe o consentimento dele. O endpoint só pode ser acessado por SSL e recusa conexões HTTP (não SSL).

O servidor de autorização aceita os seguintes parâmetros de string de consulta para aplicativos instalados:

Exemplos de URLs de autorização

As guias abaixo mostram exemplos de URLs de autorização para as diferentes opções de URI de redirecionamento.

Os URLs são idênticos, exceto pelo valor do parâmetro redirect_uri. Os URLs também contêm os parâmetros obrigatórios response_type e client_id, bem como o parâmetro opcional state. Cada URL tem quebras de linha e espaços para facilitar a leitura.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

Etapa 3: o Google solicita o consentimento do usuário

Nesta etapa, o usuário decide se quer conceder o acesso solicitado ao seu aplicativo. Nesse estágio, o Google exibe uma janela de consentimento que mostra o nome do aplicativo e os serviços da API do Google que estão solicitando permissão de acesso com as credenciais de autorização do usuário e um resumo dos escopos de acesso a serem concedidos. Assim, o usuário poderá conceder acesso a um ou mais escopos solicitados pelo seu aplicativo ou recusar a solicitação.

Seu aplicativo não precisa fazer nada nesta etapa, já que aguarda a resposta do servidor OAuth 2.0 do Google indicando se o acesso foi concedido. Essa resposta é explicada na etapa a seguir.

Etapa 4: lidar com a resposta do servidor OAuth 2.0

A maneira como seu aplicativo recebe a resposta de autorização depende do esquema do URI de redirecionamento que ele usa. Seja qual for o esquema, a resposta conterá um código de autorização (code) ou um erro (error). Por exemplo, error=access_denied indica que o usuário recusou a solicitação.

Se o usuário conceder acesso ao seu aplicativo, troque o código de autorização por um token de acesso e um token de atualização, conforme descrito na próxima etapa.

Etapa 5: trocar o código de autorização para tokens de atualização e acesso

Para trocar um código de autorização por um token de acesso, chame o endpoint https://oauth2.googleapis.com/token e defina os seguintes parâmetros:

O snippet a seguir mostra um exemplo de solicitação:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

O Google responde a essa solicitação retornando um objeto JSON que contém um token de acesso de curta duração e um token de atualização.

A resposta contém os seguintes campos:

O snippet a seguir mostra um exemplo de resposta:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Chamada de APIs do Google

Depois que o aplicativo recebe um token de acesso, é possível usá-lo para fazer chamadas para uma API do Google em nome de uma determinada conta de usuário, se o escopo de acesso exigido pela API tiver sido concedido. Para fazer isso, inclua o token de acesso em uma solicitação para a API incluindo um parâmetro de consulta access_token ou um valor Bearer de cabeçalho HTTP Authorization. Sempre que possível, recomendamos usar o cabeçalho HTTP, porque as strings de consulta tendem a ficar visíveis nos registros do servidor. Na maioria dos casos, você pode usar uma biblioteca de cliente para configurar suas chamadas para APIs do Google (por exemplo, ao chamar a API Drive Files).

É possível testar todas as APIs do Google e ver os escopos delas no OAuth 2.0 Playground.

Exemplos de HTTP GET

Uma chamada para o endpoint drive.files (API Drive Files) usando o cabeçalho HTTP Authorization: Bearer pode ter a seguinte aparência. Observe que é necessário especificar seu próprio token de acesso:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Veja a seguir uma chamada para a mesma API feita pelo usuário autenticado usando o parâmetro de string de consulta access_token:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

Exemplos de curl

Teste esses comandos com o aplicativo de linha de comando curl. Veja um exemplo que usa a opção de cabeçalho HTTP (preferencial):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Ou, como alternativa, a opção de parâmetro da string de consulta:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Atualização do token de acesso

Os tokens de acesso expiram periodicamente e se tornam credenciais inválidas para uma solicitação de API relacionada. É possível atualizar um token de acesso sem solicitar a permissão do usuário (inclusive quando ele não está presente) caso tenha solicitado acesso off-line aos escopos associados ao token.

Para atualizar um token de acesso, seu aplicativo envia uma solicitação POST HTTPS ao servidor de autorização do Google (https://oauth2.googleapis.com/token) que inclui os seguintes parâmetros:

O snippet a seguir mostra um exemplo de solicitação:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Se o usuário não tiver revogado o acesso concedido ao aplicativo, o servidor de token retornará um objeto JSON com um novo token de acesso. O snippet a seguir mostra um exemplo de resposta:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Há limites para o número de tokens de atualização que serão emitidos: um limite por combinação cliente/usuário e outro por usuário em todos os clientes. Salve os tokens de atualização em um armazenamento de longo prazo e continue a usá-los enquanto permanecerem válidos. Se o aplicativo solicita muitos tokens de atualização, ele pode atingir esses limites. Nesse caso, os tokens de atualização mais antigos deixarão de funcionar.

Revogar um token

Em alguns casos, o usuário pode querer revogar o acesso dado a um aplicativo. Um usuário pode revogar o acesso acessando Configurações da conta. Para mais informações, consulte a seção Remover o acesso ao site ou app do documento de suporte de sites e apps de terceiros com acesso à sua conta.

Também é possível que um aplicativo revogue programaticamente o acesso concedido a ele. A revogação programática é importante nos casos em que um usuário cancela a inscrição, remove um aplicativo ou os recursos da API exigidos por um app são alterados de maneira significativa. Em outras palavras, parte do processo de remoção pode incluir uma solicitação de API para garantir que as permissões concedidas anteriormente ao app sejam removidas.

Para revogar um token de forma programática, o aplicativo faz uma solicitação a https://oauth2.googleapis.com/revoke e o inclui como um parâmetro:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

O token pode ser de acesso ou de atualização. Se for um token de acesso e tiver um token de atualização correspondente, ele também será revogado.

Se a revogação for processada com êxito, o código de status HTTP da resposta será 200. Para condições de erro, um código de status HTTP 400 é retornado com um código de erro.

Leitura complementar

A prática recomendada atual do IETF, o OAuth 2.0 para apps nativos, estabelece muitas das práticas recomendadas documentadas aqui.