Vinculação de contas do Google com OAuth (fluxo implícito - arquivado)

Para oferecer suporte ao fluxo implícito do OAuth 2.0, seu serviço disponibiliza um endpoint de autorização por HTTPS. Esse endpoint é responsável pela autenticação e pela obtenção do consentimento dos usuários para acesso aos dados. O endpoint de autorização apresenta uma interface de login para os usuários que ainda não fizeram login e registra o consentimento para o acesso solicitado.

Quando um aplicativo do Google precisa chamar uma das APIs autorizadas do seu serviço, o Google usa esse endpoint para receber permissão dos usuários e chamar essas APIs em nome deles.

Vinculação de contas do Google: fluxo implícito do OAuth

O diagrama de sequência a seguir detalha as interações entre o usuário, o Google e os endpoints do seu serviço.

Funções e responsabilidades

A tabela a seguir define as funções e responsabilidades dos participantes no fluxo implícito do OAuth de vinculação de contas do Google (GAL). Observação: no GAL, o Google atua como o cliente do OAuth, enquanto seu serviço atua como o provedor de identidade/serviço.

Uma sessão típica de fluxo implícito do OAuth 2.0 iniciada pelo Google tem o seguinte fluxo:

1. O Google abre seu endpoint de autorização no navegador do usuário. O usuário faz login, se ainda não tiver feito isso, e concede permissão ao Google para acessar os dados dele com sua API, caso ainda não tenha concedido permissão.
2. Seu serviço cria um token de acesso e o retorna ao Google. Para fazer isso, redirecione o navegador do usuário de volta ao Google com o token de acesso anexado à solicitação.
3. O Google chama as APIs do seu serviço e anexa o token de acesso a cada solicitação. Seu serviço verifica se o token de acesso concede autorização ao Google para acessar a API e conclui a chamada de API.

Receita de implementação

Siga estas etapas para implementar o fluxo implícito.

Etapa 1: processar solicitações de autorização

Quando o Google inicia a vinculação de contas, ele redireciona o usuário para seu endpoint de autorização. Para ver contratos de protocolo detalhados e requisitos de parâmetros, consulte o endpoint de autorização.

Para processar a solicitação, faça o seguinte:

1. Valide a solicitação:

   • Confirme se o client_id corresponde ao ID do cliente atribuído ao Google.
   • Confirme se o redirect_uri corresponde ao URL de redirecionamento do Google esperado: none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
   • Verifique se response_type é token.

2. Autentique o usuário:

   • Verifique se o usuário fez login no seu serviço.
   • Se o usuário não estiver conectado, peça que ele conclua o fluxo de login ou inscrição.

3. Gerar token de acesso:

   • Crie um token de acesso exclusivo e não adivinhável associado ao usuário e ao cliente.

4. Redirecionar de volta para o Google:

   • Redirecione o navegador para o URL fornecido em redirect_uri.
   • Anexe os seguintes parâmetros ao fragmento do URL (hash):
     • access_token: o token de acesso gerado.
     • token_type: precisa ser bearer.
     • state: o valor de estado não modificado recebido do Google.

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.