Skip to content

Introspection/revocation endpoints unauthenticated (RFC 7662 token-scanning) #192

@rsharath

Description

@rsharath

Summary

/oauth2/token/introspect and /oauth2/token/revoke are currently unauthenticated. The tenant is derived from the presented token itself rather than from an authenticated caller. RFC 7662 §4 warns that an open introspection endpoint enables token-scanning attacks and recommends the endpoint require authorization (e.g. client authentication or a separate protection mechanism).

RFC 7662 §4 — To prevent token scanning attacks

Current behavior

Both endpoints are registered in the public route group with no auth middleware:

  • internal/handler/routes.goRegisterPublic(...)registerOAuthRoutes(...)
  • internal/service/oauth.goIntrospect(...) / Revoke(...) parse the token and derive tenant from its claims; no caller authentication.

This means an unauthenticated party can probe token validity by submitting candidate tokens.

Options to consider

  • Client authentication on introspection/revocation for confidential clients (RFC 7662 §2.1 / RFC 7009), leaving genuinely public clients to a different control.
  • Rate limiting + non-distinguishing responses (always active: false shape, constant-time) to blunt scanning where unauthenticated access must remain.
  • Decide the policy explicitly rather than inheriting "public" by default.

References

  • RFC 7662 §2.1, §4 — introspection auth + token-scanning prevention
  • RFC 7009 §2.1 — revocation client authentication

Reported by Andrii Deinega via WIMSE WG review of ZeroID.

Metadata

Metadata

Assignees

No one assigned

    Labels

    securitySecurity issuespec-complianceDeviation from SPIFFE/WIMSE/JWT-SVID specs

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions