You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(auth): link SSO sign-in to existing same-email accounts (#4866)
* fix(auth): link SSO sign-in to existing same-email accounts
SSO sign-ins failed with "account not linked" (then a cascading "Invalid
callbackURL") when an account with the same email already existed. Better
Auth's `@better-auth/sso` plugin hardcodes the provisioned user's
`emailVerified: options?.trustEmailVerified ? <claim> : false`, so with the
option unset every SSO login arrived unverified and tripped the account
linking gate `(!isTrustedProvider && !userInfo.emailVerified)` whenever the
provider was not in `accountLinking.trustedProviders`.
- Set `trustEmailVerified: true` on the SSO plugin so the IdP's verified-email
claim is honored (Okta, Entra ID, Google Workspace, Auth0 all assert it).
- Trust the operator's configured provider for linking: merge
`SSO_PROVIDER_ID` (when present in the app env) plus a new
`SSO_TRUSTED_PROVIDER_IDS` list into `trustedProviders`. Empty/unset =>
no-op, so existing deployments are unchanged.
- Invite callback URL: return a clean `/invite/<id>` (token already persists
in sessionStorage) so an appended `?error=` cannot produce a malformed URL.
- Document `SSO_TRUSTED_PROVIDER_IDS` in SSO docs, Helm values, and schema.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(auth): address review — guard trusted SSO providers, revert invite callback
- Only compute additionalTrustedSsoProviders when SSO_ENABLED, so
trustedProviders is exactly unchanged for non-SSO deployments.
- Revert the invite getCallbackUrl change: keep the token in the callback URL
(with sessionStorage/searchParams fallback) so the token survives when
sessionStorage is unavailable. The account-linking fix removes the
"account not linked" error that caused the malformed callback URL, so the
callback cleanup is unnecessary.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(auth): guard trusted SSO providers with isSsoEnabled (isTruthy)
env.SSO_ENABLED can be the string "false" (t3-env returns strings for
booleans), which is truthy in JS. Use the canonical isSsoEnabled flag
(isTruthy(env.SSO_ENABLED)) so SSO_ENABLED="false"/"0" correctly yields an
empty trusted-provider list, matching how SSO is gated elsewhere.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
question: "Can I still use email/password login after enabling SSO?",
251
251
answer: "Yes. Enabling SSO does not disable password-based login. Users can still sign in with their email and password if they have one. Forced SSO (requiring all users on the domain to use SSO) is not yet supported."
252
252
},
253
+
{
254
+
question: "A user already has an account with the same email — what happens when they sign in with SSO?",
255
+
answer: "Sim links the SSO identity to the existing account automatically, as long as your identity provider reports the email as verified (email_verified) or the provider is trusted. Most OIDC providers (Okta, Google Workspace, Auth0) assert email_verified, so linking just works. If sign-in fails with 'account not linked' — common with SAML providers that omit the claim — add the provider's ID to SSO_TRUSTED_PROVIDER_IDS on self-hosted and restart."
256
+
},
253
257
{
254
258
question: "Who can configure SSO on Sim Cloud?",
255
259
answer: "Organization owners and admins can configure SSO. You must be on the Enterprise plan."
@@ -280,8 +284,25 @@ NEXT_PUBLIC_SSO_ENABLED=true
280
284
# Required if you want users auto-added to your organization on first SSO sign-in
281
285
ORGANIZATIONS_ENABLED=true
282
286
NEXT_PUBLIC_ORGANIZATIONS_ENABLED=true
287
+
288
+
# Optional: comma-separated SSO provider IDs to trust for automatic account linking
289
+
# (links an SSO sign-in to an existing account with the same email). Needed when your
290
+
# IdP does not assert email_verified — typically SAML providers, or OIDC providers that
291
+
# omit the claim. Set it to the Provider ID you registered, then restart.
292
+
# (If you also keep SSO_PROVIDER_ID in the app's environment, that provider is trusted
293
+
# without listing it here.)
294
+
SSO_TRUSTED_PROVIDER_IDS=custom-oidc,partner-saml
283
295
```
284
296
297
+
<Callouttype="info">
298
+
When someone signs in with SSO and an account with the same email already exists
299
+
(for example, they previously signed up with email/password), Sim links the SSO
300
+
identity to that account automatically as long as your IdP reports the email as
301
+
verified, or the provider is trusted. If you hit an `account not linked` error,
302
+
either confirm your IdP sends `email_verified`, or add the provider's ID to
303
+
`SSO_TRUSTED_PROVIDER_IDS` and restart.
304
+
</Callout>
305
+
285
306
You can register providers through the **Settings UI** (same as cloud) or by running the registration script directly against your database.
SSO_USER_EMAIL: z.string().optional(),// [REQUIRED] User email for SSO registration
408
408
SSO_ORGANIZATION_ID: z.string().optional(),// Organization ID for SSO registration (optional)
409
+
SSO_TRUSTED_PROVIDER_IDS: z.string().optional(),// Comma-separated SSO provider IDs to trust for automatic account linking when an existing account shares the same email. Use for IdPs that do not assert email_verified. Merged into Better Auth accountLinking.trustedProviders.
Copy file name to clipboardExpand all lines: helm/sim/values.schema.json
+4Lines changed: 4 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -157,6 +157,10 @@
157
157
"type": "string",
158
158
"description": "Comma-separated additional public origins to trust for auth (e.g. 'https://app.example.com,https://www.example.com'). Merged into Better Auth trustedOrigins."
159
159
},
160
+
"SSO_TRUSTED_PROVIDER_IDS": {
161
+
"type": "string",
162
+
"description": "Comma-separated SSO provider IDs to trust for automatic account linking when an SSO sign-in matches an existing account's email. Only needed for IdPs that do not assert email_verified. Merged into Better Auth accountLinking.trustedProviders."
0 commit comments