DEV Community

Cover image for Why Auth0 email_verified Was Missing from My Access Token (And How to Fix It)
Anand Rathnas
Anand Rathnas

Posted on

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

#auth0 #jwt #security #authentication

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;
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

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);
};
Enter fullscreen mode Exit fullscreen mode

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",
  ...
}
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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);
    }
  }
};
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)