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

[GH-ISSUE #4346] [sso] Allow static OIDC providers in SSO plugin config #9907

New Issue
Closed
opened 2026-04-13 05:43:22 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-13 05:43:22 -05:00
Owner
Copy Link

Originally created by @flowhorn on GitHub (Sep 1, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4346

Is this suited for GitHub?

  • Yes

Feature request: Static OIDC provider configuration

Problem

When using custom OpenID Connect (OIDC) providers, they currently have to be registered dynamically through the API.
This is error-prone and makes working with them more difficult than necessary, especially in server-side or infrastructure-as-code setups.

Proposed solution

Allow OIDC providers to be declared directly in the SSOOptions at initialization.
These providers should not be stored in the database, but instead behave like built-in social providers (GitHub, Google, etc.), so they can be easily changed and version-controlled.

Alternatives considered

  • Improving the registration experience (e.g. removing the requirement for a logged-in user, or allowing true server-side admin registration).

Additional context

Currently, registering providers requires a logged-in session, which makes it hard to bootstrap providers from the server side at startup. This blocks clean deployments and automation.

Originally created by @flowhorn on GitHub (Sep 1, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4346 ### Is this suited for GitHub? - [x] Yes ### Feature request: Static OIDC provider configuration #### Problem When using custom OpenID Connect (OIDC) providers, they currently have to be registered dynamically through the API. This is error-prone and makes working with them more difficult than necessary, especially in server-side or infrastructure-as-code setups. #### Proposed solution Allow OIDC providers to be declared directly in the `SSOOptions` at initialization. These providers should not be stored in the database, but instead behave like built-in social providers (GitHub, Google, etc.), so they can be easily changed and version-controlled. #### Alternatives considered - Improving the registration experience (e.g. removing the requirement for a logged-in user, or allowing true server-side admin registration). #### Additional context Currently, registering providers requires a logged-in session, which makes it hard to bootstrap providers from the server side at startup. This blocks clean deployments and automation.
GiteaMirror added the locked label 2026-04-13 05:43:22 -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 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#9907
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?