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

[PR #4349] [CLOSED] WIP: feat(sso): add support for pre-configured SSO providers during initilization #13571

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

📋 Pull Request Information

Original PR: https://github.com/better-auth/better-auth/pull/4349
Author: @flowhorn
Created: 9/1/2025
Status: ❌ Closed

Base: canary ← Head: canary

📝 Commits (2)

  • 0259b7a feat(sso): add support for pre-configured SSO providers during initialization
  • beb515b fix provider config

📊 Changes

5 files changed (+458 additions, -70 deletions)

View changed files

📝 docs/content/docs/plugins/sso.mdx (+201 -1)
📝 packages/better-auth/src/plugins/sso/index.ts (+26 -1)
📝 packages/better-auth/src/plugins/sso/sso.test.ts (+44 -0)
➕ packages/sso/example-usage.md (+70 -0)
📝 packages/sso/src/index.ts (+117 -68)

📄 Description

Description

This PR adds support for pre-configured SSO providers during initialization.
Instead of always relying on registerSSOProvider (which requires a logged-in session and persists providers to the database), you can now declare providers directly in your SSOOptions when setting up Better Auth.

This makes it possible to:

  • Define static OIDC/SAML providers in code (e.g. Google Workspace, internal clinic SSO).
  • Keep provider configs in version control and environment-based configs.
  • Avoid database persistence and drift — providers exist only at runtime.
  • Simplify deployments by removing the need for boot-time API calls.

Closes #4346

Motivation

Currently, custom OIDC providers must be registered dynamically through the API, which:

  • Requires an authenticated session (not practical for server-side bootstrap).
  • Is error-prone and difficult to automate in CI/CD or infra-as-code.
  • Makes simple static use cases harder than necessary.

This PR addresses that by introducing configuration-based providers alongside the existing runtime registration.

Changes

  • Added providers option to SSOOptions.
  • Updated provider resolution logic to check config-based providers before database providers.
  • Extended documentation with configuration examples.
  • Added tests to verify that pre-configured providers are available immediately.
  • Provided example usage docs comparing config-based vs runtime-based providers.

Usage

import { betterAuth } from "better-auth"
import { sso } from "@better-auth/sso"

const auth = betterAuth({
  plugins: [
    sso({
      providers: [
        {
          providerId: "google-workspace",
          issuer: "https://accounts.google.com",
          domain: "yourcompany.com",
          oidcConfig: {
            clientId: process.env.GOOGLE_CLIENT_ID!,
            clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
            discoveryEndpoint: "https://accounts.google.com/.well-known/openid-configuration",
            pkce: true,
            scopes: ["openid", "email", "profile"],
            mapping: {
              id: "sub",
              email: "email",
              name: "name",
              image: "picture"
            }
          }
        }
      ]
    })
  ]
})

    
<!-- This is an auto-generated description by cubic. -->
---

## Summary by cubic
Adds support for pre-configured SSO providers during initialization so you can define OIDC/SAML providers in code without database entries. This simplifies setup and works alongside runtime-registered providers.

- **New Features**
  - sso({ providers: [...] }) supports OIDC and SAML, with optional domain and organizationId.
  - Provider lookups now check config first, then DB (by providerId, domain, or organization slug).
  - SSOProvider.userId is optional; config-based providers have no owner.
  - Updated docs, examples, and tests to cover config-based providers.

- **Migration**
  - If your ssoProvider.userId column is NOT NULL, make it nullable to support config-backed providers.

<!-- End of auto-generated description by cubic. -->



---

<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
## 📋 Pull Request Information **Original PR:** https://github.com/better-auth/better-auth/pull/4349 **Author:** [@flowhorn](https://github.com/flowhorn) **Created:** 9/1/2025 **Status:** ❌ Closed **Base:** `canary` ← **Head:** `canary` --- ### 📝 Commits (2) - [`0259b7a`](https://github.com/better-auth/better-auth/commit/0259b7a27e8c1109db6c4e883eefd09f7a00340b) feat(sso): add support for pre-configured SSO providers during initialization - [`beb515b`](https://github.com/better-auth/better-auth/commit/beb515b0d4997862db2ec68514f8ebe23a369f78) fix provider config ### 📊 Changes **5 files changed** (+458 additions, -70 deletions) <details> <summary>View changed files</summary> 📝 `docs/content/docs/plugins/sso.mdx` (+201 -1) 📝 `packages/better-auth/src/plugins/sso/index.ts` (+26 -1) 📝 `packages/better-auth/src/plugins/sso/sso.test.ts` (+44 -0) ➕ `packages/sso/example-usage.md` (+70 -0) 📝 `packages/sso/src/index.ts` (+117 -68) </details> ### 📄 Description ## Description This PR adds support for **pre-configured SSO providers during initialization**. Instead of always relying on `registerSSOProvider` (which requires a logged-in session and persists providers to the database), you can now declare providers directly in your `SSOOptions` when setting up Better Auth. This makes it possible to: - Define static OIDC/SAML providers in code (e.g. Google Workspace, internal clinic SSO). - Keep provider configs in **version control** and environment-based configs. - Avoid database persistence and drift — providers exist only at runtime. - Simplify deployments by removing the need for boot-time API calls. Closes #4346 ## Motivation Currently, custom OIDC providers must be registered dynamically through the API, which: - Requires an authenticated session (not practical for server-side bootstrap). - Is error-prone and difficult to automate in CI/CD or infra-as-code. - Makes simple static use cases harder than necessary. This PR addresses that by introducing **configuration-based providers** alongside the existing runtime registration. ## Changes - Added `providers` option to `SSOOptions`. - Updated provider resolution logic to check config-based providers before database providers. - Extended documentation with configuration examples. - Added tests to verify that pre-configured providers are available immediately. - Provided example usage docs comparing config-based vs runtime-based providers. ## Usage ```ts import { betterAuth } from "better-auth" import { sso } from "@better-auth/sso" const auth = betterAuth({ plugins: [ sso({ providers: [ { providerId: "google-workspace", issuer: "https://accounts.google.com", domain: "yourcompany.com", oidcConfig: { clientId: process.env.GOOGLE_CLIENT_ID!, clientSecret: process.env.GOOGLE_CLIENT_SECRET!, discoveryEndpoint: "https://accounts.google.com/.well-known/openid-configuration", pkce: true, scopes: ["openid", "email", "profile"], mapping: { id: "sub", email: "email", name: "name", image: "picture" } } } ] }) ] }) <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Adds support for pre-configured SSO providers during initialization so you can define OIDC/SAML providers in code without database entries. This simplifies setup and works alongside runtime-registered providers. - **New Features** - sso({ providers: [...] }) supports OIDC and SAML, with optional domain and organizationId. - Provider lookups now check config first, then DB (by providerId, domain, or organization slug). - SSOProvider.userId is optional; config-based providers have no owner. - Updated docs, examples, and tests to cover config-based providers. - **Migration** - If your ssoProvider.userId column is NOT NULL, make it nullable to support config-backed providers. <!-- End of auto-generated description by cubic. --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-13 09:00:34 -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 pull-request
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#13571
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?