Skip to main content
Identity Authority
Category: Authentication Factors

Reauthentication

Also known as: Re-authentication, Forced reauthentication
Simply put

Reauthentication is the process of asking a user (or, in some contexts, a workload or automated agent) to prove their identity again after they have already logged in. It is typically triggered during a long session to confirm the person is still present, or before a sensitive action is performed.

Formal definition

Reauthentication is the act of re-verifying a previously authenticated subject's identity during an established session, distinct from the initial identification and authentication event. Per NIST guidance, it confirms a subscriber's continued presence and intent to remain authenticated during an extended usage session. In most deployments it is invoked by policy conditions, such as session duration limits, elevated-risk operations, or step-up requirements before a sensitive action, and the specific triggers and enforcement mechanism vary by vendor and configuration (for example, IBM Security Access Manager uses a protected object policy with a 'reauth' extended attribute, while other platforms configure it through sign-on or authentication policies). Reauthentication concerns re-verifying identity (authentication) and does not by itself determine what the subject may do (authorization); the factors used and whether reauthentication requires the same or a stronger factor depend on the deployment.

Why it matters

Reauthentication addresses a fundamental gap in session-based access: an initial login establishes identity at a single point in time, but sessions can persist for hours or across sensitive operations, during which the originally authenticated subject may no longer be present. By re-verifying identity during an extended session or immediately before a high-value action, reauthentication confirms the subscriber's continued presence and intent to remain authenticated, reducing the window in which a hijacked, abandoned, or shared session can be abused.

Because reauthentication is typically invoked by policy conditions, session duration limits, elevated-risk operations, or step-up requirements before sensitive actions, it lets organizations apply stronger identity assurance selectively rather than forcing constant friction on every request. This makes it a practical control for balancing usability against the risk profile of specific operations. It is important to note that reauthentication re-verifies identity (authentication) and does not by itself determine what the subject is permitted to do; authorization decisions remain a separate concern.

The specific triggers and enforcement mechanisms vary meaningfully by vendor and configuration, so consistency depends on deliberate policy design. Whether reauthentication requires the same factor used at login or a stronger one, and how session state is evaluated, are deployment-dependent choices that directly shape the security value the control provides.

Who it's relevant to

IAM Engineers and Security Architects
They define when and how reauthentication is triggered, by session duration, risk level, or sensitive-action policies, and select enforcement mechanisms appropriate to each platform, such as an IBM Security Access Manager protected object policy or an Okta sign-on policy. They also decide whether reauthentication should require the same or a stronger factor for a given operation.
System Administrators
They operationalize reauthentication policies, tuning session limits and challenge conditions to balance security against user friction, and troubleshoot configuration differences across vendors where triggers and enforcement mechanisms vary.
Compliance Officers and Auditors
They assess whether reauthentication is applied consistently to confirm continued subscriber presence during extended sessions and before sensitive actions, and verify that policy design aligns with relevant guidance such as NIST's definition of confirming continued presence and intent to remain authenticated.

Inside Reauthentication

Session freshness verification
Reauthentication confirms that the principal currently controlling a session is still the legitimately authenticated user, by requiring them to re-present credentials rather than relying on an existing session or token.
Distinction from initial authentication
Reauthentication is a repeat of the authentication step (verifying who the principal is) that occurs after an initial authentication has already succeeded; it does not by itself establish authorization, which remains a separate step.
Step-up relationship
Reauthentication is often invoked as part of step-up authentication, where a higher assurance level or an additional factor is required before access to a sensitive operation is granted. The two overlap but are not identical: step-up may add factors, while reauthentication may simply re-verify with the same factor.
Trigger conditions
Depending on configuration, reauthentication can be triggered by elapsed time since last authentication, session age, sensitivity of the requested action, changes in risk signals, or explicit policy requirements.
Protocol-level controls
In OIDC Core, a relying party can request fresh authentication using parameters such as prompt=login or max_age, and can evaluate the returned auth_time claim; in SAML 2.0, ForceAuthn can request that the identity provider reauthenticate the user. Exact behavior varies by identity provider and profile.
Factor scope
Reauthentication may require re-presenting one or more factors across the possession, knowledge, and inherence categories, and whether it requires all original factors or a subset depends on the deployment and policy.

Common questions

Answers to the questions practitioners most commonly ask about Reauthentication.

