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.
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.
auth_time and amr ClaimsWhen 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:
auth_time and amr claims provide you insights into this session.The two new claims are available within the ID Token:
auth_time (Authentication Time):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):auth_time.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.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.
Static authentication policies are often insufficient in today's threat landscape. More dynamic, granular session insights help to more accurately identify and prevent account takeover, fake account usage, and other fraudulent activities; you can more confidently permit sensitive or high-value action when there's strong evidence of a recent and securely authenticated session. Fewer security incidents and fraudulent accounts lead to reduced support calls, investigation time, and potential financial losses.
Other new security capabilities enabled by these claims that your platform may include:
amr values to maintain a record of the authentication methods used to access sensitive data or functions.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.amr into your authorization logic. For example, denying access to critical admin functions unless mfa is present or a security key (hwk) is used.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 }
}
}
Visit Google Identity developer documentation for additional detail and cross-platform examples of working with these claims.