Este guia ajuda você a escolher entre usar a biblioteca de Serviços de Identificação do Google para autorização do usuário ou implementar sua própria biblioteca JavaScript. Ele ajuda a decidir qual fluxo de autorização do OAuth 2.0 é melhor para seu aplicativo da Web.
Antes de ler este guia, presumimos que você esteja familiarizado com os termos e conceitos descritos na Visão geral e Como funciona a autorização do usuário guia.
A biblioteca GIS é executada nesses navegadores compatíveis no dispositivo do usuário. Ela não foi criada para uso com frameworks JavaScript do lado do servidor, como o Node.js. Em vez disso, use a Node.js do Node.js do Google.
Este guia aborda apenas tópicos de autorização e compartilhamento de dados pessoais. Ele não analisa a autenticação do usuário. Em vez disso, consulte o guia Fazer login com o Google e Migrar do Login do Google para inscrição e login do usuário.
Decidir se a biblioteca GIS é adequada para você
Você precisa escolher se o uso da biblioteca do Google ou a criação da sua própria biblioteca atende melhor às suas necessidades. Visão geral dos recursos e funcionalidades:
- A biblioteca JavaScript de Serviços de Identificação do Google implementa:
- Fluxos de consentimento baseados em caixas de diálogo 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ções entre sites (CRSF, na sigla em inglês).
- Métodos auxiliares para solicitar escopos individuais e confirmar o consentimento do usuário.
- Tratamento de erros e links de documentação fáceis de usar para engenheiros durante o desenvolvimento e, posteriormente, para visitantes do seu site.
- Ao implementar sem a biblioteca de Serviços de Identificação, 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.
- Implementar recursos de segurança para validar solicitações e respostas e evitar CSRF.
- Métodos para confirmar se um usuário concedeu consentimento para todos os escopos solicitados.
- 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 forma rápida e segura e otimizar a experiência de autorização do usuário.
Escolher um fluxo de autorização
Você precisará escolher um dos dois fluxos de autorização do OAuth 2.0: implícito ou código de autorização, independentemente de decidir usar a biblioteca JavaScript de Serviços de Identificação do Google ou criar sua própria biblioteca.
Os dois fluxos resultam em um token de acesso que pode ser usado para chamar as 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 as APIs do Google sem a presença do usuário,
- se uma plataforma de back-end é necessária para hospedar um endpoint e armazenar tokens de atualização por usuário para contas de usuário individuais e
- níveis mais altos ou mais baixos 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, visualizar convites de agenda como somente leitura pode ser considerado menos arriscado do que usar um escopo de leitura e gravação para editar arquivos no Drive.
Comparação do fluxo do OAuth 2.0
| Fluxo implícito | Fluxo do código de autorização | |
| Consentimento do usuário necessário | Para cada solicitação de token, incluindo a substituição de tokens expirados. | Apenas para a primeira solicitação de token. |
| O usuário precisa estar presente | Sim | Não, oferece suporte ao uso off-line. |
| Segurança do usuário | Mínimo | Máximo, tem autenticação de cliente e evita riscos de tratamento de tokens no navegador. |
| Token de acesso emitido | Sim | Sim |
| Token de atualização emitido | Não | Sim |
| Navegador compatível necessário | Sim | Sim |
| Token de acesso usado para chamar as APIs do Google | somente de um app da Web em execução no navegador do usuário. | de um servidor em execução 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 tokens de atualização. |
| Requer 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 token de acesso novo e válido. | Após uma solicitação inicial do usuário, sua plataforma troca o token de atualização armazenado para receber um token de acesso novo e válido necessário para chamar as APIs do Google. |