github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 15:42:09 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #8267] oauth2Introspect returns {active: false} when introspecting client differs from token-issuing client #28360

New Issue
Open
opened 2026-04-17 19:47:16 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-17 19:47:16 -05:00
Owner
Copy Link

Originally created by @DibyodyutiMondal on GitHub (Mar 1, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/8267

Originally assigned to: @Paola3stefania on GitHub.

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

The /oauth2/introspect endpoint returns {active: false} when the client_id used to authenticate the introspection request differs from the client_id that issued
the token (azp for JWTs, clientId for opaque tokens). This makes it impossible to implement a standard resource server pattern where a frontend client obtains an
access token and a separate API/resource server validates it using its own credentials.

Describe the solution you'd like

Remove or relax the azp !== clientId / accessToken.clientId !== clientId checks in introspect.ts. RFC 7662 §2.1 only requires the introspecting party to be
authenticated — it does not require it to be the same client that issued the token. The azp/client_id field is already returned in the response so callers can inspect
it themselves.

Optionally, make strict same-client enforcement opt-in via something like opts.strictClientIntrospection.

Describe alternatives you've considered

  • Calling /oauth2/userinfo instead — works since it skips the clientId check, but requires openid scope and is semantically wrong for API token validation.
  • Using the token-issuing client's credentials for introspection — not viable when the resource server doesn't have access to the frontend client's secret.

Additional context

The relevant checks in packages/oauth-provider/src/introspect.ts:

// JWT tokens
if (clientId && jwtPayload.azp !== clientId) {
    return { active: false };
}

// Opaque tokens
if (clientId && accessToken.clientId !== clientId) {
    return { active: false };
}

RFC 7662 reference: https://datatracker.ietf.org/doc/html/rfc7662#section-2.1

Originally created by @DibyodyutiMondal on GitHub (Mar 1, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/8267 Originally assigned to: @Paola3stefania on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. The `/oauth2/introspect` endpoint returns `{active: false}` when the `client_id` used to authenticate the introspection request differs from the `client_id` that issued the token (`azp` for JWTs, `clientId` for opaque tokens). This makes it impossible to implement a standard resource server pattern where a frontend client obtains an access token and a separate API/resource server validates it using its own credentials. ### Describe the solution you'd like Remove or relax the `azp !== clientId` / `accessToken.clientId !== clientId` checks in `introspect.ts`. RFC 7662 §2.1 only requires the introspecting party to be authenticated — it does not require it to be the same client that issued the token. The `azp`/`client_id` field is already returned in the response so callers can inspect it themselves. Optionally, make strict same-client enforcement opt-in via something like `opts.strictClientIntrospection`. ### Describe alternatives you've considered - Calling `/oauth2/userinfo` instead — works since it skips the `clientId` check, but requires `openid` scope and is semantically wrong for API token validation. - Using the token-issuing client's credentials for introspection — not viable when the resource server doesn't have access to the frontend client's secret. ### Additional context The relevant checks in `packages/oauth-provider/src/introspect.ts`: ```ts // JWT tokens if (clientId && jwtPayload.azp !== clientId) { return { active: false }; } // Opaque tokens if (clientId && accessToken.clientId !== clientId) { return { active: false }; } ``` RFC 7662 reference: https://datatracker.ietf.org/doc/html/rfc7662#section-2.1
GiteaMirror added the identity label 2026-04-17 19:47:16 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label identity
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#28360
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?