JWT in Authorization vs Authentication — Decoding Implications

Decoding a JWT lets you inspect its contents, but decoding alone doesn't authenticate a user or authorize access. Understanding the difference between authentication and authorization—and where decoding fits in—is crucial for building secure applications.

Authentication vs Authorization: The Fundamental Difference

Authentication (AuthN): "Who are you?"

Authentication establishes the identity of a user or system. It answers: "Is this person/system who they claim to be?"

What authentication requires:

• ✅ Signature verification - Token must be signed by trusted issuer
• ✅ Claim validation - iss, aud, exp, nbf must be valid
• ✅ Key validation - Signature verified with correct secret/key
• ✅ Algorithm validation - Algorithm matches expected

What authentication does NOT require:

• ❌ Just decoding the token
• ❌ Reading the payload
• ❌ Checking if claims "look right"

Example:

// Authentication flow
function authenticate(token) {
  // 1. Decode to inspect (for debugging)
  const decoded = jwt.decode(token);
  console.log('Decoded token:', decoded);
  
  // 2. VERIFY signature (this is authentication)
  const verified = jwt.verify(token, secret, {
    issuer: 'https://auth.example.com',
    audience: 'my-api',
    algorithms: ['HS256']
  });
  
  // 3. Now we know: user is authenticated
  return verified;
}

Authorization (AuthZ): "What can you do?"

Authorization determines what actions a user can perform after authentication. It answers: "Does this authenticated user have permission to do X?"

What authorization uses:

• ✅ Roles - admin, user, moderator
• ✅ Scopes - read:users, write:posts, delete:comments
• ✅ Permissions - Custom claims like permissions: ["create", "read"]
• ✅ Resource-based rules - ABAC (Attribute-Based Access Control)
• ✅ Tenant/org context - Multi-tenant isolation

Example:

// Authorization flow (after authentication)
function authorize(decodedToken, action, resource) {
  // User is already authenticated at this point
  
  // Check roles
  if (decodedToken.roles && decodedToken.roles.includes('admin')) {
    return true;  // Admin can do anything
  }
  
  // Check scopes
  const requiredScope = `${action}:${resource}`;
  if (decodedToken.scope && decodedToken.scope.includes(requiredScope)) {
    return true;
  }
  
  // Check custom permissions
  if (decodedToken.permissions && decodedToken.permissions.includes(action)) {
    return true;
  }
  
  return false;  // Not authorized
}

The Relationship

Authentication → "Are you who you say you are?"
       ↓
Authorization → "Can you do what you're trying to do?"

Key point: Authorization happens AFTER authentication. You can't authorize someone who isn't authenticated.

