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

[GH-ISSUE #9178] tracking: oauth-provider conformance + completion checklist #28619

New Issue
Open
opened 2026-04-17 20:03:12 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-17 20:03:12 -05:00
Owner
Copy Link

Originally created by @gustavovalverde on GitHub (Apr 14, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/9178

Summary

The oauth-provider plugin is the target issuer implementation for MCP integrations that are moving off the deprecated oidc-provider. The open sub-issues cover spec conformance, authorize-flow completion, and implementation defects. These gaps block production issuer use cases such as Claude.ai, Dynamic Client Registration consumers, and DPoP clients.

Root cause

The current gaps fall into separate categories that should be tracked together and fixed independently.

  1. Spec conformance. Metadata resolution fails when the issuer has a path prefix (RFC 8414 §3.1). Protected endpoints do not consistently parse Authorization: DPoP (RFC 9449 §7.1). Introspection does not enforce the client relationship required by RFC 7662 §2.1. Dynamic Client Registration does not accept translatable metadata defined by RFC 7591 §2.2. Loopback redirect URI matching does not ignore the port as required by RFC 8252 §7.3. Discovery does not advertise the device authorization endpoint and grant type from RFC 8628. OIDC Back-Channel Logout is not available. Token exchange from RFC 8693 is not available. Discovery and JWT signing behavior also remain incomplete.

  2. Flow completion. Authorize does not always resume after a fresh sign-in.

  3. Implementation. HMAC signing over URLSearchParams is sensitive to proxy reordering. The auth.api.oauth2UserInfo wrapper can fail request binding even when a direct fetch succeeds. private_key_jwt JTI replay protection is not atomic across instances. Passkey flows can return a 302 even when the caller sends Accept: application/json.

Scope

In: compliance of the oauth-provider plugin with OAuth 2.1, OIDC Core, and the RFCs listed above; authorize resume-after-login; the implementation bugs listed here.

Out: RP/consumer-side OAuth (genericOAuth, socialProviders): tracking: generic-oauth + social provider config. SSO plugin lifecycle and claim mapping: tracking: SSO plugin. SAML: see link-only SAML thread.

Resolution criteria

  • .well-known/oauth-authorization-server resolves correctly when the issuer has a path prefix.
  • Authorization: DPoP is parsed on every protected endpoint.
  • Introspection rejects a probe where the introspecting client differs from the issuing client.
  • DCR accepts translatable metadata per RFC 7591 §2.2.
  • Loopback redirect URIs match regardless of port per RFC 8252 §7.3.
  • .well-known advertises device_authorization_endpoint and the device-code grant.
  • A back-channel logout endpoint is published and verifiable.
  • Token exchange grant is available.
  • Authorize resumes after fresh sign-in without orphaning consent state.
  • JTI replay is rejected atomically across instances.
  • HMAC signing verifies after proxy query-string reordering.

Related

  • Replaces the oidc-provider plugin (deprecated; MCP moves onto oauth-provider).
  • Prior closed context includes #6486 (generic-oauth provider config dup) and #8559 (oauthProvider + baseURL object).
Originally created by @gustavovalverde on GitHub (Apr 14, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/9178 ## Summary The `oauth-provider` plugin is the target issuer implementation for MCP integrations that are moving off the deprecated `oidc-provider`. The open sub-issues cover spec conformance, authorize-flow completion, and implementation defects. These gaps block production issuer use cases such as Claude.ai, Dynamic Client Registration consumers, and DPoP clients. ## Root cause The current gaps fall into separate categories that should be tracked together and fixed independently. 1. **Spec conformance.** Metadata resolution fails when the issuer has a path prefix (RFC 8414 §3.1). Protected endpoints do not consistently parse `Authorization: DPoP` (RFC 9449 §7.1). Introspection does not enforce the client relationship required by RFC 7662 §2.1. Dynamic Client Registration does not accept translatable metadata defined by RFC 7591 §2.2. Loopback redirect URI matching does not ignore the port as required by RFC 8252 §7.3. Discovery does not advertise the device authorization endpoint and grant type from RFC 8628. OIDC Back-Channel Logout is not available. Token exchange from RFC 8693 is not available. Discovery and JWT signing behavior also remain incomplete. 2. **Flow completion.** Authorize does not always resume after a fresh sign-in. 3. **Implementation.** HMAC signing over `URLSearchParams` is sensitive to proxy reordering. The `auth.api.oauth2UserInfo` wrapper can fail request binding even when a direct fetch succeeds. `private_key_jwt` JTI replay protection is not atomic across instances. Passkey flows can return a 302 even when the caller sends `Accept: application/json`. ## Scope **In:** compliance of the `oauth-provider` plugin with OAuth 2.1, OIDC Core, and the RFCs listed above; authorize resume-after-login; the implementation bugs listed here. **Out:** RP/consumer-side OAuth (`genericOAuth`, `socialProviders`): `tracking: generic-oauth + social provider config`. SSO plugin lifecycle and claim mapping: `tracking: SSO plugin`. SAML: see link-only SAML thread. ## Resolution criteria - `.well-known/oauth-authorization-server` resolves correctly when the issuer has a path prefix. - `Authorization: DPoP` is parsed on every protected endpoint. - Introspection rejects a probe where the introspecting client differs from the issuing client. - DCR accepts translatable metadata per RFC 7591 §2.2. - Loopback redirect URIs match regardless of port per RFC 8252 §7.3. - `.well-known` advertises `device_authorization_endpoint` and the device-code grant. - A back-channel logout endpoint is published and verifiable. - Token exchange grant is available. - Authorize resumes after fresh sign-in without orphaning consent state. - JTI replay is rejected atomically across instances. - HMAC signing verifies after proxy query-string reordering. ## Related - Replaces the `oidc-provider` plugin (deprecated; MCP moves onto `oauth-provider`). - Prior closed context includes #6486 (generic-oauth provider config dup) and #8559 (oauthProvider + baseURL object).
GiteaMirror added the trackingenhancementoauthidentity labels 2026-04-17 20:03:12 -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 enhancement identity oauth tracking
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#28619
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?