Is reauthentication the same as step-up authentication?
No, though they are related and often confused. Reauthentication asks a principal to prove the same identity again, typically to confirm the session is still controlled by the original user, and it does not necessarily increase assurance. Step-up authentication specifically raises the assurance level by requiring an additional or stronger factor, usually to access a more sensitive resource. Reauthentication can be performed at the same factor strength as the original login, whereas step-up implies a deliberate increase in the number or strength of factors. In many deployments a reauthentication event is also configured as a step-up, but the two concepts remain distinct.
Does reauthentication reauthorize the user or re-check their permissions?
Not inherently. Reauthentication re-verifies who the principal is; it does not by itself re-evaluate what the principal may do. Authorization decisions are a separate step, and depending on configuration they may or may not be refreshed at the same time. Some deployments do trigger a fresh authorization evaluation, updated claims, or new token issuance following reauthentication, but that is a design choice layered on top of reauthentication rather than an intrinsic property of it. Treating a successful reauthentication as proof of current entitlements conflates authentication with authorization.
How is reauthentication typically triggered in an OpenID Connect flow?
In OpenID Connect, a relying party can request reauthentication by sending the prompt=login parameter or by setting a max_age value on the authentication request. When max_age is specified, the OpenID Provider is expected to reauthenticate the end user if the elapsed time since the last authentication exceeds that value, and the resulting ID token typically conveys the auth_time claim so the relying party can verify when authentication actually occurred. The exact enforcement behavior can vary by provider and configuration, so relying parties generally validate auth_time rather than assuming the prompt was honored.
When should reauthentication be required rather than relying on an existing session?
Common practice is to require reauthentication before high-impact actions such as changing credentials, modifying MFA settings, initiating sensitive transactions, or granting administrative consent, even when a valid session already exists. The rationale is to confirm the person present is still the legitimate account holder and to reduce risk from session hijacking or an unattended session. The specific triggers depend on risk tolerance and policy, and many deployments combine event-based triggers with time-based ones such as a maximum authentication age for sensitive contexts.
How does reauthentication interact with access tokens and refresh tokens?
Reauthentication concerns proving the user's identity again and is distinct from token refresh. Using a refresh token to obtain a new access token does not typically constitute reauthentication, because in most flows the refresh exchange does not involve the user re-proving their identity. If a policy requires a fresh authentication event, it generally cannot be satisfied silently by a refresh token alone and instead requires an interactive prompt back to the authorization server or identity provider. Whether a given deployment forces interactive reauthentication versus allowing silent renewal depends on configuration, session policy, and the profile in use.
How can a relying party verify that reauthentication actually happened?
In OpenID Connect deployments, the relying party can inspect the auth_time claim in the ID token to determine when the user last authenticated and compare it against the requested max_age or the sensitivity of the requested action. Because a provider's handling of prompt and max_age can vary, relying parties should not assume the request was honored and should validate the returned auth_time rather than trusting the request parameters alone. The mechanics differ across protocols and profiles, so the available signals for confirming a fresh authentication event depend on the standard and provider in use.

Common misconceptions

Reauthentication re-checks what the user is allowed to do.
Reauthentication re-verifies identity (the authentication step). Determining what the principal may do is authorization, a separate step; a fresh reauthentication does not by itself re-evaluate or expand access rights.
Reauthentication and step-up authentication are the same thing.
They overlap but differ. Step-up authentication typically raises the assurance level, often by adding a stronger or additional factor, while reauthentication re-verifies the current session's identity, which may use the same factor(s). A given flow may do one, the other, or both depending on configuration.
Simply having a valid, signed token means reauthentication is unnecessary.
A valid token proves prior authentication occurred but does not guarantee session freshness. Reauthentication exists precisely to confirm the user is still present and legitimate, which is why OIDC provides max_age and auth_time and SAML provides ForceAuthn. Note also that a token being signed is not the same as it being encrypted.

Best practices

Require reauthentication before high-risk or sensitive operations (such as changing credentials, altering MFA settings, or approving high-value transactions), rather than relying solely on an existing session.
Use standard protocol mechanisms where available, such as OIDC max_age and prompt=login with evaluation of the auth_time claim, or SAML 2.0 ForceAuthn, and validate the identity provider actually honors them in your deployment.
Define explicit, policy-driven triggers for reauthentication (session age, elapsed time, changed risk signals) instead of hardcoding fixed intervals, and document the assurance level each trigger requires.
Keep reauthentication (an authentication step) separate from authorization decisions in your architecture, so that re-verifying identity does not implicitly re-grant or expand access rights.
Decide deliberately whether a given flow needs plain reauthentication or step-up authentication with an additional or stronger factor, and record which factor categories (possession, knowledge, inherence) are required.
Test that reauthentication behavior is consistent across your identity providers, relying parties, and standard profiles, since exact enforcement varies by vendor and configuration.
Promotional banner for the Penetration Report Template Kit