A token claim that records when the user’s last real authentication occurred. It gives applications a machine-readable way to compare the age of the proof against a policy threshold before allowing a sensitive operation.
Expanded Definition
auth_time is an OpenID Connect token claim that records the last time a subject completed real authentication, not merely an application session refresh. In NHI and IAM workflows, it lets a policy engine compare the age of the original proof against a sensitivity threshold before approving a step-up action, token exchange, or privileged transaction. The distinction matters because a valid token can still be too old for a high-risk operation even when the session has not expired. Implementers often pair auth_time with max_age, reauthentication prompts, or conditional access logic so that downstream services can enforce “fresh proof” requirements consistently. Standards usage is still fairly mature in OpenID Connect, but operational interpretation varies across vendors and application stacks, especially when tokens are replayed through gateways or brokered across multiple services. For a broader identity-governance context, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0. The most common misapplication is treating auth_time as proof of ongoing trust, which occurs when teams assume an old login remains sufficient for later privileged actions.
Examples and Use Cases
Implementing auth_time rigorously often introduces more reauthentication friction, requiring organisations to weigh stronger step-up assurance against user and automation latency.
- A service portal requires a fresh auth_time before approving a production configuration change, preventing a stolen long-lived session from being used after the initial login window.
- An AI agent requests a sensitive tool action, and the control plane checks auth_time before issuing a short-lived delegated token, aligning with the access freshness expectations described in the Ultimate Guide to NHIs.
- A finance application accepts a signed-in user session but demands recent authentication for wire approvals, using auth_time rather than the login cookie alone as the trust signal.
- A zero trust gateway compares auth_time against policy and forces step-up authentication when the proof is older than the allowed threshold, consistent with NIST Cybersecurity Framework 2.0 principles.
- A delegated workflow for a non-human identity uses auth_time to decide whether the original human approval is still fresh enough to authorize a downstream API call.
Why It Matters in NHI Security
auth_time is important because NHI environments often rely on automation, token chaining, and delegated access, where a token may remain technically valid long after the original proof has become stale. That creates a gap between authentication and authorization freshness, especially for privileged operations, secret rotation, emergency access, and agentic tool use. NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which makes stale proof a governance issue rather than a user convenience issue. When auth_time is enforced well, teams can require reauthentication before sensitive actions and reduce the blast radius of token theft or session replay. When it is ignored, an attacker or over-privileged workflow can continue operating under old assurance levels even after context has changed. The Ultimate Guide to NHIs highlights how widespread NHI exposure compounds this risk, while the NIST Cybersecurity Framework 2.0 reinforces the need for continuous access control. Organisations typically encounter auth_time as a critical control only after a token reuse incident or privileged action audit reveals that old authentication was still being trusted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Fresh-auth checks reduce abuse of stale tokens in NHI workflows. |
| NIST CSF 2.0 | PR.AC-7 | Supports reauthentication and access revocation decisions based on assurance age. |
| NIST SP 800-63 | AAL | Relates to reauthentication freshness and assurance level maintenance. |
Require recent auth_time before privileged NHI actions and delegated token issuance.
Related resources from NHI Mgmt Group
- How should teams support multiple SAML or OIDC identity providers without rebuilding auth every time?
- What is Just-in-Time (JIT) access and why is it important for NHI security?
- When do NHI access reviews create more value than a one-time cleanup?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
