What happened
Google added two OIDC claims to Sign in with Google: auth_time, which records when the user actually logged in, and amr, which records how they authenticated. Verified apps can read both from the token.
The intended use is risk-based access control. Instead of treating every authenticated session as equally trustworthy, an app checks session age and authentication method before allowing a sensitive action — and triggers step-up authentication, a fresh login, when the signals say the session is stale or weakly verified. Google pitches the same claims for stronger fraud prevention overall.
It's a small change at the token level with a specific promise attached: the security decision moves from the moment of login to the moment of action. A session that signed in three weeks ago can still browse, fill a cart, and check out — it just can't rewrite the account's payment details without proving itself again.
Why this matters
Friction placement is a conversion problem before it's a security one. Blanket re-authentication bleeds checkout completion; zero re-authentication makes account takeover easy money — a hijacked session quietly edits the shipping address and orders against a saved card. Session metadata lets you put the friction exactly where the fraud lives: address changes, saved-payment edits, email swaps. Everywhere else, the customer never notices.
For most stores this won't arrive as a dashboard toggle. If your storefront offers Google sign-in through an SSO app or a custom headless build, the claims land in your integration layer — someone has to read them and enforce policy. And the verified-apps requirement is a real gate: your integration has to clear Google's verification to use them.
One honest caveat. If account takeover isn't showing up in your chargeback numbers, this is a nice-to-have you can file for later. Stores with saved payment methods and a meaningful account base are the ones who just got a free signal they didn't have before — and the bigger the share of customers signing in with Google, the more of your traffic the new claims actually cover. A store where most accounts use email-and-password gains far less from this than one that pushed social login hard.
What to do about it
Map where Google sign-in touches your stack
List every surface: the storefront SSO app, any headless or custom auth flow, customer-account integrations. If Google sign-in appears nowhere, file this story and move on — no shame in that.
Write your sensitive-actions list
Address changes, payment-method edits, email and password changes, first orders above a threshold you pick. Decide which of those should demand a recent, strongly-verified session. That list is your step-up policy — the claims are just how you enforce it.
Ask your auth vendor about the new claims
If a third-party app handles Google sign-in, ask whether it will expose auth_time and amr and let you set rules against them. For custom builds, scope the token-handling change and confirm your app's Google verification status before you plan the work.
Measure the friction you add
When step-up checks go live, watch completion rates on the gated actions and overall checkout conversion side by side. If legitimate customers start abandoning address updates, your thresholds are wrong — tune the session-age cutoff rather than ripping the control out.