Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/docs/authentication/use-cases below:

Authentication and authorization use cases

This page lists some common authentication and authorization use cases, with links to more information about how to implement each use case.

For an overview of authentication at Google, see Authentication at Google.

Google APIs require a valid access token or API key with every request. How you provide these required credentials depends on where your code is running and what types of credentials the API accepts.

The recommended way to use Google APIs is to use a client library and Application Default Credentials (ADC). Application Default Credentials (ADC) is a strategy used by the authentication libraries to automatically find credentials based on the application environment. The authentication libraries make those credentials available to Cloud Client Libraries and Google API Client Libraries. When you use ADC, your code can run in either a development or production environment without changing how your application authenticates to Google Cloud services and APIs.

How you set up ADC depends on where your code is running. ADC supports both authenticating as a service account and authenticating as a user.

You use Workload Identity Federation for GKE to enable your workloads running on GKE to securely access Google APIs. Workload Identity Federation for GKE lets a GKE service account in your GKE cluster act as an Identity and Access Management (IAM) service account.

You authenticate your Knative serving services by using Workload Identity Federation for GKE, which lets you access Google APIs.

If an API supports API keys, an API key can be provided with a request instead of the access token. API keys associate the request with a Google Cloud project for billing and quota purposes.

To determine whether an API supports API keys, see the documentation for your API.

Some Google APIs support self-signed JSON Web Tokens (JWTs) instead of access tokens. Using a self-signed JWT lets you avoid making a network request to Google's authorization server. This approach requires that you create your own signed JWT. For more information about tokens, see Token types.

If ADC and the OAuth implementation provided by the Cloud Client Libraries or Google API Client Libraries isn't available in your environment, you can use the authentication libraries and packages.

The following authentication libraries and packages are available:

• C#
• Go
• Java
• Node.js
• PHP
• Python
• Ruby

You can also implement the OAuth 2.0 flow using Google's OAuth 2.0 endpoints. This approach requires a more detailed understanding of how OAuth 2.0 and OpenID Connect work. For more information, see Using OAuth 2.0 for Web Server Applications.

Some Google Cloud services support authentication flows specific to that service.

Signed URLs provide time-limited access to a specific Cloud Storage resource.

You can authenticate to GKE Enterprise clusters using Google Cloud identities or by using a third-party identity provider:

• Authenticate with Google Cloud identities, by using the Connect gateway.
• Authenticate with a third-party identity provider that supports OIDC or LDAP, by using GKE Identity Service.

API Gateway and Cloud Endpoints support service-to-service authentication and user authentication with Firebase, Google-signed ID tokens, Okta, Auth0, and JWTs.

For information, see the product documentation:

• Choosing an authentication method for API Gateway
• Choosing an authentication method for Cloud Endpoints

Applications hosted on Cloud Run and Cloud Run functions require OpenID Connect (OIDC) tokens, or ID tokens, for authentication.

For more information, see the product documentation for the hosting services listed below. For information about other ways to acquire an ID token, see Get an ID token. For more information about ID tokens, including validating ID tokens, see ID tokens.

There are various ways to set up a Cloud Run service, depending on how the service will be invoked. You might also need to authenticate to other services from a Cloud Run service, which requires an OIDC ID token.

To authenticate users to your service from a web or mobile app, you use Identity Platform or Firebase Authentication. You can also use Identity-Aware Proxy (IAP) to authenticate internal users.

When you invoke a function, you must authenticate your invocation. You can use user credentials or an OIDC ID token.

There are various options for authenticating the end users of your application, depending on the rest of your application environment. Use the descriptions below to help you understand the best option for your application.

Google Identity Services includes Sign In With Google, Google's user sign-in button, and Identity Services APIs and SDK. Google Identity Services is based on the OAuth 2.0 and OpenID Connect (OIDC) protocols.

If you're creating a mobile application, and you want to authenticate users using Gmail and Google Workspace accounts, Sign In With Google could be a good option. Sign In With Google also supports using Google Accounts with an existing sign-in system.

More information

Sign In With Google provides Gmail and Google Workspace account sign-in, and support for one-time passwords (OTP). Sign in with Google is targeted toward Google-only accounts, or Google Accounts in an existing sign-in system, for mobile applications.

Sign in With Google is available for iOS, Android, and web applications.

Firebase Authentication provides authentication services and libraries to authenticate users to your application for a wide array of user account types.

If you want to accept user sign-ins from multiple platforms, Firebase Authentication could be a good option.

