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 #2752] bug: /token endpoint in OIDC Provider expects client secret for authorization code flows #17965

New Issue
Closed
opened 2026-04-15 16:20:01 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-15 16:20:01 -05:00
Owner
Copy Link

Originally created by @ieedan on GitHub (May 22, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2752

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Try and implement a code based flow with the OIDC Provider plugin.

Current vs. Expected behavior

For code based flows the client_secret is not required as is can't be secret for some applications however better-auth currently expects the client_secret to be present and valid when hitting the /token endpoint to retrieve a token with a code. Allow users to only provide the client_id when using code based flows.

It looks like the client_secret is also being validated here. It seems like to me if the grant_type is code and the code can be verified then we should be able to skip the requirement for a client_secret but I am not so sure myself.

Documentation for code based authentication:
https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce#bdaf1735d9ad4a3d8d11bc70caf77844_node

What version of Better Auth are you using?

1.2.8-beta.3

Provide environment information

N/A

Which area(s) are affected? (Select all that apply)

Client, Backend

Auth config (if applicable)

export const auth = betterAuth({
   plugins: [
      oidcProvider({ loginPage: '/login' })
   ]
})

Additional context

No response

Originally created by @ieedan on GitHub (May 22, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2752 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Try and implement a code based flow with the OIDC Provider plugin. ### Current vs. Expected behavior For code based flows the client_secret is not required as is can't be secret for some applications however better-auth currently expects the client_secret to be present and valid when hitting the `/token` endpoint to retrieve a token with a code. Allow users to only provide the client_id when using code based flows. It looks like the client_secret is also being validated here. It seems like to me if the grant_type is code and the code can be verified then we should be able to skip the requirement for a `client_secret` but I am not so sure myself. Documentation for code based authentication: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce#bdaf1735d9ad4a3d8d11bc70caf77844_node ### What version of Better Auth are you using? 1.2.8-beta.3 ### Provide environment information ```bash N/A ``` ### Which area(s) are affected? (Select all that apply) Client, Backend ### Auth config (if applicable) ```typescript export const auth = betterAuth({ plugins: [ oidcProvider({ loginPage: '/login' }) ] }) ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-15 16:20:01 -05:00
GiteaMirror commented 2026-04-15 16:20:02 -05:00
Author
Owner
Copy Link

@ieedan commented on GitHub (May 22, 2025):

Actually it seems like the only supported grant_type at the moment is authorization_code so maybe client secret should just be removed from this code entirely?

<!-- gh-comment-id:2901498760 --> @ieedan commented on GitHub (May 22, 2025): Actually it seems like the only supported `grant_type` at the moment is `authorization_code` so maybe client secret should just be removed from this code entirely?
GiteaMirror commented 2026-04-15 16:20:02 -05:00
Author
Owner
Copy Link

@ieedan commented on GitHub (May 22, 2025):

So I patched the provider in my code to remove the client_secret verification and that allows me to authenticate. Happy to open a PR if that's the correct solution for this!

<!-- gh-comment-id:2901516548 --> @ieedan commented on GitHub (May 22, 2025): So I patched the provider in my code to remove the client_secret verification and that allows me to authenticate. Happy to open a PR if that's the correct solution for this!
GiteaMirror commented 2026-04-15 16:20:03 -05:00
Author
Owner
Copy Link

@ieedan commented on GitHub (May 23, 2025):

I missed #2655 closing in favor of that

<!-- gh-comment-id:2904700699 --> @ieedan commented on GitHub (May 23, 2025): I missed #2655 closing in favor of that
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 locked
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#17965
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?