One sign-in for the whole company.

Your identity provider proves who someone is; Screencake signs them in. The protocol is OpenID Connect (Authorization Code with PKCE), which every major provider speaks — Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin and Auth0 among them. SAML isn't offered.

Single sign-on is part of Studio. A workspace that leaves the plan keeps its connection, but it stops signing anyone in until the workspace returns.

1. As the workspace owner, open Workspace settings › Single sign-on.
2. At your provider, create a web application with the redirect URI https://screencake.com/sso/callback and the scopes openid email profile.
3. Paste the issuer URL, client ID and client secret, and enter your company's email domain.
4. Prove the domain with the DNS record shown (below), then verify.

The client secret is stored encrypted and never shown again; leave the field blank later to keep it. Screencake reads the provider's configuration from /.well-known/openid-configuration under the issuer, so there is nothing else to paste.

Nobody can sign in through a connection until its domain is verified. The settings page shows a TXT record to add at _screencake.yourdomain.com with a value of the form screencake-verify=…. DNS changes can take a while to publish; choose Verify domain once they have.

Keep the record in place. Changing the domain later means proving the new one. Public email providers — gmail.com, outlook.com and the like — can't be claimed, and each domain belongs to one workspace.

Choose Sign in with SSO on the sign-in page (or open screencake.com/sso), enter a work email, and the browser goes to your provider and comes back signed in. An account with two-factor authentication still presents its second factor afterwards — the provider is the first factor, not both.

The desktop and mobile apps already sign in through the browser, so single sign-on works there with nothing extra to set up.

An address the provider hasn't verified, or one outside the workspace's domain, is refused whatever the provider says about it.

Once the domain is verified, turn on Require single sign-on. From then on a password sign-in for any address at the domain is sent to single sign-on instead.

Passkeys still work: they are phishing-resistant and bound to this site, so they are left alone on purpose. Turning the requirement off returns everyone to passwords at once; nobody is signed out either way.

With Let anyone at the domain join on, a first sign-in from the domain creates the account — its address already verified, its own personal workspace alongside — and adds it to your workspace at the role you choose:

• Reader — read and comment on every production
• Producer — read-only across productions
• Editor — edit scripts and comments, no member management
• Writer — create and edit scripts, invite collaborators

Owner and admin are never granted this way. With the switch off, single sign-on signs in existing accounts only and new people need an invitation.

• single sign-on connected, updated or disconnected, and the domain verified
• single sign-on required or no longer required
• every sign-in through it, with the address and “sso” as the method
• each account that joined through it, and the role it was given

See the workspace audit log for the rest of what it keeps.

The issuer URL, the client ID, the client secret (encrypted at rest), the email domain and the verification token. From each sign-in we read the address, whether the provider has verified it, and the name; the provider's tokens are checked and discarded, never stored.

Choose Disconnect on the settings page. Everyone goes back to passwords and passkeys; existing sessions carry on, and accounts created through single sign-on keep working — they can set a password from the sign-in page's forgotten-password link.