Week 19: Advanced Auth — OAuth2 Provider, API Keys & Multi-Tenancy

1. Running Your Own OAuth2/OIDC Provider

Week 6 built JWT issuance directly into your own API — your Express app validated credentials and signed its own tokens. Passport.js consumed external providers for social login. Some platforms need a third role: issuing tokens to a genuinely separate first-party mobile app, a partner's third-party integration, or an internal service — all authenticating against a real authorization code grant, the flow a browser-based login actually uses. node-oidc-provider implements the full OAuth2/OIDC provider role on top of an HTTP framework.

import Provider from "oidc-provider";

const oidc = new Provider("https://auth.acme.com", {
  clients: [
    {
      client_id: "acme-web-app",
      client_secret: process.env.WEB_APP_SECRET,
      redirect_uris: ["https://app.acme.com/callback"],
      grant_types: ["authorization_code", "refresh_token"],
      scope: "openid tasks:read tasks:write",
    },
  ],
  findAccount: async (ctx, id) => {
    const user = await prisma.user.findUnique({ where: { id } });
    return user
      ? { accountId: id, claims: async () => ({ sub: id, email: user.email }) }
      : undefined;
  },
});

app.use("/oidc", oidc.callback());

This is the same flow a browser-based login always uses, except your server is now the one issuing the authorization code and, ultimately, the access token, rather than delegating to Google or GitHub the way Week 6's Passport.js setup did. Custom, application-specific scopes like tasks:read and tasks:write become possible in a way an external provider's fixed scope set never allowed, letting you express your own API's actual permission boundaries directly in the tokens you issue.

2. API Keys & the Client Credentials Grant

Every grant type in Week 6 and Section 1 assumes a human is present to log in. A scheduled BullMQ job, a webhook receiver, or a server calling your API with no user in the loop needs a different pattern entirely — there's no browser to redirect and no password to prompt for.

The client credentials grant is OAuth2's answer: the calling service authenticates directly with its own client ID and secret, no user or redirect involved, and receives an access token scoped to what that service is allowed to do.

curl -X POST https://auth.acme.com/oidc/token \
  -u reporting-service:reporting-secret \
  -d "grant_type=client_credentials&scope=reports:generate"

# {"access_token": "eyJ...", "token_type": "Bearer", "expires_in": 3600}

For simpler internal or partner integrations where full OAuth2 is more machinery than the situation needs, a plain API key — a long random string, checked against a hashed value stored server-side, tied to an owning account and a set of permissions — is a legitimate, lighter-weight alternative:

async function apiKeyAuth(req: Request, res: Response, next: NextFunction) {
  const rawKey = req.header("X-API-Key");
  if (!rawKey) return res.status(401).json({ error: "Missing API key" });

  const key = await prisma.apiKey.findUnique({ where: { hashedKey: hashKey(rawKey) } });
  if (!key || !key.isActive) {
    return res.status(401).json({ error: "Invalid or inactive API key" });
  }

  req.apiKeyOwner = key.ownerId;
  next();
}

The key's hash is what's stored and compared, exactly like Week 6's password hashing with bcrypt — a leaked database dump shouldn't hand out usable API keys any more than it should hand out usable passwords.

3. Multi-Tenant Data Isolation

Once a single deployment serves multiple customers ("tenants") from shared infrastructure, the single most important property the application has to guarantee is that Tenant A's request can never return Tenant B's data — not "usually doesn't," but structurally cannot. Three common strategies, in increasing order of isolation and operational cost:

• Shared schema, discriminator column — every table gets a tenantId column, and every query filters by it. Cheapest to run and simplest to add a tenant to, but the isolation is only as strong as every single query remembering to filter correctly.
• Schema-per-tenant — one PostgreSQL schema per tenant, same database instance. Stronger isolation (a missing filter can't cross schemas as easily), but migrations and connection routing get meaningfully more complex as tenant count grows.
• Database-per-tenant — full physical isolation. Strongest guarantee, but the most operationally expensive: connection pooling, migrations, and backups now all multiply by tenant count.

For the common shared-schema approach, Prisma's client extensions can enforce the tenant boundary at the query layer, rather than trusting every repository function to remember the where: { tenantId } clause:

function forTenant(tenantId: string) {
  return prisma.$extends({
    query: {
      task: {
        async findMany({ args, query }) {
          args.where = { ...args.where, tenantId };
          return query(args);
        },
        async findUnique({ args, query }) {
          args.where = { ...args.where, tenantId };
          return query(args);
        },
        // repeat for update, delete, etc.
      },
    },
  });
}

// in middleware, attached once per request from the authenticated principal
app.use((req, res, next) => {
  req.db = forTenant(req.auth.tenantId);
  next();
});

With req.db built this way, every query issued through it for the rest of the request automatically has the tenant condition applied — a developer writing a new repository function later can't accidentally forget the filter, because it isn't something they write per query at all; they just use req.db instead of the raw prisma client.

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.