In the previous article we built a working OIDC Authorization Code Flow server. There was one shortcut worth updating before we could continue filling it smoothly: a hardcoded ISSUER constant.

const ISSUER = "http://localhost:3000";

Every place that constant is used is now locked to localhost:3000: the iss JWT claim, the discovery URL, the JWKS endpoint URL returned to clients, etc... Deploy to https://auth.example.com and you will have to change the code to match the new origin. Start the server on a random port and the discovery document won't work at all.

You could use an environment variable to set the issuer at startup, but that adds complexity and is still error-prone. If you forget to set the variable or set it incorrectly, your server will be broken until you fix the configuration and restart it.

The fix is to derive the issuer from the incoming HTTP request at runtime instead of hard-coding it at startup. It's easy to do, trust me.

Step 1: Import getOriginFromRequest

@saurbit/oauth2 ships a small helper that extracts the scheme + host from a Request object. Add it to the existing import block:

import {
  AccessDeniedError,
  StrategyInsufficientScopeError,
  StrategyInternalError,
  UnauthorizedClientError,
  UnsupportedGrantTypeError,
  getOriginFromRequest, // add this
} from "@saurbit/oauth2";

Step 2: Remove the ISSUER constant and loosen CLIENT.redirectUris

Delete the ISSUER constant entirely. While you're there, give CLIENT an explicit type and change redirectUris to an empty array. You'll handle the Scalar redirect URI dynamically in the next step:

// Before
const ISSUER = "http://localhost:3000";

const CLIENT = {
  id: "example-client",
  secret: "example-secret",
  grants: ["authorization_code"],
  redirectUris: ["http://localhost:3000/scalar"],
  scopes: ["openid", "profile", "email", "content:read", "content:write"],
};

// After: no ISSUER constant
const CLIENT: {
  id: string;
  secret: string;
  grants: string[];
  redirectUris: string[];
  scopes: string[];
} = {
  id: "example-client",
  secret: "example-secret",
  grants: ["authorization_code"],
  redirectUris: [], // validated dynamically below
  scopes: ["openid", "profile", "email", "content:read", "content:write"],
};

You can still add static redirect URIs to CLIENT.redirectUris if you have other clients with known URIs. For this app, Scalar's redirect URI is always {origin}/scalar which is why it doesn't make sense to hard-code it here. Unless you don't want every client to be able to redirect to your server's tool, but that's a different topic.

Step 3: Use a relative discovery URL

setDiscoveryUrl previously received the full URL including the origin. Pass only the path instead. The builder will resolve it against the request origin at runtime:

// Before
.setDiscoveryUrl(`${ISSUER}${DISCOVERY_ENDPOINT_PATH}`)

// After
.setDiscoveryUrl(`${DISCOVERY_ENDPOINT_PATH}`)

Step 4: Validate the redirect URI against the request origin

In getClientForAuthentication the redirect URI was validated purely against the static redirectUris array. Now also accept the internal URI {origin}/scalar where origin is the origin of the current authorization request:

// Before
.getClientForAuthentication((data) => {
  if (data.clientId === CLIENT.id && CLIENT.redirectUris.includes(data.redirectUri)) {
    return { … };
  }
})

// After
.getClientForAuthentication((data) => {
  if (
    data.clientId === CLIENT.id &&
    (data.redirectUri === `${data.origin}/scalar` ||
      CLIENT.redirectUris.includes(data.redirectUri))
  ) {
    return { … };
  }
})

data.origin is provided by the builder from the incoming authorization request, so it automatically matches whatever host the server is running on.

Step 5: Set the iss claim from the grant context

Inside generateAccessToken, replace the static ISSUER string with grantContext.origin:

// Before
const registeredClaims = {
  …
  iss: ISSUER,
  …
};

// After
const registeredClaims = {
  …
  iss: grantContext.origin,
  …
};

grantContext.origin is derived from the token request that triggered this callback, so the iss claim in every access token and ID token will match the actual host that issued it.

Step 6: Prepend the runtime origin to the OpenAPI security scheme

The Scalar UI reads openIdConnectUrl from the OpenAPI spec to discover the authorization server. Now that URL is a relative path (see Step 3). So prepend the runtime origin in the /openapi.json handler:

// Before
app.get(
  "/openapi.json",
  openAPIRouteHandler(app, {
    documentation: {
      info: { title: "Auth Server API", version: "0.1.0" },
      components: {
        securitySchemes: { ...flow.toOpenAPISecurityScheme() },
      },
    },
  })
);

// After
app.get("/openapi.json", async (c, n) => {
  const issuer = getOriginFromRequest(c.req.raw);

  const schemes = flow.toOpenAPISecurityScheme();

  for (const schemeName in schemes) {
    if (schemeName === "openidConnect") {
      schemes[schemeName].openIdConnectUrl = `${issuer}${schemes[schemeName].openIdConnectUrl}`;
      break;
    }
  }

  return await openAPIRouteHandler(app, {
    documentation: {
      info: { title: "Auth Server API", version: "0.1.0" },
      components: {
        securitySchemes: { ...schemes },
      },
    },
  })(c, n);
});

getOriginFromRequest reads the Host (or X-Forwarded-Host) header from the raw Request object, so it returns the correct base URL whether the server is sitting behind a reverse proxy or running directly.

Result

After these changes the server has no opinion about where it is deployed. The same code works on http://localhost:3000, https://staging.example.com, and https://auth.example.com without environment-specific builds or configuration files.

Oh, and if you wonder why the endpoint URLs in the openid configuration response still have the correct origin, it's because of the way the flow's getDiscoveryConfiguration method is used in the discovery endpoint handler:

app.get(DISCOVERY_ENDPOINT_PATH, (c) => {
  const config = flow.getDiscoveryConfiguration(c.req.raw); // here we pass the Request
  return c.json(config);
});

It accepts the raw Request object as an argument (optional) and uses it to resolve the issuer and all endpoint URLs at runtime.

Now with that out of the way, continuing to the next articles in the series will be much easier. You won't have to worry about you deployment environment... at least for that... and not until you need to support multiple issuers from the same server, but that's a topic for another day 😉

The full runnable example is available at Github (apps/oidc-app).