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

[GH-ISSUE #8616] OAuth 2.1 Provider: client_secret not validated when sent in POST body with client_secret_basic auth method #19768

New Issue
Closed
opened 2026-04-15 19:06:29 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-15 19:06:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @tobiassern on GitHub (Mar 15, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/8616

Bug Description

The OIDC Provider plugin does not validate client_secret when:

  • The client's token_endpoint_auth_method is set to client_secret_basic (expects secret in Authorization: Basic header)
  • But the client_secret is sent in the POST body instead

The token exchange succeeds even when the provided client_secret does not match the stored secret.

Steps to Reproduce

  1. Register an OAuth client with token_endpoint_auth_method: "client_secret_basic"
  2. Send a token request with client_secret in the POST body (not in the Authorization: Basic header)
  3. Use an incorrect client_secret value
  4. The token exchange succeeds — no secret validation error is returned

Expected Behavior

The token endpoint should either:

  1. Reject the request because the secret is not provided via the expected client_secret_basic method (i.e., Authorization: Basic header), OR
  2. If it accepts both methods, it should still validate the provided secret against the stored secret

Actual Behavior

The token exchange succeeds with a mismatched client_secret, effectively allowing any client that knows the client_id to obtain tokens without the correct secret.

Relevant Code

In plugins/oidc-provider/index.mjs, the token endpoint extracts client_secret from both the Authorization: Basic header and the POST body (lines ~375-390), but when the auth method is client_secret_basic and the secret comes via POST body, validation appears to be bypassed.

Environment

  • better-auth: 1.5.5
  • Using the OIDC Provider plugin as an upstream OAuth server for a Cloudflare Workers MCP server

🤖 Generated with Claude Code

Originally created by @tobiassern on GitHub (Mar 15, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/8616 ## Bug Description The OIDC Provider plugin does not validate `client_secret` when: - The client's `token_endpoint_auth_method` is set to `client_secret_basic` (expects secret in `Authorization: Basic` header) - But the `client_secret` is sent in the POST body instead The token exchange succeeds even when the provided `client_secret` does not match the stored secret. ## Steps to Reproduce 1. Register an OAuth client with `token_endpoint_auth_method: "client_secret_basic"` 2. Send a token request with `client_secret` in the POST body (not in the `Authorization: Basic` header) 3. Use an **incorrect** `client_secret` value 4. The token exchange succeeds — no secret validation error is returned ## Expected Behavior The token endpoint should either: 1. Reject the request because the secret is not provided via the expected `client_secret_basic` method (i.e., `Authorization: Basic` header), OR 2. If it accepts both methods, it should still validate the provided secret against the stored secret ## Actual Behavior The token exchange succeeds with a mismatched `client_secret`, effectively allowing any client that knows the `client_id` to obtain tokens without the correct secret. ## Relevant Code In `plugins/oidc-provider/index.mjs`, the token endpoint extracts `client_secret` from both the `Authorization: Basic` header and the POST body (lines ~375-390), but when the auth method is `client_secret_basic` and the secret comes via POST body, validation appears to be bypassed. ## Environment - better-auth: 1.5.5 - Using the OIDC Provider plugin as an upstream OAuth server for a Cloudflare Workers MCP server 🤖 Generated with [Claude Code](https://claude.com/claude-code)
GiteaMirror added the lockedbug labels 2026-04-15 19:06:29 -05:00
GiteaMirror commented 2026-04-15 19:06:31 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Mar 31, 2026):

This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.

<!-- gh-comment-id:4165919112 --> @github-actions[bot] commented on GitHub (Mar 31, 2026): This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.
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 labels bug locked
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#19768