What happens when your app can’t trust how a user logged in?

What happens when your app can’t trust how a user logged in? If you don’t know when someone authenticated, or how strongly they proved their identity, you’re leaving yourself open. I’ve seen enough production systems buckle under pressure to know that leaving things to chance rarely ends well.

Google’s been working on tightening this up for “Sign in with Google,” bringing in new OIDC claims: auth_time and amr. For us developers, these aren’t just extra bits of data; they’re critical signals for building systems that can genuinely hold up.

The Quality of a Login Session

Think about the security of a building. It’s not just about locking the front door. You want to know if someone entered with a standard key, a biometric scan, or if the alarm was triggered before they even got in. And crucially, how long ago did they enter? An hour ago? A week ago? The context changes everything.

Until now, with federated identity services like “Sign in with Google,” we primarily got a “yes, they’re logged in” signal. That’s like knowing the door is closed, but not knowing if it’s a weak latch or a bolted steel plate. For a lot of applications, that’s enough. But for anything dealing with sensitive user data, financial transactions, or critical business processes, that level of ambiguity is a liability.

It’s where account takeover and fraud find their cracks. An attacker compromises an old, lingering session, and without knowing how fresh that login is, or if it was established with a robust method like Multi-Factor Authentication (MFA), your system treats it as valid. It’s like letting someone into a restricted area just because they have a valid ID from five years ago, without checking their face against it today.

New Tools for Deeper Trust: auth_time and amr

This is where the new OpenID Connect (OIDC) standard claims come in.

• First, there’s auth_time. This timestamp tells you the precise moment a user last actively authenticated with Google. It’s not just when their session token was issued, but when they actually proved their identity, perhaps by entering a password or using a biometric prompt. For us, it’s like having a digital service record for a vehicle – you know exactly when it was last properly checked over. If auth_time is too far in the past, even if the session is technically valid, your application knows it needs to be cautious.
• Then there’s amr (Authentication Methods Reference). This is a game-changer. It provides an array of strings that tell you how the user authenticated. Did they just use a password? Or did they use MFA? Was it a hardware key, like a FIDO device? Knowing the amr is like understanding the quality of the timber in a joinery project. A pine joint will hold differently to a kiaat dovetail. A login secured with a hardware key is inherently more robust than one secured with just a password, regardless of password strength.

Building Adaptive Defenses

With auth_time and amr, we can start building genuinely adaptive security policies. It’s not about a blanket “all users are equal” approach; it’s about dynamic risk assessment based on real-time signals.

Imagine a user accessing their profile. If their auth_time is recent and their amr shows MFA, you can grant them full access. No problem. But what if they try to change their banking details, and auth_time indicates their last active login was three weeks ago? Or perhaps their amr only shows a basic password? Now your system can react intelligently. This is where step-up authentication comes in – a system can prompt them for a re-authentication, or an additional MFA challenge, specifically for that sensitive action. It’s like having a gate that opens wider or narrower depending on the cargo and the driver’s credentials.

This is core to the OWASP principles I use when hardening systems. It moves us beyond static security configurations to a posture that constantly assesses and adapts. For anyone managing access control for critical applications, whether it’s a Drupal Commerce site with Stripe integrations or an internal Argon application, this is invaluable.

Practical Application for Developers

For developers, integrating these claims means you need to adjust your identity provider configurations and your application’s session management logic. You’ll parse these claims from the ID token provided by Google and use them to inform your authorisation decisions. It’s not just about displaying this data; it’s about embedding it into your backend logic to drive granular policy enforcement.

It’s about building with the understanding that not all authentication events are created equal. You’re building systems to last, systems that can adapt to changing threat landscapes. Just as you’d spec different grades of concrete for different load-bearing walls, you now have the tools to spec different levels of access based on the integrity of the login.

If you’re running any application relying on “Sign in with Google,” especially those with sensitive user data or actions, start looking at these claims. Review your access control policies. Figure out where you can implement step-up authentication or tighter session controls based on auth_time and amr. Don’t wait for a breach to discover the weak points in your authentication structure. Make sure your foundations are solid, not just look-and-feel good.