hectoday
DocsCoursesChangelog GitHub
DocsCoursesChangelog GitHub

Access Required

Enter your access code to view courses.

Invalid code

← All courses Production Auth Patterns with @hectoday/http

Before They Start

  • Why Production Auth Is Different
  • Project Setup

Email Verification

  • Why Verify Emails
  • Building Email Verification
  • Restricting Unverified Accounts

Session Management

  • Tracking Sessions Across Devices
  • Listing and Revoking Sessions
  • Session Security

Step-Up Authentication

  • What Is Step-Up Auth
  • Building Step-Up Auth
  • Applying Step-Up to Sensitive Routes

Account Deletion

  • The Right to Be Forgotten
  • Building Account Deletion
  • Data Cleanup

SAML and Enterprise SSO

  • What Is SAML
  • Building a SAML Service Provider
  • Just-in-Time Provisioning

Putting It All Together

  • Production Auth Checklist
  • Capstone: Production-Ready Auth

What Is Step-Up Auth

Being logged in is not enough

A user logged in 23 hours ago. Their session is still valid. They click “Delete my account.”

Should the server process this immediately? The user is authenticated — they have a valid session. But 23 hours is a long time. What if someone else is using their laptop? What if the session was hijacked?

Step-up authentication requires the user to re-prove their identity before sensitive actions. Even though they are logged in, they must enter their password, TOTP code, or use a passkey again. The re-authentication must be recent — typically within the last 5 minutes.

What actions need step-up

Not every action needs re-authentication. Listing notes does not. Creating a note does not. But these actions should require step-up:

Changing the email address. A changed email means password reset emails go to a new inbox. If an attacker changes the email, they control account recovery.

Changing the password. An attacker who changes the password locks out the real user.

Disabling 2FA. An attacker who disables 2FA removes the second factor protection.

Deleting the account. Irreversible. Should require recent proof of identity.

Creating or revoking API keys. API keys grant long-lived access. Creating one from a stale session is risky.

Viewing sensitive data. Billing information, personal documents, security settings.

The common pattern: actions that change security settings or are irreversible.

How it works

User clicks "Change email"
│
├─ Session is valid? → Yes
├─ Recent auth within 5 minutes? → No (logged in 23 hours ago)
│
└─ Show re-authentication prompt
    ├─ User enters password → Verified ✓
    ├─ Or enters TOTP code → Verified ✓
    └─ Or uses passkey → Verified ✓

    → Record the re-authentication timestamp
    → Proceed with email change

The re-authentication timestamp is stored on the session. For the next 5 minutes, the user can perform other sensitive actions without re-authenticating.

GitHub’s model

GitHub uses this pattern extensively. Try changing your email or creating a personal access token — GitHub asks for your password even though you are logged in. The prompt is called “Confirm access” or “Sudo mode.”

This is the model we build in the next two lessons.

Exercises

Exercise 1: Think about the apps you use. Which actions require re-authentication? Which should but do not?

Exercise 2: List the routes in your app. Which ones should require step-up authentication?

Why is step-up authentication needed for changing an email address?

← Session Security Building Step-Up Auth →

© 2026 hectoday. All rights reserved.