That little Sign in with Google button just got a quiet but powerful upgrade. Until now it told an app who you are. Now it can also tell the app how recently and how securely you proved it. As Google announced, two new signals help apps fight account takeovers and fraud. Here is what changed, in plain language.
| Quick Answer Google added two new security signals to Sign in with Google: auth_time, which tells an app when you last logged into your Google account, and amr, which tells it how you logged in, such as a password, two-factor code, or hardware key. Apps can use these to make smarter, risk-based decisions, like asking you to re-verify before a sensitive action. It works on Android, iOS, and the web for verified apps. |
The Problem: A Login Is Not a Yes or No
For years, signing in was treated as a simple gate. You were either logged in or you were not. But that misses a lot. A login from five minutes ago using a hardware key is highly trustworthy. One from three weeks ago using only a password is far weaker.
That gap is exactly what attackers exploit. Phishing and account takeovers thrive when apps cannot tell a fresh, strong login from a stale, weak one. Google’s update gives apps that missing context.
| Why It Matters This happens behind the scenes, but you feel the benefit. Apps that use these signals can spot suspicious logins faster and protect your account, which means fewer hacked accounts and fewer fraud headaches for everyone. |
The Fix: Two New Security Signals
When you use Sign in with Google, Google has already done the hard work of verifying you. The update simply shares two useful facts from that check with the app, so the app does not have to reinvent strong security itself.
These facts are called claims, and they ride along inside the secure token the app receives. There are two new ones, and they are easier to understand than their names suggest.
Signal 1: auth_time, or How Fresh Your Login Is
The auth_time signal is a timestamp of the last time you actually logged into your Google account. Crucially, that differs from when the app got its token. It reflects when you genuinely proved who you are.
Think of it like the date stamp on an ID check. A login from two minutes ago gives an app strong confidence you are really there. A login from last month is weaker, so the app might ask you to verify again before, say, changing your password or making a payment.
| The Cool Part auth_time lets an app say: your session is still valid, but it has been a while, so please confirm it is really you before this sensitive action. That is the polite re-verification you sometimes see at exactly the right moment. |
Signal 2: amr, or How You Proved It
The amr signal, short for authentication methods reference, tells the app which method you used to log into Google. It comes as a simple list. Each entry maps to a familiar way of signing in.
| Code | What It Means |
| pwd | You signed in with a password |
| mfa | You completed a multi-factor or two-step check |
| hwk | You used a hardware security key |
| swk | You used a software-secured key |
| tel | You verified using a phone |
| sms | You verified using a text message |
This tells the app how strong your login was. A password alone is fine for everyday use. But an app might require a hardware key or two-factor check before letting you into admin settings or high-value features.
What Apps Can Now Do With These Signals
Together, these two signals let apps move from rigid, one-size-fits-all logins to smart, risk-based security. Here are the practical wins.
- Step-up checks at the right moment. If your session is old, the app can ask you to re-verify just for sensitive actions, instead of logging you out constantly.
- Stronger rules for risky actions. An app can require two-factor or a security key before allowing admin access or large transactions.
- Better fraud detection. Knowing how and when you logged in helps apps spot fake accounts and takeovers more accurately.
- Cleaner audit trails. Apps can log which method protected sensitive data, useful for security reviews.
This fits the wider shift toward smarter, AI-era defense we covered in fighting AI threats with AI, where context and speed matter more than rigid rules.
For Developers: How to Turn It On
If you build apps, the good news is you do not need to rebuild your login. The claims are ready for verified apps already using Sign in with Google with OpenID Connect. You just request them in your authentication call, like this.
https://accounts.google.com/o/oauth2/v2/auth?
|
The two claims then arrive in the ID token your backend receives, ready to use in your security logic. Full cross-platform examples are in the Google Identity developer documentation.
| Worth Knowing These signals are available for verified apps and work across Android, iOS, and the web. They follow the OpenID Connect standard, so they slot into existing auth flows rather than forcing a rewrite. |
What It Means for You as a User
You will not see these signals directly, but you will feel their effect. Apps that adopt them can keep you logged in for everyday use while adding a quick check exactly when it matters, like before a payment or a password change.
It is part of a broader move to make accounts safer without making them annoying. Pair it with good habits, like staying alert to AI-powered scams, and your online accounts get meaningfully harder to break into.
This is a small change with a big payoff. By sharing when and how you logged in, Sign in with Google lets apps replace rigid, all-or-nothing logins with smart, risk-based security. That kind stays out of your way until it is truly needed. For most people it means safer accounts with less hassle, and for developers it is an easy upgrade. You can read the full details in Google’s announcement.
Frequently Asked Questions
What Changed in Sign in with Google
Google added two new session-metadata signals, auth_time and amr, that tell an app when and how you last logged into your Google account, helping apps make smarter security decisions.
What Is the auth_time Claim
It is a timestamp showing the last time you actually authenticated with Google. It signals how fresh your login is, separate from when the app received its token.
What Is the amr Claim
It is the authentication methods reference. It tells the app how you signed in, such as a password, two-factor check, hardware key, or phone, signalling how strong your login was.
Does This Affect Regular Users
Indirectly, yes. You will not see the signals, but apps that use them can better protect your account from takeovers and fraud, often with a well-timed re-verification.
Which Platforms Support It
The new claims work across Android, iOS, and web apps for verified applications using Sign in with Google with OpenID Connect.
Do Developers Need to Rebuild Their Login
No. The claims follow the OpenID Connect standard, so developers simply request them in the existing auth flow without a major rewrite.
