Google groups a small set of extra ID token claims under what it calls the Security Bundle for Sign in with Google. These claims tell your risk engine how and when the user last authenticated to their Google Account — signals that are genuinely useful for step-up authentication, fraud scoring and session decisions.

They are also, per Google's own documentation, switched off by default and only returned once your OAuth app is published to production and verified. That single sentence is where most integrations quietly stall.

Sign in with Google Security Bundle: what it returns

The Sign in with Google Security Bundle explains when Google includes the amr and auth_time claims in an ID token. These claims help applications make safer session and risk decisions.

For the Sign in with Google Security Bundle, verify that the OAuth app is published, production-ready, and approved before debugging token parsing.

Why the claims silently go missing

Google's documentation is blunt about the failure mode: missing claims are likely because the app is not verified, or because the additional settings are disabled — and disabled is the default state. There is no error, no warning, and no difference in the shape of a successful response. You simply get an ID token without those two fields.

The gate, in order

The part that catches product teams, not developers

Steps 3 and 4 are configuration. Step 2 is a review process with a queue, a rejection path and dependencies on assets you may not control yet — your verified domain, your published privacy policy, your brand assets and your scope list. If any of your scopes fall into the sensitive or restricted tier, the timeline and the evidence burden change substantially; which tier your scopes land in is decided by Google, not by you.

So a feature that looks like a two-line SDK change is, in practice, blocked behind an approval that can take weeks and can be sent back for reasons that have nothing to do with your sign-in code.

Where these projects commonly get stuck

What it is worth once it works

The honest summary

The Security Bundle is not a hard technical problem. It is an approval problem wearing a technical disguise. The code changes are small; the blocker is getting the OAuth app through publication and verification cleanly, with scopes, brand assets and policy pages that hold up to review — and then knowing which of the four gates is the one actually failing.

That diagnosis is the expensive part, because every failure mode looks identical from the outside: a valid token with two fields missing. If your app is stuck somewhere in that sequence, or verification has come back rejected more than once, this is exactly the kind of review preparation and policy-alignment work we handle for Google OAuth and API verification projects. Outcomes depend on Google's review and on your app meeting their published requirements — no specific result can be promised — but the path is well mapped, and most of the delay comes from fixable submission problems rather than from the platform itself.

All requirements described here are from Google's official Sign in with Google Security Bundle and Cross-Account Protection documentation, current as of August 2026. Google changes these settings and their locations periodically — always confirm against the live documentation before you build.

Google’s official OpenID Connect documentation explains ID token claims, authentication context, and validation requirements for Sign in with Google.