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(sso): close the fail-open paths an independent audit found
- Ask the entitlement read to throw rather than answer "not entitled" on
an outage, so a blip cannot drop the requirement and cache that
- Keep the membership read's old resilience for paths the requirement
allows anyway, and fail closed only on the ones it governs
- Say why a verification code was refused instead of calling it invalid
- Report the requirement from fresh reads, so the settings surface cannot
disagree with what sign-in enforces
- Document that social sign-in is refused too, and how an owner without a
password gets back in
Copy file name to clipboardExpand all lines: apps/docs/content/docs/platform/enterprise/sso.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -324,10 +324,10 @@ SSO provisioning creates internal organization members but does not grant worksp
324
324
By default members can sign in with a password, an email code, or your identity provider. To make single sign-on the only way in, open **Settings → Organization → Single sign-on → Sign-in** and set **Allowed sign-in methods** to **Single sign-on**. It becomes available once the organization has an identity provider on a verified domain.
325
325
326
326
- The requirement is checked when a session is created, so turning it on signs nobody out. Members keep working and meet the requirement at their next sign-in. To end current sessions too, use **Sign out all members** under **Settings → Organization → Security**.
327
-
- Organization owners keep every sign-in method. If the identity provider breaks, an owner can still sign in with a password and turn the requirement back off.
327
+
- Organization owners keep every sign-in method. If the identity provider breaks, an owner can still sign in with a password — setting one through **Forgot password** if they only ever signed in through the identity provider — and turn the requirement back off.
328
328
- If the last identity provider is deleted or its domain verification lapses, the requirement stops being enforced instead of locking the organization out, and you can switch back to any method at any time.
329
329
- Desktop app handoff from an already signed-in browser keeps working, because that session derives from one the requirement already admitted.
330
-
- A member who tries a password or email code sees a message telling them to sign in through their identity provider.
330
+
- A member who tries a password, an email code, or a social sign-in such as Google or GitHub sees a message telling them to sign in through their identity provider.
331
331
332
332
<Callouttype="info">
333
333
Turning the requirement off restores password and email sign-in immediately for everyone.
@@ -362,7 +362,7 @@ By default members can sign in with a password, an email code, or your identity
362
362
},
363
363
{
364
364
question: "Can I still use email/password login after enabling SSO?",
365
-
answer: "Yes, unless you require single sign-on. Enabling SSO does not disable password login on its own; set Allowed sign-in methods to Single sign-on to refuse password and email-codesign-in for members. Organization owners keep password sign-in as a way back in if the identity provider breaks."
365
+
answer: "Yes, unless you require single sign-on. Enabling SSO does not disable password login on its own; set Allowed sign-in methods to Single sign-on to refuse password, email-code, and social sign-in for members. Organization owners keep password sign-in as a way back in if the identity provider breaks, and can set a password through Forgot password if they never had one."
366
366
},
367
367
{
368
368
question: "A user already has an account with the same email — what happens when they sign in with SSO?",
0 commit comments