Esta página apresenta alguns exemplos de utilização comuns de autenticação e autorização, com links para mais informações sobre como implementar cada exemplo de utilização.
Para uma vista geral da autenticação na Google, consulte o artigo Autenticação na Google.
Autentique-se nas APIs Google
As APIs Google requerem um token de acesso ou uma chave da API válidos com cada pedido. A forma como faculta estas credenciais necessárias depende de onde o código está a ser executado e dos tipos de credenciais que a API aceita.
Use as bibliotecas de cliente e as Credenciais padrão da aplicação
A forma recomendada de usar as APIs Google é usar uma biblioteca cliente e as Credenciais padrão da aplicação (ADC). Application Default Credentials (ADC) é uma estratégia usada pelas bibliotecas de autenticação para encontrar automaticamente credenciais com base no ambiente da aplicação. As bibliotecas de autenticação disponibilizam essas credenciais às bibliotecas cliente da Cloud e bibliotecas cliente de APIs Google. Quando usa o ADC, o seu código pode ser executado num ambiente de desenvolvimento ou de produção sem alterar a forma como a sua aplicação se autentica nos Trusted Cloud by S3NS serviços e APIs.
A forma como configura o ADC depende do local onde o código está a ser executado. A ADC suporta a autenticação como conta de serviço e a autenticação como utilizador.
Autentique a partir do Google Kubernetes Engine (GKE)
Usa a Federação do Workload Identity para o GKE para permitir que as suas cargas de trabalho em execução no GKE acedam em segurança às APIs Google. A federação de identidades da carga de trabalho para o GKE permite que uma conta de serviço do GKE no seu cluster do GKE atue como uma conta de serviço da gestão de identidade e de acesso (IAM).
Autentique a partir do Knative serving
Autentique os seus serviços Knative Serving através da Workload Identity Federation para o GKE, que lhe permite aceder às APIs Google.
Use uma API que aceite chaves da API
Se uma API suportar chaves da API, pode fornecer uma chave da API com um pedido em vez do token de acesso. As chaves da API associam o pedido a um Trusted Cloud projeto para fins de faturação e quotas.
Para determinar se uma API suporta chaves da API, consulte a documentação da sua API.
Use símbolos da Web JSON (JWTs) autoassinados
Algumas APIs Google suportam símbolos da Web JSON (JWTs) autoassinados em vez de tokens de acesso. A utilização de um JWT autoassinado permite-lhe evitar fazer um pedido de rede ao servidor de autorização da Google. Esta abordagem requer que crie o seu próprio JWT assinado. Para mais informações sobre os tokens, consulte o artigo Vista geral dos tokens.
Use as bibliotecas e os pacotes de autenticação
Se o ADC e a implementação do OAuth fornecida pelas bibliotecas cliente da nuvem ou pelas bibliotecas cliente de APIs Google não estiverem disponíveis no seu ambiente, pode usar as bibliotecas e os pacotes de autenticação.
Estão disponíveis as seguintes bibliotecas e pacotes de autenticação:
Também pode implementar o fluxo do OAuth 2.0 através dos pontos finais do OAuth 2.0 da Google. Esta abordagem requer uma compreensão mais detalhada do funcionamento do OAuth 2.0 e do OpenID Connect. Para mais informações, consulte o artigo Usar o OAuth 2.0 para aplicações de servidor Web.
Trusted Cloud Exemplos de utilização específicos do serviço
Alguns Trusted Cloud serviços suportam fluxos de autenticação específicos desse serviço.
Forneça acesso por tempo limitado a um recurso do Cloud Storage através de URLs assinados
Os URLs assinados oferecem acesso por tempo limitado a um recurso específico do Cloud Storage.
Autentique-se em clusters do GKE Enterprise
Pode autenticar-se em clusters do GKE Enterprise através de Trusted Cloud identidades ou usando um fornecedor de identidade de terceiros:
- Autentique-se com Trusted Cloud identidades através do gateway Connect.
- Autentique-se com um fornecedor de identidade de terceiros que suporte OIDC ou LDAP, através do serviço de identidade do GKE.
Configure uma API implementada com o API Gateway ou o Cloud Endpoints para autenticação
O API Gateway e os Cloud Endpoints suportam a autenticação de serviço para serviço e a autenticação de utilizadores com o Firebase, tokens de ID assinados pela Google, Okta, Auth0 e JWTs.
Para mais informações, consulte a documentação do produto:
- Escolher um método de autenticação para o API Gateway
- Escolher um método de autenticação para os Cloud Endpoints
Autenticação para aplicações alojadas no Cloud Run ou nas funções do Cloud Run
As aplicações alojadas no Cloud Run e nas funções do Cloud Run requerem tokens de ID para autenticação.
Para obter informações sobre outras formas de adquirir um token de ID, consulte o artigo Obtenha um token de ID. Para mais informações sobre tokens de ID, consulte o artigo Tokens de identidade.
Cloud Run
Existem várias formas de configurar um serviço do Cloud Run, consoante a forma como o serviço vai ser invocado. Também pode ter de fazer a autenticação noutros serviços a partir de um serviço do Cloud Run, o que requer um token de ID OIDC.
Para autenticar utilizadores no seu serviço a partir de uma app Web ou para dispositivos móveis, usa a Identity Platform ou a Firebase Authentication. Também pode usar o Identity-Aware Proxy (IAP) para autenticar utilizadores internos.
Funções do Cloud Run
Quando invoca uma função, tem de autenticar a invocação. Pode usar credenciais de utilizador ou um token de ID OIDC.
Autentique utilizadores de aplicações
Existem várias opções para autenticar os utilizadores finais da sua aplicação, dependendo do resto do ambiente da aplicação. Use as descrições seguintes para ajudar a compreender a opção adequada para a sua aplicação.
| Serviço de autenticação | Descrição |
|---|---|
| Serviços de identidade Google |
Os Serviços de identidade Google incluem o Iniciar sessão com o Google, o botão de início de sessão do utilizador da Google e as APIs e o SDK dos Serviços de identidade. Os serviços de identidade da Google baseiam-se nos protocolos OAuth 2.0 e OpenID Connect (OIDC). Se estiver a criar uma aplicação para dispositivos móveis e quiser autenticar utilizadores através de contas do Gmail e do Google Workspace, o Iniciar sessão com o Google pode ser uma boa opção. O Iniciar sessão com o Google também suporta a utilização de Contas Google com um sistema de início de sessão existente. Mais informações O Iniciar sessão com o Google oferece início de sessão na conta do Gmail e do Google Workspace, bem como suporte para palavras-passe únicas (OTP). O Iniciar sessão com o Google destina-se a contas apenas Google ou Contas Google num sistema de início de sessão existente para aplicações para dispositivos móveis. O Iniciar sessão com o Google está disponível para iOS, Android e aplicações Web. |
| Firebase Authentication |
O Firebase Authentication fornece serviços de autenticação e bibliotecas para autenticar utilizadores na sua aplicação para uma vasta gama de tipos de contas de utilizador. Se quiser aceitar inícios de sessão de utilizadores a partir de várias plataformas, o Firebase Authentication pode ser uma boa opção. Mais informações O Firebase Authentication oferece suporte de autenticação para muitos tipos de contas de utilizador. O Firebase Authentication suporta a autenticação por palavra-passe e o início de sessão federado com o Google, o Facebook, o Twitter e outras plataformas. A Identity Platform e o Firebase Authentication baseiam-se nos Serviços de identidade Google. O Firebase Authentication destina-se a aplicações de consumidor. O Identity Platform é ideal para utilizadores que querem ser o seu próprio fornecedor de identidade ou que precisam da funcionalidade pronta para a empresa que o Identity Platform oferece. Para mais informações sobre as diferenças entre estes produtos, consulte Diferenças entre a Identity Platform e o Firebase Authentication. Os seguintes links fornecem mais informações:
|
| Identity Platform |
O Identity Platform é uma plataforma de gestão de identidade e de acesso do cliente (CIAM) que ajuda as organizações a adicionar capacidade de gestão de identidade e de acesso de nível empresarial às respetivas aplicações. Se estiver a criar uma aplicação para utilização com um fornecedor de identidade Google, como o Google Workspace, ou o seu próprio serviço de gestão de identidade e acesso, a Identity Platform pode ser uma boa opção. Mais informações A Identity Platform oferece um serviço de identidade e autenticação personalizável e de fácil implementação para o registo e o início de sessão de utilizadores. A Identity Platform suporta vários métodos de autenticação: SAML, OIDC, email/palavra-passe, redes sociais, telemóvel e opções personalizadas. A Identity Platform e o Firebase Authentication baseiam-se nos Serviços de identidade Google. O Firebase Authentication destina-se a aplicações de consumidor. O Identity Platform é ideal para utilizadores que querem ser o seu próprio fornecedor de identidade ou que precisam da funcionalidade pronta para a empresa que o Identity Platform oferece. Para mais informações sobre as diferenças entre estes produtos, consulte Diferenças entre a Identity Platform e o Firebase Authentication. |
| OAuth 2.0 e OpenID Connect |
O OpenID Connect permite-lhe processar e usar tokens de autenticação com a maior personalização. Se quiser ter o máximo controlo sobre a implementação do OAuth 2.0 e se sentir à vontade para implementar fluxos do OAuth 2.0, considere esta opção. Mais informações A implementação do OAuth 2.0 da Google está em conformidade com a especificação do OpenID Connect e é certificada pelo OpenID. O OpenID Connect é uma camada de identidade sobre o protocolo OAuth 2.0. A sua aplicação pode usar o OpenID Connect para validar o token de ID e obter informações do perfil do utilizador. O OAuth 2.0 pode ser usado para implementar a autenticação programática num recurso protegido pelo Identity-Aware Proxy. |
| Identity-Aware Proxy (IAP) |
O IAP permite-lhe controlar o acesso à sua aplicação antes de os pedidos chegarem aos recursos da aplicação. Ao contrário dos outros serviços de autenticação nesta tabela, que são implementados na sua aplicação, o IAP realiza a autenticação antes de a sua aplicação poder ser alcançada. Mais informações Com a IAP, estabelece uma camada de autorização central para aplicações e usa cabeçalhos assinados para proteger a sua app. As aplicações protegidas pela IAP só podem ser acedidas por diretores que tenham a função da IAM correta. Quando um utilizador final tenta aceder a um recurso protegido pelo IAP, o IAP realiza verificações de autenticação e autorização por si. A IAP não protege contra a atividade num projeto, como outro serviço no mesmo projeto. Para identidades Google, a IAP usa tokens de ID. Para mais informações, consulte o artigo Autenticação programática. Para ver informações sobre como o IAP protege os recursos da sua aplicação, consulte a vista geral do IAP. Os seguintes tutoriais específicos do idioma estão disponíveis para as compras na app: |
| API App Engine Users | Para aplicações executadas no ambiente padrão do App Engine, a API Users está disponível para fornecer autenticação de utilizadores para alguns idiomas. |
| Autorizar o acesso a recursos do utilizador final | Se a sua aplicação aceder a recursos pertencentes ao utilizador final, tem de garantir que este dá autorização para o fazer. Este exemplo de utilização é, por vezes, denominado OAuth de três partes ou 3LO, porque existem três entidades envolvidas: a aplicação, o servidor de autorização e o utilizador. |
Opções de autenticação e autorização para o Trusted Cloud e o Google Workspace
Trusted Cloud e o Google Workspace oferecem várias opções para configurar o acesso, melhorar a segurança da conta e administrar contas.
Conceda acesso aos recursos do Trusted Cloud para cargas de trabalho externas
A federação de identidades da carga de trabalho permite-lhe conceder às cargas de trabalho nas instalações ou de várias nuvens acesso a Trusted Cloud recursos. Anteriormente, este exemplo de utilização exigia a utilização de chaves de contas de serviço, mas a Workload Identity Federation evita a manutenção e o encargo de segurança da utilização de chaves de contas de serviço. A Workload Identity Federation suporta fornecedores de identidade compatíveis com OIDC ou SAML 2.0.
Configure um Fornecedor de identidade
Pode usar o Google como fornecedor de identidade usando o Cloud ID ou o Google Workspace. Também pode federar uma conta do Cloud ID ou do Google Workspace com um fornecedor de identidade externo. Esta abordagem usa SAML, o que permite aos seus funcionários usar a respetiva identidade e credenciais existentes para iniciar sessão nos serviços Google.
Configure a autenticação de dois fatores
A exigência da autenticação de dois fatores é uma prática recomendada que ajuda a impedir que autores de ameaças acedam a uma conta quando obtiveram acesso às credenciais dessa conta. Com a autenticação de dois fatores, é necessária uma segunda informação ou identificação do utilizador antes de este ser autenticado. A Google oferece várias soluções que suportam a norma FIDO (Fast IDentity Online).
A Identity Platform suporta a autenticação de dois fatores para apps Web, iOS e Android.
Os Serviços de identidade da Google suportam a autenticação FIDO (Fast IDentity Online).
A Google suporta várias soluções de hardware para a autenticação de dois fatores, como as chaves Titan.
Configure o acesso baseado em certificados
Como parte da solução de confiança zero do Chrome Enterprise Premium, o acesso baseado em certificados limita o acesso apenas a utilizadores autenticados num dispositivo fidedigno, identificando os dispositivos através dos respetivos certificados X.509. O acesso baseado em certificados também é, por vezes, denominado Transport Layer Security mútuo (mTLS).
Informações gerais da conta e de autenticação
Obtenha ajuda para aceder a uma Conta Google
Se precisar de ajuda para aceder ou gerir uma Conta Google, consulte a página de apoio técnico da Conta Google.
Trate credenciais comprometidas
Se considerar que as suas credenciais foram comprometidas, existem passos que você ou o seu administrador podem seguir para mitigar a situação. Para mais informações, consulte o artigo Como processar credenciais Trusted Cloud by S3NS comprometidas.
Receba ajuda com problemas da autoridade de certificação
Se vir erros relacionados com um problema com o seu certificado ou autoridade de certificação (AC), incluindo a sua AC raiz, consulte as perguntas frequentes dos Google Trust Services para mais informações.