Neste guia, ajudamos você a escolher entre usar a biblioteca dos 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 OAuth 2.0 é melhor para seu aplicativo da Web.
Antes de ler este guia, presume-se que você já conheça os termos e conceitos descritos nos guias Visão geral e Como funciona a autorização do usuário.
A biblioteca SIG é executada nesses navegadores compatíveis no dispositivo do usuário. Ele não é destinado ao uso com frameworks de JavaScript do lado do servidor, como Node.js. Em vez disso, use a biblioteca de cliente Node.js do Google.
Este guia aborda apenas os tópicos sobre 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 Migração do Login do Google para se inscrever e fazer login do usuário.
Como decidir se a biblioteca SIG é a melhor opção para você
Escolha se você vai usar a biblioteca do Google ou criar a própria biblioteca de acordo com suas necessidades. Uma visão geral dos recursos e funcionalidades:
- A biblioteca JavaScript de serviços de identidade do Google implementa:
- Fluxos de consentimento baseados em pop-up para minimizar os redirecionamentos, permitindo que os usuários permaneçam no seu site durante todo o processo de autorização.
- Recursos de segurança, como a 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 acessível para humanos e links de documentação para uso dos engenheiros durante o desenvolvimento e posteriormente para os visitantes do site.
- Ao implementar sem a biblioteca de serviços de identidade, você é responsável por:
- Gerenciamento de 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, respostas e evitar CSRF.
- Métodos para confirmar que um usuário deu consentimento para todos os escopos solicitados.
- Gerenciamento de códigos de erro do OAuth 2.0, criação de mensagens legíveis e links para ajuda do usuário.
Em resumo, o Google oferece a biblioteca SIG para ajudar você a implementar de maneira rápida e segura um cliente OAuth 2.0 e otimizar a experiência de autorização do usuário.
Como escolher um fluxo de autorização
Você precisará escolher um dos dois fluxos de autorização do OAuth 2.0: código implícito ou de autorização, independentemente de decidir usar a biblioteca JavaScript dos serviços de identidade do Google ou criar sua própria biblioteca.
Ambos os 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 aplicativo chamará as APIs do Google sem a presença do 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
- níveis mais altos ou mais baixos de segurança do usuário.
Ao comparar fluxos e avaliar os requisitos de segurança, é importante considerar que o nível de segurança do usuário varia de acordo com os escopos escolhidos. Por exemplo, ver 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 fluxo 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, incluindo a substituição de tokens expirados. | Apenas para a primeira solicitação de token. |
| O usuário precisa estar presente | Sim | Não, com suporte para uso off-line. |
| Segurança do usuário | Mínimo | A maioria tem autenticação de cliente e evita riscos de manipulação de tokens no navegador. |
| Token de acesso emitido | Sim | Sim |
| Token de atualização emitido | Não | Sim |
| É necessário ter um navegador compatível | 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 em execução na plataforma de back-end ou de um app da Web em execução no navegador do usuário. |
| Requer uma 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 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, a 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. |