A vinculação de Conta do Google permite que os proprietários de contas se conectem aos seus serviços e compartilhem dados com o Google de maneira rápida, fácil e segura.
Com esse recurso, os usuários que já têm a Conta do Google vinculada ao seu serviço podem usar o Fazer login com um toque com o Google. Isso melhora a experiência dos usuários, já que eles podem fazer login com um clique, sem precisar inserir novamente o nome de usuário e a senha. Isso também reduz as chances de os usuários criarem contas duplicadas no serviço.
Requisitos
Para implementar o login de 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. A implementação do OAuth precisa incluir estes endpoints:
- endpoint de autorização para lidar com solicitações de autorização.
- token endpoint para lidar com solicitações de acesso e tokens de atualização.
- userinfo endpoint para recuperar informações básicas da conta sobre o usuário vinculado, que são exibidas para o usuário durante o processo de login da conta vinculada.
- Você tem um app Android.
Como funciona
Pré-requisito : o usuário vinculou anteriormente a Conta do Google à conta no serviço.
- Você ativa a exibição das 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 fazer login no 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 com 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 compara ao identificador de usuário no token de ID que foi recebido pelo seu servidor para fazer o login do usuário em seu aplicativo.
Implementar o login de conta vinculada no app Android
Para oferecer suporte ao recurso "Login de conta vinculada" no seu app Android, siga as instruções do guia de implementação para Android.
Processar solicitações de código de autorização do Google
O Google faz uma solicitação POST ao seu endpoint de 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 por 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 ser capaz de lidar com os seguintes parâmetros de solicitação:
Parâmetros de endpoint de token | |
---|---|
code |
Obrigatório Código de autorização do Google OAuth2 |
client_id |
ID do cliente obrigatório que você emitiu para o Google |
client_secret |
Chave secreta do cliente obrigatória que você emitiu para o Google |
access_token |
Obrigatório Token de acesso que você emitiu para o Google. Você usará isso para obter o contexto do usuário |
grant_type |
Obrigatório O valor PRECISA ser definido como urn:ietf:params:oauth:grant-type:reciprocal . |
Seu endpoint de troca de token deve responder à solicitação POST fazendo o seguinte:
- Verifique se a
access_token
foi concedida ao Google, identificada 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 por um token de ID do Google ou com um código de erro HTTP se a solicitação for inválida.
Resposta HTTP
Sucesso
Retorne o 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
No caso de uma solicitação HTTP inválida, responda com um dos seguintes códigos de erro HTTP:
Código de status HTTP | Corpo | Descrição |
---|---|---|
400 | {"error": "invalid_request"} |
A solicitação não tem um parâmetro, então o servidor não pode prosseguir com a solicitação. Também pode ser retornado se a solicitação incluir um parâmetro sem suporte ou se repetir um parâmetro |
401 | {"error": "invalid_request"} |
Falha na autenticação do cliente, por exemplo, quando a solicitação contém um secret ou ID do cliente inválido |
401 | {"error": "invalid_token"}
Inclua "Autenticação WWW: portador" desafio de autenticação no cabeçalho de resposta |
O token de acesso do parceiro é inválido. |
403 | {"error": "insufficient_permission"}
Inclua "Autenticação WWW: portador" desafio de autenticação 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ória |
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 o código de autorização pelo token de ID
Você precisará trocar o código de autorização recebido 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 encontrado na página Credenciais do Console de APIs. Geralmente, essa é 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 deste 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 e 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 |
O 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 deste 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 deste campo é 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 declaração do JWT
É possível validar e decodificar a declaração do JWT usando um Biblioteca de decodificação JWT para sua linguagem. Usar as chaves públicas do Google, disponíveis em 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 a propriedade
emissor (campo iss
) é https://accounts.google.com
, que o público-alvo
(campo aud
) é seu ID de cliente atribuído e que o token não expirou
(campo exp
).
Use os campos email
, email_verified
e hd
para determinar se
O Google hospeda e é autoritativo para um endereço de e-mail. Nos casos em que o Google
autoritativo, 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, estes métodos
pode ser usada para verificar a conta antes da vinculação.
Casos em que o Google é confiável:
email
tem o sufixo@gmail.com
. Esta é uma conta do Gmail.- A opção
email_verified
é verdadeira ehd
foi definida. Esta é uma conta do G Suite.
Os usuários podem se registrar para Contas do Google sem usar o Gmail ou o G Suite. Quando
email
não contém um sufixo @gmail.com
e hd
está ausente, o Google não está
com autoridade e senha ou outros métodos de desafio
o usuário. email_verified
também pode ser verdadeiro porque o Google verificou inicialmente o
usuário quando a Conta do Google foi criada, mas a propriedade do terceiro
pode ter mudado desde então.