Skip to content

Does local sign-in still work alongside SSO?

Requires Pro

Yes. In Notory, SSO is an additional sign-in path, not a replacement: local sign-in with email and password always remains available — there’s deliberately no “SSO-required” switch that would turn it off. If the identity provider goes down, users with a local password can still get in. JIT-provisioned SSO accounts, however, initially have no usable password — they’re effectively SSO-only until an administrator sets one.

  1. Both options on one screen. The login screen always shows the email and password fields. If e-mail discovery detects a provider, the “Sign in with …” button additionally appears — the password field doesn’t disappear.

  2. Bridging an IdP outage. If the IdP is unreachable, only the SSO path fails. Users with a local password sign in normally. Administrators should therefore always keep a local password for themselves (emergency access).

  3. Enabling local sign-in for an SSO-only account later. As an administrator, open the user’s detail page and set a password (“Set password” or “Send reset link”). Local sign-in then works as well.

  • No enforcement switch. There is no setting like “allow SSO only”. The local login endpoint checks exclusively the account, password, lockouts, and 2FA — an SSO configuration doesn’t affect it. This is a deliberate safeguard against IdP outages and misconfiguration.
  • SSO-only through an unusable password. During JIT provisioning, Notory generates a random password known to no one (Argon2id-hashed). Such an account can only sign in locally once an administrator sets a real password, or — with self-service reset enabled — the user chooses one themselves via “Forgot password?”.
  • Protection mechanisms apply to both paths. Account lockout after 5 failed attempts (15 minutes), the deactivation check, and mandatory 2FA setup all apply regardless of the sign-in path. During SSO login, the IdP handles multi-factor verification; a local TOTP code is not requested there.
  • Self-service reset as a fallback path. Whether users may request a reset link themselves is controlled by the instance setting “Self-service password reset” (requires SMTP) — relevant when SSO users need to switch to local sign-in.