Login na conta vinculada

Com a vinculação de Contas do Google, os proprietários de Contas do Google podem se conectar aos seus serviços de forma rápida, fácil e segura e compartilhar dados com o Google.

O login com uma conta vinculada ativa o Login com um toque no Google para usuários que já têm uma Conta do Google vinculada ao seu serviço. Isso melhora a experiência dos usuários, já que eles podem fazer login com um clique, sem digitar o nome de usuário e a senha novamente. Isso também reduz as chances de os usuários criarem contas duplicadas no seu serviço.

Requisitos

Para implementar o login com contas vinculadas, você precisa atender aos seguintes requisitos:

  • Você tem uma implementação de vinculação de OAuth da Conta do Google que é compatível com o fluxo do código de autorização do OAuth 2.0. A implementação do OAuth precisa incluir estes endpoints:
    • endpoint de autorização para processar solicitações de autorização.
    • endpoint do token para processar a solicitação de tokens de acesso e atualização.
    • endpoint userinfo para recuperar informações básicas da conta sobre o usuário vinculado que são exibidas durante o processo de login na conta vinculada.
  • Ter um app Android.

Como funciona

Pré-requisito : o usuário vinculou anteriormente a Conta do Google à conta dele no seu serviço.

  1. Você opta por mostrar as contas vinculadas durante o fluxo de login com um toque.
  2. O usuário vê uma solicitação de login com um toque com uma opção para usar a conta vinculada no serviço.
  3. Se o usuário quiser continuar com a conta vinculada, o Google vai enviar uma solicitação ao endpoint do token para salvar um código de autorização. A solicitação contém o token de acesso do usuário emitido pelo seu serviço e um código de autorização do Google.
  4. Você troca o código de autorização do Google por um token de ID do Google que contém informações sobre a Conta do Google do usuário.
  5. Seu aplicativo também recebe um token de ID quando o fluxo termina, e você o compara com o identificador de usuário no token de ID recebido pelo seu servidor para fazer o login do usuário no seu aplicativo.
Login na conta vinculada.
Figura 1. Fluxo de login da conta vinculada. Se o usuário tiver várias contas conectadas no dispositivo, ele poderá ver um seletor de conta e só será levado para a visualização "Login da conta vinculada" se selecionar uma conta vinculada.

Implementar o login de conta vinculada no seu app Android

Para oferecer compatibilidade com o login de conta vinculada no seu app Android, siga as instruções no guia de implementação do Android.

Processar solicitações de código de autorização do Google

O Google faz uma solicitação POST ao endpoint do token para salvar um código de autorização que você troca pelo token de ID do usuário. A solicitação contém o token de acesso do usuário e um código de autorização OAuth2 emitido pelo Google.

Antes de salvar o código de autorização, verifique se o token de acesso foi concedido por você ao Google, identificado pelo client_id.

Solicitação HTTP

Exemplo de solicitação

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

code=GOOGLE_AUTHORIZATION_CODE
&grant_type=urn:ietf:params:oauth:grant-type:reciprocal
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&access_token=ACCESS_TOKEN

Seu endpoint de troca de token precisa processar os seguintes parâmetros de solicitação:

Parâmetros de endpoint do token
code Obrigatório Código de autorização do Google OAuth2
client_id Obrigatório ID do cliente que você emitiu para o Google
client_secret Obrigatório Chave secreta do cliente emitida para o Google
access_token Token de acesso obrigatório que você emitiu para o Google. Você vai usar isso para ter o contexto do usuário
grant_type O valor obrigatório precisa ser definido como urn:ietf:params:oauth:grant-type:reciprocal

Seu endpoint de troca de token precisa responder à solicitação POST da seguinte maneira:

  • Verifique se o access_token foi concedido ao Google, identificado pelo client_id.
  • Responda com uma resposta HTTP 200 (OK) se a solicitação for válida e o código de autenticação for trocado por um token de ID do Google ou um código de erro HTTP se a solicitação for inválida.

Resposta HTTP

Concluído

Retornar código de status HTTP 200 OK

Exemplo de resposta de êxito
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{}

Erros

No caso de uma solicitação HTTP inválida, responda com um dos seguintes códigos de erro HTTP:

Código de status HTTP Body Descrição
400 {"error": "invalid_request"} A solicitação está sem um parâmetro, portanto, o servidor não pode prosseguir com a solicitação. Isso também poderá ser retornado se a solicitação incluir um parâmetro incompatível ou repetir um parâmetro
401 {"error": "invalid_request"} Falha na autenticação do cliente, por exemplo, se a solicitação contém uma chave secreta ou um ID do cliente inválido
401 {"error": "invalid_token"}

