With the rise of phishing and online abuse, it’s more important than ever that you’re keeping your platform and users as safe as possible. That’s why we’re introducing new session metadata claims within Sign in with Google, designed to provide you deeper insights into how and when a user authenticates.

Available for verified apps, these OpenID Connect (OIDC) standard claims are added to the ID Token your backend systems receive, allowing you to make informed security decisions and move towards more dynamic, risk-based access controls. These enhancements benefit users signing in with any type of Google Account, including personal Gmail accounts and those managed by Google Workspace.

The Value of Federated Identity Signals

By using Sign in with Google, you're leveraging Google's robust, secure authentication infrastructure. Google has already vetted the user's session. The new OIDC claims allow your application to benefit from that vetting, taking the burden of certain aspects of strong authentication off your plate. Google manages the intricacies of the authentication event and provides your platform with the useful signals to make informed decisions.

What's New: auth_time and amr Claims

When a user signs into a Google Account and later signs into an app using Sign in with Google, these claims are shared in the ID token. There are two authentication moments and two user sessions:

1. User <-> Google Session: Established when a user signs into their Google Account. Google manages this session's lifecycle and security. The new auth_time and amr claims provide you insights into this session.
2. User <-> Your Application Session: Established after the user signs in to your application, often initiated via Sign in with Google. Your application manages this session using the claims to improve session and account management decisions.

The two new claims are available within the ID Token:

• auth_time (Authentication Time):
  • What it is: This claim is a standard OIDC timestamp indicating the last time the user successfully authenticated and created a session with Google. This is different from when an ID Token or access token was issued to your app or website.
  • Why it's important: auth_time provides a clear signal of the freshness of the user's Google session, offering greater confidence that the user is actively present. This allows your platform to better enforce risk-based session policies, such as requiring re-authentication for sensitive actions after a set time.
• amr (Authentication Methods Reference):
  • What it is: This standard OIDC claim is a JSON array of strings that identifies the method(s) the user employed to authenticate their Google Account during the session indicated by auth_time.
    • Supported Values:
      • pwd: When the user authenticated using a password.
      • mfa: When the user completed a Multi-Factor Authentication challenge, such as using a recovery factor.
      • hwk: When the user authenticated using a hardware-secured key.
      • swk: When the user authenticated using a software-secured key.
      • tel: When the user authenticated using a phone.
      • sms: When the user authenticated using a text message.
  • Why it's important: amr offers crucial context on the strength of the authentication event. Knowing how a user authenticated allows you to implement finer-grained access controls.

These claims work on Android, iOS, and Web client and server applications.

Advanced Security Benefits

• Audit Logging: Log the amr values to maintain a record of the authentication methods used to access sensitive data or functions.
• Step-up Authentication: Use auth_time to determine session age and trigger step-up authentication challenges within your application for sensitive operations if the session is stale, even if the Google session is still valid.
• Authorization Policies: Incorporate amr into your authorization logic. For example, denying access to critical admin functions unless mfa is present or a security key (hwk) is used.

Getting Started

These new claims are available for verified applications. If you're already using Sign in with Google with OpenID Connect, you can add these security enhancements without significantly changing your existing auth flow. Simply request the claims via the standard OIDC claims parameter in the authentication request. For example:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=id_token&
client_id=YOUR_CLIENT_ID&
scope=openid email profile&
redirect_uri=https://example.com/user-login&
nonce=RANDOM_VALUE&
claims={ "id_token": {
    "amr": { "essential": true },
    "auth_time": { "essential": true }
  }
}

Plain text

Copied

Visit Google Identity developer documentation for additional detail and cross-platform examples of working with these claims.