Google now tells apps how freshly you signed in

When an attacker logs in from a stolen cookie hours after the real user did, most apps see a perfectly valid session. They have no way to ask: how recently did this person actually sign in to Google, and how? Google is now starting to answer that question, by adding two new fields to the signed receipt an app receives after a Sign in with Google login.

The change is small in code but large in implication. In a post on the Google Developers Blog published Tuesday, Google product manager Sergei Akulich and product solutions engineer Brian Daugherty described two new OIDC claims, auth_time and amr, that will appear inside the ID token sent to a relying party's backend.

In plain English, auth_time is the timestamp of the user's last real Google login, not the moment a token was minted. amr (short for "authentication methods reference") is the list of methods the user actually used: password, passkey, hardware security key, or some combination. Both are part of the OpenID Connect standard, the same plumbing Google, Apple, Microsoft, and Okta use to hand identity proofs to third-party apps.

What this gives apps is a kind of secondary signal they have never had before. Until now, an ID token from Google effectively said "this person is signed in to Google, and here is who they are." With the new claims, the token can also say "this person last entered their password four days ago on a different device, and they used a passkey."

That matters because of the failure mode it lets apps catch. A stolen session cookie replayed the next morning looks identical to the original login to most apps, which is why account-takeover fraud keeps working. An app that reads auth_time can see that the underlying Google login happened before the cookie was issued, and either re-prompt for sign-in, require a step-up authentication method, or block the request entirely. An app that reads amr can refuse sessions that only used a password when a higher-assurance method was available, or demand a hardware key for sensitive actions.

Google's framing is that the identity provider has already done the work of vetting the user, so the app should be able to inherit that vetting. In Akulich and Daugherty's words, the company wants to give apps "deeper insights" into the strength of a session so they can make "more dynamic, risk-based access control decisions."

That is the architectural shift underneath the changelog entry. Federated login has historically been a binary gate: the identity provider checked the user, minted a token, and stepped out of the way. The new claims extend that gate into a continuous signal that apps can read on every request, not just at sign-in. It is a small change in the protocol and a large change in what every app that uses Sign in with Google has to think about.

There are real limits to what this actually fixes. The claims are a signal, not a defense. They do not stop phishing on their own, and they do not help if the attacker also steals the user's password and goes through a real Google sign-in. They raise the floor only for apps that read the claims and wire them into their authentication flow. Apps that ignore the new fields see no change at all.

The rollout is also incremental rather than universal. Google is making the claims available to verified apps in its identity ecosystem, meaning apps that have gone through a registration and verification process with Google. Apps that have not been verified do not get the new signals, which means smaller developers and unverified clients still receive the older, narrower ID token. Google has not published a timeline for expanding access.

None of that is an argument against the change. It is an argument for reading the announcement carefully. Google is positioning this as a step toward a federated identity model in which the provider does the heavy lifting of session-quality assessment and the relying app consumes the result. The two new claims are the visible edge of that shift. Whether they actually reduce account takeover will depend almost entirely on whether developers build for them, and whether app security teams treat session-freshness as a first-class signal the way they treat password strength today.

For now, the practical effect is that a verified app that wants to know how stale a session is, or what unlocked it, no longer has to guess. Google is telling it directly.