Com a vinculação da Conta do Google, os proprietários de contas podem se conectar aos seus serviços de maneira rápida, fácil e segura e compartilhar dados com o Google.
O login na conta vinculada ativa o Login com um toque com o 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. Isso também reduz as chances de os usuários criarem contas duplicadas no seu serviço.
Requisitos
Para implementar o login com conta vinculada, você precisa atender aos seguintes requisitos:
- Você tem uma implementação de vinculação OAuth da Conta do Google compatível com o fluxo do código de autorização do OAuth 2.0. Sua implementação do OAuth precisa incluir os seguintes 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 do usuário vinculado que são mostradas a ele durante o processo de login na conta vinculada.
- Você tem um app Android.
Como funciona
Pré-requisito : o usuário já vinculou a Conta do Google à conta dele no seu serviço.
- Você aceita mostrar as contas vinculadas durante o fluxo de login com um toque.
- O usuário recebe uma solicitação de login com um toque com uma opção para acessar seu serviço com a conta vinculada.
- Se o usuário optar por continuar com a conta vinculada, o Google 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.
- 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.
- Seu aplicativo também recebe um token de ID quando o fluxo termina, e você o combina com o identificador de usuário no token de ID recebido pelo seu servidor para fazer o login do usuário no seu aplicativo.
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 |
Obrigatório Token de acesso que você emitiu para o Google. Use isso para entender 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 fazendo o seguinte:
- Verifique se o
access_token
foi concedido ao Google, identificado peloclient_id
. - Responda com uma resposta HTTP 200 (OK) se a solicitação for válida e o código de autenticação for trocado com sucesso 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 sucesso
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{}
Erros
Caso uma solicitação HTTP inválida, responda com um dos seguintes códigos de erro HTTP:
Código de status HTTP | Texto | Descrição |
---|---|---|
400 | {"error": "invalid_request"} |
A solicitação está sem um parâmetro, então o servidor não pode prosseguir com ela. 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 contiver um ID do cliente ou uma chave secreta inválida |
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 realizar 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 |
String de erro Obrigatório |
error_description |
Descrição legível do erro. |
error_uri |
URI que fornece 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 código de autorização pelo token de ID
Você precisará trocar o código de autorização que 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 obtida 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 |
Ciclo de vida 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 na 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 ehd
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.