Why Auth0 email_verified Was Missing from My Access Token (And How to Fix It)

Spent an hour debugging why verified users were getting blocked. The culprit? Auth0 doesn't include email_verified in access tokens by default.

The Problem

My Spring Boot filter checks if users have verified their email:

Boolean emailVerified = jwt.getClaimAsBoolean("email_verified");

if (emailVerified == null || !emailVerified) {

    response.setStatus(HttpServletResponse.SC_FORBIDDEN);

    response.getWriter().write("{\"error\":\"Email not verified\"}");

    return;

}

Users who had verified their email in Auth0 Dashboard (showing "VERIFIED" badge) were still getting blocked. The logs showed:

User email not verified: sub=auth0|67c6a695657d0f4f7ac8736f

But... they ARE verified. What gives?

The Root Cause

Auth0 includes email_verified in the ID token but NOT in the access token by default.

When you decode your access token, you might see:

{

  "iss": "https://your-tenant.auth0.com/",

  "sub": "auth0|67c6a695657d0f4f7ac8736f",

  "aud": ["https://your-api/"],

  "iat": 1767421775,

  "exp": 1767508175,

  "scope": "openid profile email"

}

No email_verified. Even though you requested the email scope.

The Fix: Auth0 Action

Create a Post-Login Action to add the claim to your access token:

Auth0 Dashboard → Actions → Flows → Login → Add Action

exports.onExecutePostLogin = async (event, api) => {

  // Add email_verified to access token for API validation

  api.accessToken.setCustomClaim('email_verified', event.user.email_verified);

};

Deploy it, drag it into your Login flow.

Now your access token includes:

{

  "email_verified": true,

  "iss": "https://your-tenant.auth0.com/",

  "sub": "auth0|67c6a695657d0f4f7ac8736f",

  ...

}

Why Auth0 Does This

ID tokens are for the client (your frontend) to know who the user is.

Access tokens are for the API (your backend) to authorize requests.

Auth0's philosophy: access tokens should contain authorization info, not identity info. But in practice, your API often needs both.

Alternative: Fetch from Userinfo Endpoint

If you can't modify Auth0 Actions (or want a fallback), fetch from the userinfo endpoint:

// If email_verified not in JWT, fetch from Auth0

if (emailVerified == null) {

    String userinfoUrl = auth0Issuer + "userinfo";

    // GET with Bearer token

    // Parse response for email_verified

}

But this adds latency to every request. The Action approach is better.

OAuth Users Don't Need This Check

Plot twist: if you're using social login (Google, GitHub), the provider already verified the email. Auth0 sets email_verified: true automatically for OAuth users.

You could skip the check for non-database connections:

String subject = jwt.getSubject();

boolean isDatabaseConnection = subject != null && subject.startsWith("auth0|");



if (isDatabaseConnection) {

    // Only check email_verified for username/password users

}

But I prefer keeping it simple - just add the claim via Action and check for everyone. KISS.

The Complete Action

Here's my full Action that also handles resending verification emails:

exports.onExecutePostLogin = async (event, api) => {

  // Always include email_verified in access token

  api.accessToken.setCustomClaim('email_verified', event.user.email_verified);



  // Auto-resend verification email for unverified users (rate limited)

  if (!event.user.email_verified) {

    const lastSent = event.user.user_metadata?.verification_email_last_sent;

    const now = Date.now();

    const ONE_HOUR = 60 * 60 * 1000;



    if (!lastSent || (now - lastSent) > ONE_HOUR) {

      // Trigger verification email via Management API

      // ... (see Auth0 docs for Management API setup)



      api.user.setUserMetadata('verification_email_last_sent', now);

    }

  }

};

Lessons Learned

1. 
   ID token ≠ Access token - They serve different purposes and contain different claims


2. 
   Test with actual tokens - Decode your JWT at jwt.io to see what's really there


3. 
   Actions are powerful - You can add any claim you need to the access token


4. 
   Check Auth0 Dashboard carefully - Just because it shows "VERIFIED" doesn't mean the token has the claim

Ever been burned by missing JWT claims? What other claims do you add via Actions?

Building jo4.io - a URL shortener with analytics, bio pages, and white-labeling.