Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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.
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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2023-12-01 UTC."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