Incluir o desafio de autenticação "WWW-Authentication: Bearer" no cabeçalho de resposta

O token de acesso do parceiro é inválido.
403 {"error": "insufficient_permission"}

Incluir o desafio de autenticação "WWW-Authentication: Bearer" no cabeçalho de resposta

O token de acesso do parceiro não contém os escopos necessários para executar o OAuth recíproco
500 {"error": "internal_error"} Erro no servidor

A resposta de erro deve conter os seguintes campos :

Campos de resposta de erro
error Obrigatório String de erro
error_description Descrição legível do erro.
error_uri URI que mostra mais detalhes sobre o erro
Exemplo de resposta de erro 400
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "error": "invalid_request",
  "error_description": "Request was missing the 'access_token' parameter."
}

Trocar o código de autorização pelo token de ID

Troque o código de autorização que você recebeu por um token de ID do Google com informações sobre a Conta do Google do usuário.

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

Campos de solicitação
client_id Obrigatório O ID do cliente obtido na página Credenciais do Console de APIs. Geralmente, é a credencial com o nome New Actions on Google app.
client_secret Obrigatório A chave secreta do cliente conseguida na página Credenciais do Console de APIs
code Obrigatório O código de autorização enviado na solicitação inicial
grant_type Obrigatório Conforme definido na especificação OAuth 2.0, o valor desse campo precisa ser definido como authorization_code.
Exemplo de solicitação
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=GOOGLE_AUTHORIZATION_CODE
&grant_type=authorization_code
&client_id=GOOGLE_CLIENT_ID
&client_secret=GOOGLE_CLIENT_SECRET

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:

Campos de resposta
access_token Token de acesso emitido pelo Google que seu aplicativo envia para autorizar uma solicitação de API do Google
id_token O token de ID contém as informações da Conta do Google do usuário. A seção "Validar resposta" contém detalhes sobre como decodificar e validar a resposta do token de ID
expires_in A vida útil restante do token de acesso em segundos
refresh_token Um token que pode ser usado para receber um novo token de acesso. Os tokens de atualização são válidos até que o usuário revogue o acesso
scope O valor desse campo é sempre definido como openid para o caso de uso de login da conta vinculada
token_type O tipo de token retornado. No momento, o valor desse campo está sempre definido como Bearer.
Exemplo de resposta
HTTP/1.1 200 OK
Content-type: application/json; charset=utf-8

{
  "access_token": "Google-access-token",
  "id_token": "Google-ID-token",
  "expires_in": 3599,
  "token_type": "Bearer",
  "scope": "openid",
  "refresh_token": "Google-refresh-token"
}


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

code=Google authorization code
&grant_type=authorization_code
&client_id=Google client id
&client_secret=Google client secret

Validar a resposta do token de ID

Valide e decodifique a asserção JWT

Você pode validar e decodificar a declaração JWT usando uma biblioteca de decodificação JWT para o seu idioma . Use as chaves públicas do Google, disponíveis nos formatos JWK ou PEM , para verificar a assinatura do token.

Quando decodificada, a declaração JWT se parece com o seguinte exemplo:

{
  "sub": "1234567890",      // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "email_verified": true,   // true, if Google has verified the email address
  "hd": "example.com",      // If present, the host domain of the user's GSuite email address
                            // If present, a URL to user's profile picture
  "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ",
  "locale": "en_US"         // User's locale, from browser or phone settings
}

Além de verificar a assinatura do token, verifique se o emissor da declaração (campo iss ) é https://accounts.google.com , se o público (campo aud ) é seu ID de cliente atribuído e se o token não expirou ( exp campo).

Usando os campos email , email_verified e hd , você pode determinar se o Google hospeda e se tem autoridade para um endereço de e-mail. Nos casos em que o Google tem autoridade, o usuário é atualmente conhecido como o proprietário legítimo da conta e você pode pular a senha ou outros métodos de desafio. Caso contrário, esses métodos podem ser usados ​​para verificar a conta antes da vinculação.

Casos em que o Google é autoritário:

  • email - email tem um sufixo @gmail.com , esta é uma conta do Gmail.
  • email_verified é true e hd está definido, esta é uma conta do G Suite.

Os usuários podem se registrar em Contas do Google sem usar o Gmail ou o G Suite. Quando o email não contém um sufixo @gmail.com e hd está ausente, o Google não é autoritativo e senha ou outros métodos de desafio são recomendados para verificar o usuário. email_verfied também pode ser verdadeiro, já que o Google verificou inicialmente o usuário quando a conta do Google foi criada; no entanto, a propriedade da conta de e-mail de terceiros pode ter mudado.