Where Decoding Helps (And Where It Doesn't)

✅ Where Decoding Helps

1. Debugging and Development

Use case: Quickly inspect token contents during development

Example:

// Decode without verification (for debugging)
const decoded = jwt.decode(token, { complete: true });

console.log('Header:', decoded.header);
console.log('Payload:', decoded.payload);
console.log('Algorithm:', decoded.header.alg);
console.log('Key ID:', decoded.header.kid);
console.log('Subject:', decoded.payload.sub);
console.log('Expires:', new Date(decoded.payload.exp * 1000));

Why it helps:

• See token structure without verification
• Check claims before verification
• Debug why verification might fail
• Understand token contents

Use our JWT Encoder/Decoder for safe, client-side inspection.

2. Support and Troubleshooting

Use case: Help users understand why their tokens aren't working

Example:

function diagnoseToken(token) {
  try {
    const decoded = jwt.decode(token, { complete: true });
    
    // Check expiration
    const now = Math.floor(Date.now() / 1000);
    if (decoded.payload.exp && decoded.payload.exp < now) {
      return {
        valid: false,
        reason: 'Token expired',
        expiredAt: new Date(decoded.payload.exp * 1000)
      };
    }
    
    // Check issuer
    if (decoded.payload.iss !== 'https://auth.example.com') {
      return {
        valid: false,
        reason: 'Wrong issuer',
        issuer: decoded.payload.iss
      };
    }
    
    // Check audience
    if (!decoded.payload.aud || !decoded.payload.aud.includes('my-api')) {
      return {
        valid: false,
        reason: 'Wrong audience',
        audience: decoded.payload.aud
      };
    }
    
    return { valid: true, decoded };
  } catch (error) {
    return { valid: false, reason: 'Invalid token format', error: error.message };
  }
}

3. Logging (Without Storing Tokens)

Use case: Add context to logs without storing sensitive tokens

Example:

function logRequest(token, request) {
  // Decode to extract safe information
  const decoded = jwt.decode(token);
  
  // Log safe claims (not the full token)
  logger.info('Request received', {
    userId: decoded.sub,
    issuer: decoded.iss,
    expiresAt: new Date(decoded.exp * 1000),
    // Don't log: full token, sensitive claims
  });
}

Why this is safe:

• Doesn't store tokens (security risk)
• Provides debugging context
• Complies with privacy regulations

❌ Where Decoding Misleads

Mistake 1: "Payload looks fine, so allow access"

Wrong approach:

// BAD - Only decoding, no verification
function checkAccess(token) {
  const decoded = jwt.decode(token);
  
  if (decoded.roles && decoded.roles.includes('admin')) {
    return true;  // DANGEROUS!
  }
  
  return false;
}

Why it's dangerous:

• Anyone can create a fake token
• No signature verification
• Attacker can set roles: ["admin"]
• Complete security bypass

Correct approach:

// GOOD - Verify first, then check roles
function checkAccess(token) {
  // 1. VERIFY signature (authentication)
  const verified = jwt.verify(token, secret, {
    issuer: 'https://auth.example.com',
    algorithms: ['HS256']
  });
  
  // 2. Check roles (authorization)
  if (verified.roles && verified.roles.includes('admin')) {
    return true;
  }
  
  return false;
}

Mistake 2: "Algorithm says HS256, use any secret"

Wrong approach:

// BAD - Uses algorithm from token
function verifyToken(token) {
  const decoded = jwt.decode(token);
  const algorithm = decoded.header.alg;
  
  // Uses whatever algorithm token says
  return jwt.verify(token, 'some-secret', {
    algorithms: [algorithm]  // DANGEROUS!
  });
}

Why it's dangerous:

• Algorithm confusion attacks
• Attacker can set alg: "none" to bypass verification
• Could accept wrong algorithm

Correct approach:

// GOOD - Pin allowed algorithms
function verifyToken(token) {
  // Pin algorithms - don't trust token
  return jwt.verify(token, secret, {
    algorithms: ['HS256'],  // Only HS256 allowed
    issuer: 'https://auth.example.com'
  });
}

Mistake 3: "Issuer/audience nearly match, close enough"

Wrong approach:

// BAD - Fuzzy matching
function verifyToken(token) {
  const decoded = jwt.decode(token);
  
  // Fuzzy matching - DANGEROUS!
  if (decoded.iss.includes('example.com')) {
    return decoded;  // Wrong!
  }
  
  return null;
}

Why it's dangerous:

• Allows tokens from evil-example.com
• Allows tokens from example.com.evil.com
• Security vulnerability

Correct approach:

// GOOD - Exact matching
function verifyToken(token) {
  return jwt.verify(token, secret, {
    issuer: 'https://auth.example.com',  // Exact match
    audience: 'my-api',                   // Exact match
    algorithms: ['HS256']
  });
}

The Complete Secure Flow

Step-by-Step Implementation

1. Decode to Inspect (Optional, for Debugging)

// Decode without verification (safe, read-only)
const decoded = jwt.decode(token, { complete: true });

console.log('Token structure:', {
  algorithm: decoded.header.alg,
  keyId: decoded.header.kid,
  subject: decoded.payload.sub,
  issuer: decoded.payload.iss,
  audience: decoded.payload.aud,
  expiresAt: new Date(decoded.payload.exp * 1000)
});

2. Verify Signature (Authentication)

// VERIFY signature - this is authentication
let verified;

try {
  verified = jwt.verify(token, secret, {
    issuer: 'https://auth.example.com',  // Exact match
    audience: 'my-api',                   // Exact match
    algorithms: ['HS256'],                // Pin algorithms
    clockTolerance: 60                    // 60s clock skew tolerance
  });
} catch (error) {
  if (error.name === 'TokenExpiredError') {
    throw new Error('Token expired');
  }
  if (error.name === 'JsonWebTokenError') {
    throw new Error('Invalid token');
  }
  throw error;
}

// Now user is authenticated

3. Enforce Claim Checks

// Additional claim validation
function validateClaims(verified) {
  // Check required claims exist
  if (!verified.sub) {
    throw new Error('Missing subject claim');
  }
  
  // Check time claims
  const now = Math.floor(Date.now() / 1000);
  if (verified.exp && verified.exp < now) {
    throw new Error('Token expired');
  }
  if (verified.nbf && verified.nbf > now) {
    throw new Error('Token not yet valid');
  }
  
  // Check custom claims
  if (!verified.tenant) {
    throw new Error('Missing tenant claim');
  }
  
  return verified;
}

const validated = validateClaims(verified);

4. Authorize Based on Roles/Scopes

// Authorization - what can user do?
function authorize(validated, action, resource) {
  // Check roles
  if (validated.roles && validated.roles.includes('admin')) {
    return true;  // Admin can do anything
  }
  
  // Check scopes
  const requiredScope = `${action}:${resource}`;
  const scopes = validated.scope ? validated.scope.split(' ') : [];
  
  if (scopes.includes(requiredScope)) {
    return true;
  }
  
  // Check custom permissions
  if (validated.permissions && validated.permissions.includes(action)) {
    return true;
  }
  
  return false;  // Not authorized
}

// Use authorization
if (!authorize(validated, 'write', 'posts')) {
  throw new Error('Insufficient permissions');
}

Complete Example

async function authenticateAndAuthorize(token, action, resource) {
  // Step 1: Decode (optional, for debugging)
  const decoded = jwt.decode(token, { complete: true });
  console.log('Inspecting token:', {
    alg: decoded.header.alg,
    kid: decoded.header.kid,
    sub: decoded.payload.sub
  });
  
  // Step 2: Authenticate (verify signature)
  let verified;
  try {
    verified = jwt.verify(token, secret, {
      issuer: 'https://auth.example.com',
      audience: 'my-api',
      algorithms: ['HS256'],
      clockTolerance: 60
    });
  } catch (error) {
    throw new Error(`Authentication failed: ${error.message}`);
  }
  
  // Step 3: Validate claims
  if (!verified.sub || !verified.tenant) {
    throw new Error('Missing required claims');
  }
  
  // Step 4: Authorize
  if (!authorize(verified, action, resource)) {
    throw new Error(`Not authorized to ${action} ${resource}`);
  }
  
  return verified;
}

// Usage
try {
  const user = await authenticateAndAuthorize(token, 'write', 'posts');
  // User is authenticated AND authorized
  await createPost(user.sub, postData);
} catch (error) {
  if (error.message.includes('Authentication')) {
    return { status: 401, error: 'Unauthenticated' };
  }
  if (error.message.includes('authorized')) {
    return { status: 403, error: 'Forbidden' };
  }
  return { status: 500, error: 'Internal error' };
}

Common Patterns and Anti-Patterns

Pattern 1: Middleware-Based Authentication

Express.js example:

// Authentication middleware
function authenticateToken(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return res.status(401).json({ error: 'No token provided' });
  }
  
  try {
    // Verify signature
    const verified = jwt.verify(token, secret, {
      issuer: 'https://auth.example.com',
      algorithms: ['HS256']
    });
    
    // Attach user to request
    req.user = verified;
    next();
  } catch (error) {
    return res.status(401).json({ error: 'Invalid token' });
  }
}

