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

[PR #8591] feat(sso): add prompt parameter support for OIDC authorization requests #8084

New Issue
Open
opened 2026-03-13 13:59:35 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-03-13 13:59:35 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/better-auth/better-auth/pull/8591
Author: @mark-kbkg
Created: 3/13/2026
Status: 🔄 Open

Base: canary ← Head: feat/sso-prompt-parameter

📝 Commits (1)

  • 297fbda feat(sso): add prompt parameter support for OIDC authorization requests

📊 Changes

4 files changed (+71 additions, -0 deletions)

View changed files

📝 packages/sso/src/routes/providers.ts (+1 -0)
📝 packages/sso/src/routes/schemas.ts (+11 -0)
📝 packages/sso/src/routes/sso.ts (+32 -0)
📝 packages/sso/src/types.ts (+27 -0)

📄 Description

Summary

Adds the standard OIDC prompt parameter to the SSO plugin, enabling control over the authentication experience when signing in with OIDC identity providers.

This is useful when users have multiple accounts with an identity provider and need to be prompted to select which account to use, or when applications need to force re-consent.

Problem

The SSO plugin's OIDC flow currently provides no way to control the prompt parameter in the authorization request. The core createAuthorizationURL function already supports it, and the Generic OAuth plugin already passes it through — but the SSO plugin does not.

This means SSO consumers cannot force account selection, consent, or re-authentication when needed.

Solution

  • Provider-level default: Added prompt to OIDCConfig interface and provider registration schemas, so a default prompt can be configured per provider (both defaultSSO in code and database-stored providers)
  • Per-request override: Added prompt to the signIn.sso() body schema, allowing per-request override of the provider default
  • Precedence: Request-level prompt takes precedence over provider-level default (ctx.body.prompt || config.prompt)

Changes

File Change
types.ts Added prompt field to OIDCConfig interface with JSDoc
routes/schemas.ts Added prompt to oidcConfigSchema for provider registration
routes/sso.ts Added prompt to signInSSOBodySchema, buildOIDCConfig, createAuthorizationURL call, and OpenAPI metadata
routes/providers.ts Added prompt to mergeOIDCConfig for provider updates

Supported values

Per the OIDC spec:

  • none — No interaction; fail if not already authenticated
  • login — Force re-authentication
  • consent — Force consent screen
  • select_account — Force account selection
  • create — Prompt for account creation
  • select_account consent — Account selection + consent
  • login consent — Re-authentication + consent

Usage

// Provider-level default (in defaultSSO config)
sso({
  defaultSSO: [{
    domain: "example.com",
    providerId: "my-idp",
    oidcConfig: {
      // ...
      prompt: "select_account",
    },
  }],
})

// Per-request override (client-side)
await authClient.signIn.sso({
  email: "user@example.com",
  callbackURL: "/dashboard",
  prompt: "select_account consent",
})

Test plan

  • Verify prompt is persisted when registering a new SSO provider
  • Verify prompt is included in the authorization URL when set on provider config
  • Verify per-request prompt overrides provider-level default
  • Verify prompt is preserved during provider updates via mergeOIDCConfig
  • Verify backward compatibility — existing providers without prompt continue to work

Summary by cubic

Adds support for the OIDC prompt parameter in @better-auth/sso authorization requests. This lets apps force login, consent, or account selection when needed.

  • New Features
    • Provider default: add prompt to OIDCConfig (applies to both code defaultSSO and DB providers).
    • Per-request override: signIn.sso({ prompt }) can override the provider default.
    • Precedence: request value wins over provider default.
    • Wiring: pass prompt through buildOIDCConfig to createAuthorizationURL, update schemas/OpenAPI, and support updates via provider merge.
    • Backward compatible: existing providers work without changes.

Written for commit 297fbdaf88473f4f3a8ddf845ef0c59522687a80. Summary will update on new commits.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/better-auth/better-auth/pull/8591 **Author:** [@mark-kbkg](https://github.com/mark-kbkg) **Created:** 3/13/2026 **Status:** 🔄 Open **Base:** `canary` ← **Head:** `feat/sso-prompt-parameter` --- ### 📝 Commits (1) - [`297fbda`](https://github.com/better-auth/better-auth/commit/297fbdaf88473f4f3a8ddf845ef0c59522687a80) feat(sso): add prompt parameter support for OIDC authorization requests ### 📊 Changes **4 files changed** (+71 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `packages/sso/src/routes/providers.ts` (+1 -0) 📝 `packages/sso/src/routes/schemas.ts` (+11 -0) 📝 `packages/sso/src/routes/sso.ts` (+32 -0) 📝 `packages/sso/src/types.ts` (+27 -0) </details> ### 📄 Description ## Summary Adds the standard OIDC `prompt` parameter to the SSO plugin, enabling control over the authentication experience when signing in with OIDC identity providers. This is useful when users have multiple accounts with an identity provider and need to be prompted to select which account to use, or when applications need to force re-consent. ### Problem The SSO plugin's OIDC flow currently provides no way to control the `prompt` parameter in the authorization request. The core `createAuthorizationURL` function already supports it, and the Generic OAuth plugin already passes it through — but the SSO plugin does not. This means SSO consumers cannot force account selection, consent, or re-authentication when needed. ### Solution - **Provider-level default**: Added `prompt` to `OIDCConfig` interface and provider registration schemas, so a default prompt can be configured per provider (both `defaultSSO` in code and database-stored providers) - **Per-request override**: Added `prompt` to the `signIn.sso()` body schema, allowing per-request override of the provider default - **Precedence**: Request-level `prompt` takes precedence over provider-level default (`ctx.body.prompt || config.prompt`) ### Changes | File | Change | |------|--------| | `types.ts` | Added `prompt` field to `OIDCConfig` interface with JSDoc | | `routes/schemas.ts` | Added `prompt` to `oidcConfigSchema` for provider registration | | `routes/sso.ts` | Added `prompt` to `signInSSOBodySchema`, `buildOIDCConfig`, `createAuthorizationURL` call, and OpenAPI metadata | | `routes/providers.ts` | Added `prompt` to `mergeOIDCConfig` for provider updates | ### Supported values Per the [OIDC spec](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest): - `none` — No interaction; fail if not already authenticated - `login` — Force re-authentication - `consent` — Force consent screen - `select_account` — Force account selection - `create` — Prompt for account creation - `select_account consent` — Account selection + consent - `login consent` — Re-authentication + consent ### Usage ```typescript // Provider-level default (in defaultSSO config) sso({ defaultSSO: [{ domain: "example.com", providerId: "my-idp", oidcConfig: { // ... prompt: "select_account", }, }], }) // Per-request override (client-side) await authClient.signIn.sso({ email: "user@example.com", callbackURL: "/dashboard", prompt: "select_account consent", }) ``` ## Test plan - [ ] Verify `prompt` is persisted when registering a new SSO provider - [ ] Verify `prompt` is included in the authorization URL when set on provider config - [ ] Verify per-request `prompt` overrides provider-level default - [ ] Verify `prompt` is preserved during provider updates via `mergeOIDCConfig` - [ ] Verify backward compatibility — existing providers without `prompt` continue to work <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Adds support for the OIDC `prompt` parameter in `@better-auth/sso` authorization requests. This lets apps force login, consent, or account selection when needed. - **New Features** - Provider default: add `prompt` to `OIDCConfig` (applies to both code `defaultSSO` and DB providers). - Per-request override: `signIn.sso({ prompt })` can override the provider default. - Precedence: request value wins over provider default. - Wiring: pass `prompt` through `buildOIDCConfig` to `createAuthorizationURL`, update schemas/OpenAPI, and support updates via provider merge. - Backward compatible: existing providers work without changes. <sup>Written for commit 297fbdaf88473f4f3a8ddf845ef0c59522687a80. Summary will update on new commits.</sup> <!-- 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-03-13 13:59:35 -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#8084
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?