WorkOS AuthKit MCP authentication: known deviations
aud is only correct when Resource Indicators are enabled in the dashboard and the client sends resource — otherwise it falls back to the client id.
How WorkOS AuthKit deviates from the MCP authorization spec
- The JWKS is at /oauth2/jwks.
- `aud` is only the expected resource URL when Resource Indicators are enabled in the dashboard — a configuration step outside any code — and the client sends `resource`.
- The dashboard's default Resource Indicator covers only CIMD/DCR-registered clients; hand-created OAuth and M2M apps always fall back to aud = the environment client id.
- Refresh tokens minted before a default was set keep their old audience, so mixed-aud fleets persist after a “fix”.
How to spot it without credentials
The Protected Resource Metadata's resource URL is exactly the expected aud; signin.workos.com's RFC 8414 document advertises PKCE, DCR and CIMD while its OIDC discovery document omits all three — which discovery-ladder rung a client lands on decides its verdict.
What it breaks in production
A 401 with a correct-looking token is the predictable “Resource Indicators not enabled” failure, and an aud shaped client_… fingerprints the vacuous-audience fallback — including every hand-created M2M app, which the default can never cover.
Check a WorkOS AuthKit-backed MCP server
The free scanner runs the discovery and client-compatibility checks with no credentials, and every finding cites the spec requirement it violates:
npx mcpcomp https://your-mcp-server.example/mcp