Every tool your company adds is another place someone can still log in after they leave. IT knows this, which is why "does it support SSO" is usually the first question on a security review and the last hurdle before a purchase.
FinalDoc supports SAML 2.0. Your team signs in to the dashboard with the identity provider you already run, and your existing joiner-mover-leaver process covers documentation the same way it covers everything else.
Any SAML 2.0 provider
Entra ID, Okta, Google Workspace, ADFS, OneLogin — or anything else that speaks SAML 2.0. Choosing your provider in the setup wizard only tailors the on-screen hints; the protocol is the same either way.
Setup is two exchanges of information. You give FinalDoc your provider's sign-in URL and its X.509 signing certificate. FinalDoc gives you back the Reply (ACS) URL, a Service Provider metadata URL, and an Entity ID to paste into your provider — or you can point your provider at the metadata URL and let it import everything itself.
The certificate is the part that matters. It is how FinalDoc verifies that a sign-in response genuinely came from your provider rather than from someone who found the URL.
Check before you roll out
Each connection has a Check action that validates what you have entered — that the sign-in URL is present and uses HTTPS, and that the certificate is a well-formed X.509 block — and tells you exactly what is missing rather than leaving you to discover it during a failed login.
It confirms the configuration is complete. Opening the sign-in URL and logging in with a real account confirms the round trip.
Authentication is not authorisation
This is where SSO implementations tend to go quietly wrong, so it is worth being explicit about the default.
Signing in through your identity provider proves who somebody is. It does not establish that they should be able to edit your documentation. A company with three thousand people in its directory does not want three thousand documentation editors.
So automatic account creation is off by default. Only people you have already invited as team members can sign in; everyone else is turned away, and the attempt is recorded in your audit log. Your directory decides who can authenticate. You decide who gets in.
If you do want accounts created on first sign-in, turn it on and pick the role those accounts receive — Viewer, Editor or Admin. It defaults to Viewer, the least privileged of the three, and automatically created accounts count toward your plan's team-member limit like any other.
Revoking access actually revokes it
The reason SSO earns its place on a security review is offboarding. Disable someone in your identity provider and they can no longer obtain a FinalDoc session — there is no separate password left behind for them to use.
Deleting a connection stops sign-ins through it immediately.
What this covers
SAML SSO signs your team in to the FinalDoc dashboard — the people who write, review and publish. Controlling who can read a published knowledge base is a separate thing, handled by Site Visibility and Reader Management, and the two can be combined: an internal knowledge base that requires reader sign-in, maintained by a team who authenticate through Okta.
Setting it up
Go to Settings → Security & Access → SSO (SAML) and click Create SSO. You will need the sign-in URL and signing certificate from your provider's admin console, which usually live under the SAML settings for the application. Available on the Enterprise plan.