Using one OAuth client to get ID tokens for another client

What to do if we have a set of tokens issued to one Google OAuth client, but we need an ID token for another OAuth client? Continue »

All access tokens aren't created equal

Whenever we want to call a Google or Google Cloud API, we need an access token. But there’s more than one way to obtain an access token, and depending on which way we use, the resulting access token might behave a little differently. What kinds of access tokens are there, and how do they differ? Continue »

New documentation and tool support for authenticating to Google Cloud from an Active Directory environment

When an on-premises application needs to access Google Cloud, it’s tempting to just let it use a service account key. But if the application runs in an Active Directory environment, there’s a better alternative – we can let it use its domain credentials and “exchange” them against Google credentials. That doesn’t even require custom code anymore. Continue »

Dealing with partial consent in Google OAuth clients

When we use a tool like gcloud or IAP Desktop for the first time, we need to authorize it. Google Sign-in then shows us a consent screen that lists all the things the tool might do on our behalf, and we can decide whether to consent or deny. But sometimes, we get a third option. Continue »

What does the email_verified claim indicate in Google ID Tokens?

When you authenticate a user by using OpenID Connect and request the email scope, most identity providers add two additional claims to the ID Token, email and email_verified. The email claim does not need much explanation – but what about email_verified, what does this claim indicate and how does Google populate it? Continue »

Authenticating users in tools or desktop apps

If your plan is to develop a tool or desktop app instead of a server-side application, the benefits of application default credentials are less obvious and reusing the user’s personal gcloud credentials instead might seem attractive. But there are some pitfalls. Continue »

Impact of GCP session length on OAuth clients

Once you’ve signed in on google.com, the Cloud Console, or any other Google site, your browser session remains valid for multiple days. Not being prompted to sign in over and over again is convenient and at least in typical consumer scenarios, the risk that comes along with keeping the session is limited.

Things can look different in a corporate scenario where users might have access to sensitive data. Keeping sessions alive for 14 days (which is the default) might seem a little risky and might not be in line with an enterprise’s idea of security. G Suite Business and Cloud Identity Premium therefore allow you to change the default session length to a different period such as 8 hours. This setting applies to all Google services, not only GCP.

Recently, Google introduced another way to control session lifetime by allowing you to control the session length for Cloud Console and gcloud sessions.