Security and daily use - Enterprise SSO
There are two scopes, and they never mix
An account-level configuration logs in only users of that account; a platform configuration (with no account attached) logs in only Dock staff. Scope is determined by who is logged in, never by request parameters - specifically, by whether the organisation identifier in the address points to the platform configuration or to a specific account's configuration. A superadmin setting up Dock's own enterprise SSO does not switch anything on for any subscriber, and the reverse holds too: an account's configuration never reaches Dock staff. One configuration per scope - a unique database index enforces this, so two platform configurations can never be created by mistake.
Who has access to the screen
Among the platform roles, the enterprise SSO screen is visible only to the superadmin - this is panel-access configuration, not projects or billing, so a superdeveloper or a super-accountant never touch it. On the subscriber side it is configured by the account owner and the account admin.
What DockRay checks on every login
Before anyone is logged in, DockRay verifies in order: the one-time state and nonce, the ID token's signature against the provider's public keys (JWKS), the issuer (iss), the audience (aud), the expiry (exp) and the confirmed e-mail address (email_verified). A missing or mismatched value in any of these ends the login with an error, rather than letting someone in on incomplete proof of identity.
SSRF protection
The discovery address and every endpoint the provider returns must be a public HTTPS address - private and reserved addresses are rejected, since a configurable issuer would otherwise be a tool for probing DockRay's internal network with an account admin's permissions. The HTTP client used to talk to the provider never follows redirects - the address is checked before the request goes out, and a redirect would already point somewhere nobody verified.
SSO does not create accounts
Only an existing user belonging to that configuration's scope can log in - the integration never creates an account or moves a user between accounts. On the first login the match happens by confirmed e-mail address; every later login relies on the permanently saved sub identifier instead, not on the address, which can change. Changing the issuer in the configuration removes the existing bindings - a deliberate decision, since a new issuer means a different identity provider, and old proofs of identity should not automatically carry over to a new one.
What happens when access is lost
DockRay's second factor applies after a successful SSO login exactly as it would after a password login - the identity provider proves who someone is, but access to the panel is decided by DockRay alone. A deactivated user cannot log in even with a correct, fully verified token. A subscriber account dropping to the free plan turns login off entirely through this route, not just hiding the button in the panel - the integration is a paid component, and it stops working the moment that component is lost.