Your sign-in request asks for amr and auth_time. The request succeeds. The ID token comes back — and neither claim is there. Nothing errored, so the team starts upgrading SDK versions. That is almost never the problem.
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.
What the Security Bundle actually returns
amr — Authentication Methods References
A JSON array describing how the user last signed in to Google. Google supports pwd, swk (passkey or software key), hwk (hardware security key), sms, tel and mfa. The presence of mfa confirms the sign-in met Google's multi-factor requirements.
auth_time — last authentication timestamp
A Unix timestamp for when the user most recently authenticated to their Google Account. Compared against the token's iat, it tells you how stale that Google session is before you allow a sensitive action.
Cross-Account Protection (RISC)
A separate, optional service that pushes signed security event tokens to an endpoint you host — session revocations, token revocations, account disabled for hijacking. Google explicitly recommends enabling it alongside the bundle.
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 diagnostic trap: because the request returns HTTP 200 with a perfectly valid ID token, every layer of your stack reports success. Teams typically burn days on SDK upgrades, claims-parameter encoding and nonce handling before anyone checks the OAuth app's publishing and verification status.
The gate, in order
Publishing status must be In production. An app sitting in Testing does not qualify. Moving to production is also what removes the test-user cap and the unverified-app warning screen — see Internal vs External user type for why that dropdown decides whether verification applies to you at all.
Verification status must read Verified. This is the full OAuth app verification path in the Google Auth Platform Verification Center — brand review, scope justification, demo video, privacy policy and, for restricted scopes, an annual security assessment. Our Google OAuth verification guide covers what reviewers actually check.
The advanced settings must be switched on. Session age claims enable auth_time; authentication strength claims enable amr. Both are opt-in and both are off until someone turns them on.
Then the claims must be requested correctly per platform. The mechanism differs across the OIDC endpoint, the Web library, Android and iOS. Even with the gate cleared, a request built for the wrong surface returns a token without the claims — indistinguishable from the unverified case.
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
- App still in Testing. The integration was built and demoed in testing mode, so nobody noticed the claims were never arriving in the first place.
- Verification rejected on brand grounds. App name, logo or homepage do not match the verified domain, so the app never reaches Verified and the claims stay off.
- Advanced settings never enabled. Verification passes, everyone celebrates, and the claims are still absent because the two toggles were never touched.
- Wrong platform request shape. The claims parameter works on the web flow but the Android or iOS request was never updated, so mobile users silently get a reduced token.
- Workspace assumptions. Cross-Account Protection does not currently send security events for Google Workspace users, which breaks risk models built on the assumption that every account emits events.
- RISC endpoint rejected. The receiver must be HTTPS and must sit on one of the project's authorized domains, or registration fails outright.
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.