// Authorization middleware
function authorize(...allowedRoles) {
  return (req, res, next) => {
    if (!req.user) {
      return res.status(401).json({ error: 'Not authenticated' });
    }
    
    if (!req.user.roles || !req.user.roles.some(role => allowedRoles.includes(role))) {
      return res.status(403).json({ error: 'Forbidden' });
    }
    
    next();
  };
}

// Usage
app.get('/admin/users', authenticateToken, authorize('admin'), getUsers);

Pattern 2: Resource-Based Authorization

ABAC (Attribute-Based Access Control):

function authorizeResource(user, action, resource) {
  // Check if user owns resource
  if (action === 'read' && resource.ownerId === user.sub) {
    return true;
  }
  
  // Check if user is in same organization
  if (resource.orgId && user.orgId === resource.orgId) {
    if (['read', 'update'].includes(action)) {
      return true;
    }
  }
  
  // Check roles
  if (user.roles && user.roles.includes('admin')) {
    return true;
  }
  
  return false;
}

Anti-Pattern: Skipping Verification

Never do this:

// BAD - No verification
function getUserId(token) {
  const decoded = jwt.decode(token);
  return decoded.sub;  // Anyone can fake this!
}

Always verify:

// GOOD - Verify first
function getUserId(token) {
  const verified = jwt.verify(token, secret, {
    algorithms: ['HS256']
  });
  return verified.sub;  // Trusted after verification
}

