Single sign-on (SSO)
Your team already exists in a company directory: Okta, Microsoft Entra ID, Google Workspace, Keycloak, Auth0, JumpCloud, Ping. You can use it with Writizzy. Nobody needs one more password, your own rules apply, including multi-factor, and cutting someone off in your directory cuts them off here.
Any directory that speaks OpenID Connect works, including one you host yourself such as Keycloak or Authentik.
SSO requires the Team plan.
If you also want arrivals and departures to reach your blog on their own, without anyone inviting or removing people by hand, set up SSO first and then read Automatic provisioning.
Setting it up
Everything is under Settings → Team → Single sign-on, and only the account owner sees it.
1. Create the application in your directory
Create an OpenID Connect application, of the kind meant for a server (Okta calls it a Web Application, Entra a Web platform). It gives you a client ID and a client secret.
Paste in the redirect URL shown on the Writizzy screen. Copy it from there rather than typing it: an address that differs by a slash is refused by your directory, with an error that does not say why.
2. Fill in the three values
| Field | Where it comes from |
|---|---|
| Provider address | See the table below |
| Client ID | Your directory, on the application you just created |
| Client secret | Same place. It is stored encrypted and never shown again |
The provider address is the only one Writizzy asks for, and everything else is discovered from it. It must be the exact address your directory publishes as its own, with no trailing slash. A few common ones:
| Directory | Provider address |
|---|---|
| Okta | https://yourcompany.okta.com, or https://yourcompany.okta.com/oauth2/default if you use a custom authorization server |
| Microsoft Entra ID | https://login.microsoftonline.com/<your-tenant-id>/v2.0 |
| Google Workspace | https://accounts.google.com |
| Keycloak | https://your-keycloak-host/realms/<your-realm> |
For anything else, your directory's documentation calls it the issuer, and it is the one value that has to match to the character. If you cannot find it, open <the address you think it is>/.well-known/openid-configuration in a browser: if a block of settings comes back, the issuer field inside it is what to paste.
If you get the address wrong, saving still works and signing in does not. The screen keeps working because a connection with no proven domain sends nobody anywhere.
3. Prove you own your email domain
Add your domain, for example yourcompany.com, then publish the TXT record shown on screen at _writizzy-sso.yourcompany.com, and click Verify.
DNS takes a few minutes to spread.
A verified domain is what lets your directory speak for an address, so we only trust it for addresses you have proven you own. Public mailbox domains such as gmail.com are refused: nobody can prove they own them.
A domain belongs to one blog. If yours is already claimed elsewhere, verification fails and we sort it out with you.
4. That is it
Once a domain is verified, everyone in your team whose address is in it signs in through your directory and nowhere else. They are signed out of their current session straight away, so the change takes effect now rather than whenever they happen to sign out.
You are not signed out. You are the one on the setup screen. You can ask a colleague to test it at writizzy.com/login.
To go back, remove the connection or the domain.
Who this applies to, and who it does not
Two conditions for triggering SSO:
- the person is a member of this blog's team
- and their address is in a domain you have verified.
The following are excluded:
- A freelancer you invited at
bob@gmail.comkeeps signing in the usual way. They are not in your directory.
What your directory did
Under Settings → Team → Single sign-on you get a record of everything that happened through your directory: who joined, who left, who signed in, and every sign-in it refused, with the reason.
Each line says when, who it was about, and who caused it, your directory, the person, or you. For your directory's own actions it also shows the address it called from, which is how you spot a provisioning token being used somewhere you do not recognise.
Kept for six months, then removed.
Good to know
An invitation still works, and still goes through your directory. Inviting a colleague at an address in one of your verified domains gives them their place as usual, but not a session: they land on the sign-in page, which recognises their address and sends them to your directory. That is how you add somebody when you use single sign-on without provisioning.
Sign-in starts here, not in your directory. Your team goes to writizzy.com/login, types their address, and is sent on.
Most directories also show your team a page listing the company's tools, one icon each, where clicking a tool usually opens it already signed in. That shortcut does not work for Writizzy. Add it as a plain link to https://writizzy.com/login instead, and it lands them on the page above, which sends them straight back to you.
Your directory has to have verified the address. If it reports an address as unverified, we refuse the sign-in.
Signing in does not create anything. Someone your directory knows but who is not on your team on Writizzy gets a message telling them to see their administrator. You have to invite them beforehand, or let provisioning do it.
If your directory is unreachable, signing in fails with an explicit message and no password is accepted in the meantime.
If your plan drops below Team, SSO stops applying and passwords work again.
Your team can still subscribe to newsletters anywhere on Writizzy, yours or anyone else's, and confirm their subscription from their inbox as any reader does. Confirming does not sign them in: that still goes through your directory.
Next
Automatic provisioning (SCIM) takes the next step: your directory creates the accounts, and removes them the day someone leaves.