What I Learned Rebuilding an Entire Auth System from Scratch

When I inherited the Public Financial Management (PFM) project at EY, I quickly discovered that the authentication system was one of the biggest security risks. The previous team had implemented a custom authentication solution that had several critical flaws—and this was for a system handling government financial data.

Not ideal.

The Problem

The existing auth system had issues that would make any security professional cringe:

Outdated password hashing — Using an algorithm that was deprecated years ago

Predictable session tokens — Easy to guess and didn't expire properly

No rate limiting — Brute force attacks were trivially easy

Enumeration vulnerabilities — The forgot password flow leaked user information

When I ran a security scan, we had over 1,000 vulnerabilities. For a system that would handle millions of dollars in international aid disbursement, this was unacceptable.

Never roll your own authentication. Even experienced security teams make mistakes. Use battle-tested solutions like Auth0, Clerk, or at minimum, well-maintained libraries like Passport.js.

Why Auth0?

After evaluating several options—building a custom solution with Passport.js, implementing Keycloak, or using a managed service—we chose Auth0 for several reasons:

Enterprise-grade security — Handles brute force protection, anomaly detection, and secure token management out of the box

Compliance certifications — SOC 2 Type II certified, critical for government clients

Developer experience — Clean SDKs and excellent documentation

Flexibility — We needed custom claims for blockchain integration

The licensing cost was significant, but the alternative—building and maintaining a secure auth system ourselves—would have cost far more in engineering time and potential security incidents.

The Architecture Challenge

Here's where it got interesting. We weren't just replacing a basic auth system—we needed to integrate Auth0 with our existing blockchain-based user management. Every user had an associated blockchain address, and their permissions were stored on-chain.

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   React     │────▶│   Auth0     │────▶│  User API   │
│   Frontend  │     │             │     │  (Node.js)  │
└─────────────┘     └─────────────┘     └─────────────┘
                           │                    │
                           ▼                    ▼
                    ┌─────────────┐     ┌─────────────┐
                    │   Custom    │     │  Blockchain │
                    │   Actions   │────▶│   (Geth)    │
                    └─────────────┘     └─────────────┘

The flow needed to:

Authenticate the user through Auth0

Fetch their blockchain address from our database

Inject blockchain-related claims into the JWT

Return a token that both our API and blockchain nodes could validate

Implementation: Custom Auth0 Actions

Auth0 Actions let you run custom code at specific points in the authentication pipeline. We used the Post Login action to inject blockchain data into the JWT:

exports.onExecutePostLogin = async (event, api) => {
  const { user } = event;
  
  // Fetch user's blockchain address from our API
  const blockchainData = await fetch(
    ${process.env.API_URL}/users/${user.user_id}/blockchain,
    { 
      headers: { 
        Authorization: Bearer ${process.env.API_TOKEN} 
      } 
    }
  ).then(r => r.json());
  
  // Add custom claims to the ID token
  api.idToken.setCustomClaim('blockchain_address', blockchainData.address);
  api.idToken.setCustomClaim('organization_id', blockchainData.orgId);
  api.idToken.setCustomClaim('permissions', blockchainData.permissions);
  
  // Also add to access token for API authorization
  api.accessToken.setCustomClaim('blockchain_address', blockchainData.address);
  api.accessToken.setCustomClaim('permissions', blockchainData.permissions);
};

Keep custom claims minimal. JWTs are sent with every request, so large payloads impact performance. Only include data that's needed for authorization decisions.

Role-Based Access Control

Our RBAC system needed to map Auth0 roles to blockchain-based permissions. Government financial systems have complex permission structures—a Finance Officer can create transactions, but only a Director can approve ones over a certain amount.

interface UserPermissions {
  canCreateTransactions: boolean;
  canApproveTransactions: boolean;
  canViewReports: boolean;
  maxApprovalAmount: number;
  organizationScope: string[];
}
const mapRolesToPermissions = (roles: string[]): UserPermissions => {
  const basePermissions: UserPermissions = {
    canCreateTransactions: false,
    canApproveTransactions: false,
    canViewReports: false,
    maxApprovalAmount: 0,
    organizationScope: [],
  };
  
  for (const role of roles) {
    switch (role) {
      case 'finance-officer':
        basePermissions.canCreateTransactions = true;
        basePermissions.canViewReports = true;
        break;
      case 'director':
        basePermissions.canApproveTransactions = true;
        basePermissions.maxApprovalAmount = 100000;
        break;
      case 'minister':
        basePermissions.canApproveTransactions = true;
        basePermissions.maxApprovalAmount = Infinity;
        break;
    }
  }
  
  return basePermissions;
};

The key insight was that permissions lived in two places: Auth0 (for application access) and the blockchain (for transaction signing). We needed both to align.

The Migration Strategy

You can't just flip a switch when replacing authentication. We ran both systems in parallel for two weeks:

New auth system running but not enforced. All logins still used the old system, but we logged what the new system would have done.

10% of users migrated to the new system. Monitored for issues, login success rates, and support tickets.

Remaining 90% migrated. Old system kept running as fallback for one week.

Old auth system disabled. All traffic through Auth0.

Results

After the migration, the improvements were dramatic:

MetricBeforeAfter

Security vulnerabilities1,000+50 Login success rate~60%~99% Auth-related incidentsMonthlyZero in 6 months Password reset completion~40%~95%

The system successfully passed the Ministry's security audit, enabling the $1M+ project handover to the Government of Guinea-Bissau.

Lessons Learned

1. Don't build auth yourself

Unless you have a dedicated security team and compliance requirements that prevent using third-party services, use a proven solution. The cost of Auth0/Clerk/etc. is a fraction of building and maintaining secure auth.

2. Plan migrations carefully

Running systems in parallel catches issues before they affect all users. The extra infrastructure cost is worth it.

3. Custom claims are powerful but dangerous

They let you encode business logic in your tokens, but they also increase token size and can leak information. Be thoughtful about what you include.

4. Test edge cases obsessively

Password resets, account lockouts, token refresh flows, session expiration—these edge cases are where security vulnerabilities hide.

What's Next

I'm now applying these lessons to CROW, my automotive SaaS project. For an early-stage startup, Auth0 is overkill, so I'm implementing a simpler solution with NextAuth.js—but the principles remain the same: never roll your own crypto, validate everything, and assume breach.

---

Have questions about authentication architecture? Get in touch—I'm always happy to chat about security.