Implementation Best Practices

1. Pin Allowed Algorithms

Why: Prevents algorithm confusion attacks

// GOOD
jwt.verify(token, secret, {
  algorithms: ['HS256']  // Only HS256
});

// BAD
jwt.verify(token, secret, {
  algorithms: ['HS256', 'RS256', 'none']  // Dangerous!
});

2. Maintain Clock Tolerance

Why: Handles small time differences between systems

jwt.verify(token, secret, {
  clockTolerance: 60  // 60 seconds tolerance
});

3. Rotate Refresh Tokens

Why: Limits exposure if tokens are compromised

// Short-lived access tokens (15 minutes)
const accessToken = jwt.sign(payload, secret, {
  expiresIn: '15m'
});

// Longer-lived refresh tokens (7 days)
const refreshToken = jwt.sign({ sub: payload.sub }, secret, {
  expiresIn: '7d'
});

4. Validate All Required Claims

Why: Ensures tokens have necessary information

function validateClaims(verified) {
  const required = ['sub', 'iss', 'aud', 'exp'];
  
  for (const claim of required) {
    if (!verified[claim]) {
      throw new Error(`Missing required claim: ${claim}`);
    }
  }
  
  return verified;
}

5. Use Secure Token Storage

Why: Prevents token theft

Client-side:

• ✅ HTTP-only cookies (best)
• ✅ Memory storage (good)
• ❌ localStorage (vulnerable to XSS)
• ❌ sessionStorage (vulnerable to XSS)

Server-side:

• ✅ Secure session storage
• ✅ Encrypted database
• ❌ Plain text storage

Real-World Scenarios

Scenario 1: API Gateway Authentication

// API Gateway authenticates requests
async function handleRequest(req) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return { status: 401, error: 'No token' };
  }
  
  try {
    // Authenticate
    const verified = await verifyToken(token);
    
    // Authorize based on path
    if (req.path.startsWith('/admin') && !verified.roles?.includes('admin')) {
      return { status: 403, error: 'Forbidden' };
    }
    
    // Attach user context
    req.user = verified;
    return { status: 200, user: verified };
  } catch (error) {
    return { status: 401, error: 'Invalid token' };
  }
}

Scenario 2: Multi-Tenant Authorization

// Ensure user can only access their tenant's data
function authorizeTenant(user, resource) {
  // User must be authenticated (already verified)
  if (!user.tenant) {
    throw new Error('User missing tenant claim');
  }
  
  // Resource must belong to user's tenant
  if (resource.tenantId !== user.tenant) {
    throw new Error('Tenant mismatch');
  }
  
  return true;
}

Summary: Decoding vs Verification

Key takeaways:

1. Decoding is read-only - Use for debugging, never for security
2. Verification is authentication - Always verify before trusting token
3. Authorization comes after - Check permissions after authentication
4. Never skip steps - Decode → Verify → Authorize

Next Steps

1. Use our JWT Encoder/Decoder to safely inspect tokens
2. Read Don't Trust Decoded JWTs for security warnings
3. Learn How to Decode JWTs Safely for best practices
4. Understand JWT Tokens Explained for fundamentals