More information

Firebase Authentication provides authentication support for many user account types. Firebase Authentication supports password authentication and federated sign-in with Google, Facebook, Twitter, and other platforms.

Identity Platform and Firebase Authentication are both based on Google Identity Services. Firebase Authentication is targeted toward consumer applications. Identity Platform is ideal for users who want to be their own identity provider, or who need the enterprise-ready functionality Identity Platform provides. For more information about the differences between these products, see Differences between Identity Platform and Firebase Authentication.

The following links provide more information:

• Where do I start with Firebase Authentication? helps you understand some ways of using Firebase Authentication.
• For Python applications running in the App Engine standard environment, see Authenticating users with Firebase.

Identity Platform is a customer identity and access management (CIAM) platform that helps organizations add enterprise-grade identity and access management capability to their applications.

If you're creating an application for use with a Google identity provider such as Google Workspace, or your own identity and access management service, Identity Platform could be a good option.

More information

Identity Platform provides a drop-in, customizable identity and authentication service for user sign-up and sign-in. Identity Platform supports multiple authentication methods: SAML, OIDC, email/password, social, phone, and custom options.

Identity Platform and Firebase Authentication are both based on Google Identity Services. Firebase Authentication is targeted toward consumer applications. Identity Platform is ideal for users who want to be their own identity provider, or who need the enterprise-ready functionality Identity Platform provides. For more information about the differences between these products, see Differences between Identity Platform and Firebase Authentication.

OpenID Connect lets you handle and use authentication tokens with the most customization.

If you want maximum control over your OAuth 2.0 implementation, and you're comfortable implementing OAuth 2.0 flows, consider this option.

More information

Google's OAuth 2.0 implementation conforms to the OpenID Connect specification and is OpenID Certified. OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. Your application can use OpenID Connect to validate the ID token and retrieve user profile information.

OAuth 2.0 can be used to implement programmatic authentication to an Identity-Aware Proxy-secured resource.

IAP lets you control access to your application before requests reach your application resources.

Unlike the other authentication services in this table, which are implemented within your application, IAP performs authentication before your application can be reached.

More information

With IAP, you establish a central authorization layer for applications and use signed headers to secure your app. IAP-protected applications can be accessed only by principals that have the correct IAM role. When an end user tries to access an IAP-secured resource, IAP performs authentication and authorization checks for you. IAP doesn't protect against activity within a project, such as another service in the same project.

For Google identities, IAP uses ID tokens. For more information, see Programmatic authentication.

For information about how IAP secures your application resources, see the IAP overview.

The following language-specific tutorials are available for IAP:

• Authenticating users with Go
• Authenticating users with Node.js
• Authenticating users with PHP
• Authenticating users with Python
• Authenticating users with Ruby

Google Cloud and Google Workspace provide various options for setting up access, enhancing account security, and administering accounts.

Workload Identity Federation lets you grant on-premises or multi-cloud workloads access to Google Cloud resources. Historically, this use case required the use of service account keys, but Workload Identity Federation avoids the maintenance and security burden of using service account keys. Workload Identity Federation supports OIDC-compatible or SAML 2.0-compatible identity providers.

You can use Google as your identity provider, by using Cloud Identity or Google Workspace. You can also federate a Cloud Identity or Google Workspace account with an external identity provider. This approach uses SAML, enabling your employees to use their existing identity and credentials to sign in to Google services.

Requiring two-factor authentication is a best practice that helps to prevent bad actors from accessing an account when they have gained access to the credentials for that account. With two-factor authentication, a second piece of information or identification from the user is required before that user is authenticated. Google's provides several solutions that support the FIDO (Fast IDentity Online) standard.

Identity Platform supports two-factor authentication for web, iOS, and Android apps.

Google Identity Services supports FIDO (Fast IDentity Online) authentication.

Google supports various hardware solutions for two-factor authentication, such as Titan Keys.

Part of the Chrome Enterprise Premium zero trust solution, certificate-based access limits access to only authenticated users on a trusted device, identifying devices through their X.509 certificates. Certificate-based access is also sometimes referred to as mutual Transport Layer Security (mTLS).

If you need help with accessing or managing a Google Account, see the Google Account support page.

If you believe that your credentials have been compromised, there are steps you or your administrator can take to mitigate the situation. For more information, see Handling compromised Google Cloud credentials.

If you see errors related to an issue with your certificate or certificate authority (CA), including your root CA, see the Google Trust Services FAQ for more information.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4