Este guia ajuda você a escolher entre usar a biblioteca do Google Identity Services para autorização do usuário ou implementar sua própria biblioteca JavaScript. Ele ajuda você a decidir qual fluxo de autorização do OAuth 2.0 é melhor para seu aplicativo da Web.
Antes de ler este guia, pressupomos que você esteja familiarizado com os termos e conceitos descritos no guia Visão geral e Como a autorização do usuário funciona.
A biblioteca GIS é executada nesses navegadores compatíveis com o dispositivo do usuário. Ele não se destina ao uso com bibliotecas JavaScript do servidor, como Node.js, mas sim a biblioteca de cliente Node.js do Google.
Este guia aborda somente tópicos de autorização e compartilhamento de dados. Ele não analisa a autenticação do usuário. Em vez disso, consulte Fazer login com o Google e o guia Como migrar do Login do Google para fazer login e fazer login do usuário.
Como decidir se a biblioteca GIS é ideal para você
Você precisa escolher se vai usar a biblioteca do Google ou criar o que for melhor para suas necessidades. Uma visão geral dos recursos e funcionalidades:
- A biblioteca JavaScript dos Serviços de identidade do Google implementa:
- Fluxos de consentimento com base em pop-ups para minimizar redirecionamentos, permitindo que os usuários permaneçam no seu site durante todo o processo de autorização.
- Recursos de segurança, como falsificação de solicitação entre sites (CRSF, na sigla em inglês).
- Métodos auxiliares para solicitar escopos individuais e confirmar o consentimento do usuário.
- Links de documentação e tratamento de erros humanos para uso dos engenheiros durante o desenvolvimento e posteriormente para os visitantes do site.
- Ao implementar sem a biblioteca do Identity Services, você é responsável
por:
- Gerenciar solicitações e respostas com os endpoints do OAuth 2.0 do Google, incluindo redirecionamentos.
- Otimizar a experiência do usuário.
- Implementação de recursos de segurança para validar solicitações e respostas e evitar CSRF.
- Métodos para confirmar que um usuário deu o consentimento para qualquer escopo solicitado.
- Gerenciar códigos de erro do OAuth 2.0, criar mensagens legíveis e links para a ajuda do usuário.
Em resumo, o Google oferece a biblioteca GIS para ajudar você a implementar um cliente OAuth 2.0 de maneira rápida e segura e otimizar a experiência de autorização do usuário.
Como escolher um fluxo de autorização
Será necessário escolher um dos dois fluxos de autorização do OAuth 2.0: código implícito ou de autorização, independentemente de você decidir usar a biblioteca JavaScript dos serviços de identidade do Google ou criar sua própria biblioteca.
Os dois fluxos resultam em um token de acesso que pode ser usado para chamar APIs do Google.
As principais diferenças entre os dois fluxos são:
- o número de ações do usuário,
- se o app vai chamar APIs do Google sem o usuário,
- Se uma plataforma de back-end for necessária para hospedar um endpoint e armazenar tokens de atualização por usuário para contas de usuário individuais, e
- de segurança do usuário.
Ao comparar fluxos e avaliar seus requisitos de segurança, um fator a ser considerado é que o nível de segurança do usuário varia de acordo com os escopos escolhidos. Por exemplo, ver os convites da agenda como somente leitura pode ser considerado menos arriscado do que usar um escopo de leitura/gravação para editar arquivos no Drive.
Comparação de fluxos do OAuth 2.0
| Fluxo implícito | Fluxo do código de autorização | |
| Consentimento do usuário obrigatório | Para cada solicitação de token, inclusive a substituição de tokens expirados. | Apenas para a primeira solicitação de token. |
| O usuário precisa estar presente | Sim | Não, compatível com o uso off-line. |
| Segurança do usuário | Mínimo | A maioria tem autenticação de cliente e evita riscos no processamento de tokens no navegador. |
| Token de acesso emitido | Sim | Sim |
| Token de atualização emitido | Não | Sim |
| Um navegador compatível é necessário | Sim | Sim |
| Token de acesso usado para chamar APIs do Google | somente de um aplicativo da web executado no navegador do usuário. | de um servidor executado na plataforma de back-end ou de um app da Web em execução no navegador do usuário. |
| Requer plataforma de back-end | Não | Sim, para hospedagem e armazenamento de endpoints. |
| Armazenamento seguro necessário | Não | Sim, para armazenamento de token de atualização. |
| Exige a hospedagem de um endpoint de código de autorização | Não | Sim, para receber códigos de autorização do Google. |
| Comportamento de expiração do token de acesso | Um gesto do usuário, como pressionar um botão ou clicar em um link, é necessário para solicitar e receber um novo token de acesso válido. | Após uma solicitação inicial do usuário, sua plataforma troca o token de atualização armazenado para receber um novo token de acesso válido necessário para chamar as APIs do Google. |