[GH-ISSUE #3242] Unified SSO Callback Endpoint #26860

Closed
opened 2026-04-17 17:34:49 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @isaacwasserman on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3242

Is this suited for github?

  • Yes, this is suited for github

Configuring separate allowed redirect urls for each SSO provider is a big pain point with the plugin's current implementation (especially during development and testing).

Describe the solution you'd like

I'd appreciate if there were a way to configure the SSO plugin such that all providers used the same endpoint for their callback URL. This could be done by passing the app's internal providerId in the authorization request's state parameter. Then, when the authorization is received by the shared callback URL, we can direct it to the correct provider using this id.

Describe alternatives you've considered

I initially considered ways that I could wrap BetterAuth's existing callback flow with my own provider inference logic, but the problem is that I have to way to include the providerId in the state.

Additional context

I would be willing to implement this as a contribution to the package, but want to feel out whether the maintainers would be open to such an option.

Originally created by @isaacwasserman on GitHub (Jul 1, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3242 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Configuring separate allowed redirect urls for each SSO provider is a big pain point with the plugin's current implementation (especially during development and testing). ### Describe the solution you'd like I'd appreciate if there were a way to configure the SSO plugin such that all providers used the same endpoint for their callback URL. This could be done by passing the app's internal `providerId` in the authorization request's state parameter. Then, when the authorization is received by the shared callback URL, we can direct it to the correct provider using this id. ### Describe alternatives you've considered I initially considered ways that I could wrap BetterAuth's existing callback flow with my own provider inference logic, but the problem is that I have to way to include the providerId in the state. ### Additional context I would be willing to implement this as a contribution to the package, but want to feel out whether the maintainers would be open to such an option.
GiteaMirror added the locked label 2026-04-17 17:34:49 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Sep 30, 2025):

Hi, @isaacwasserman. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary

  • You proposed adding a unified callback endpoint for all SSO providers to simplify configuration, especially during development.
  • The idea involves using the state parameter to pass the providerId for correct callback routing.
  • You expressed willingness to contribute the implementation if the maintainers support the concept.
  • There has been no further activity or comments on this issue since it was opened.

Next Steps

  • Please let me know if this feature is still relevant to the latest version of better-auth by commenting on this issue.
  • If I do not hear back within 7 days, I will automatically close the issue.

Thank you for your understanding and contribution!

<!-- gh-comment-id:3352874884 --> @dosubot[bot] commented on GitHub (Sep 30, 2025): Hi, @isaacwasserman. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary** - You proposed adding a unified callback endpoint for all SSO providers to simplify configuration, especially during development. - The idea involves using the state parameter to pass the providerId for correct callback routing. - You expressed willingness to contribute the implementation if the maintainers support the concept. - There has been no further activity or comments on this issue since it was opened. **Next Steps** - Please let me know if this feature is still relevant to the latest version of better-auth by commenting on this issue. - If I do not hear back within 7 days, I will automatically close the issue. Thank you for your understanding and contribution!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#26860