OAuth introspection & revocation endpoints are unauthenticated (RFC 7662 §2.1 / RFC 7009)

[saucam]

Problem

/oauth2/token/introspect and /oauth2/token/revoke accept any caller. They are registered in registerOAuthRoutes (internal/handler/oauth.go:156-171) with no Security and no auth middleware, and the handlers derive the tenant from the submitted token itself rather than from an authenticated caller identity:

• introspectOp — internal/handler/oauth.go:328-334
• revokeOp — internal/handler/oauth.go:337-340

RFC 7662 §2.1: "To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint." An open introspection endpoint lets anyone probe token validity and metadata (active status, scopes, cnf, expiry) by submitting tokens — a token-scanning / validity-oracle surface.

For revocation, RFC 7009 §2.1 requires client authentication; an unauthenticated /revoke lets anyone who can present a token force its revocation. Because revoke always returns 200 per RFC 7009 §2.2, it's also a blind operation with no caller accountability.

Impact

• Introspection: token-scanning / validity oracle for anyone who obtains or guesses a token.
• Revocation: anyone holding a token can force-revoke it — an availability/DoS surface against agent credentials.
• No caller-identity audit trail on either endpoint; the tenant comes from the token, not the requester.

Proposed change

Require caller authentication on both endpoints (RFC 7662 §2.1 / RFC 7009 §2.1):

• Confidential clients authenticate (client_secret / private_key_jwt, or the internal-service secret), consistent with how the rest of the platform authenticates service callers.
• Public clients: per RFC 7662, still require some authorization — decide the policy (e.g. restrict introspection to the internal mesh, or require a client credential alongside the token).
• Keep the RFC 7009 §2.2 "always 200" response for revoke, but gate access first.
• Derive/verify the tenant from the authenticated caller and cross-check it against the token's tenant, rather than trusting the token alone.

References

• RFC 7662 §2.1 — introspection endpoint MUST require authorization (token-scanning defense)
• RFC 7009 §2.1 — revocation client authentication
• Code: internal/handler/oauth.go:156-171 (registration), :328-340 (handlers)
• Reported by Andrii Deinega via WIMSE WG review of ZeroID. Related: Validate DPoP proofs in /oauth2/token/verify forward-auth endpoint #193 (DPoP validation on the sibling /oauth2/token/verify forward-auth endpoint).

[rsharath]

Addressed in #198 (commit c9daba1 on fix/security-review-backlog).

What changed: introspection (RFC 7662 §2.1) and revocation (RFC 7009 §2.1) now enforce caller authentication, gated by a new config flag token.allow_unauthenticated_token_inspection (env ZEROID_ALLOW_UNAUTHENTICATED_TOKEN_INSPECTION):

• Production is strict by default. Validate() rejects allow_unauthenticated_token_inspection=true when server.env=production — the same production-gate pattern as allow_unsafe_dev_stub and the default issuer. A production deployment must consciously keep it false (strict) or fail startup. In strict mode an anonymous call to /introspect or /revoke is rejected with invalid_client; presented client credentials are verified (wrong secret → invalid_client).
• The standalone / network-isolated model and local dev keep the accept-and-verify posture (default flag true outside production). A production deployer who genuinely relies on network isolation authenticates these endpoints at their own edge (Server.Use) rather than serving them unauthenticated from ZeroID.
• The RFC 7009 §2.2 "always 200" revoke contract is preserved — the auth gate runs before it, and the rejected call does not revoke the token (covered by a new integration test).

This also builds on the earlier hardening in the same PR (public-client client_id-only handled per RFC 7009/7662; presented-credential verification on both endpoints).

One sub-point not closed — the tenant cross-check. The issue also asks to "derive/verify the tenant from the authenticated caller and cross-check it against the token's tenant." ZeroID OAuth clients are global, not tenant-scoped, so client authentication carries no caller tenant to cross-check. Gating access (above) closes the token-scanning / force-revoke surface; binding the caller's tenant requires a tenant-scoped caller identity (e.g. an internal-service credential that carries tenant context), which doesn't exist in the OSS core today. @saucam I am tracking that as follow-up, happy to keep this issue open scoped to the tenant cross-check, or split it out, your call.

[saucam]

@rsharath this is a solid fail-safe — production fails closed, and the always-200 gate ordering is right. One direction worth weighing for the follow-up, since it removes the env-gated anonymous mode entirely rather than defaulting it safe.

The axis I'd reframe: the real choice here isn't anonymous vs authenticated — it's who asserts the caller, ZeroID or the edge. Modeled that way, the endpoint can always require an asserted caller (no branch ever proceeds with caller == nil), satisfied two ways:

1. OAuth client auth — client_secret / private_key_jwt, the RFC 7662/7009 baseline we already verify-when-presented.
2. Edge-asserted identity — for the network-isolated model, the gateway/mesh terminates auth (mTLS / SPIFFE) and forwards a caller assertion. We already have the machinery: TrustForwardedHeaders + the deployer-supplied principal resolver (internal/service/principal.go), same as the admin surface. The isolated caller isn't anonymous — it's authenticated one hop up and asserted to us; absent the assertion → reject.

That honors RFC 7662 §2.1's MUST in every environment — never a literal open oracle — and the network-isolated deployer flips trust_forwarded_headers=true instead of allow_unauthenticated=true.

The second piece: gate the credential-less method on a checked network fact, not server.env. server.env is self-declared — a staging box that's actually routable is still an open oracle under the flag. Instead, honor the forwarded assertion only when the immediate peer is the trusted ingress (trusted-proxy CIDR) or the listener is bound loopback/private; a public-internet peer can't use method 2 at all and must present real client creds. Isolation gets verified, not asserted by a label.

And I'd split the posture per verb: introspect is read-only (scanning/disclosure), so the edge-asserted posture is fine; revoke is a write with availability impact — anyone who reaches it can invalidate tokens, and RFC 7009 ties it to the owning client — so it should require an asserted caller in all deployments, never relaxed.

On the tenant cross-check you flagged: this direction is also the natural carrier for it. A global OAuth client gives us no tenant, but an edge-asserted identity (internal-service credential / mTLS principal) can carry tenant context — so "require an asserted caller" and "cross-check the caller's tenant" converge on the same follow-up. +1 to splitting it out; happy to scope a new issue to "production-grade introspect/revoke auth: asserted-caller model + tenant binding" and reference this thread.

Not blocking #198 — ship the fail-safe. This is just the shape I'd aim the follow-up at.