How to Enable Knowledge Base SSO

Enabling SSO in a knowledge base comes down to picking one of three methods, API Key, SAML through Active Directory, or JWT, based on whether you have a developer, an Active Directory setup, or neither, and then connecting it to your identity provider.

Most knowledge base SSO guides assume the same thing: pick your identity provider from a dropdown, click connect, done.

That’s not how every platform handles it. I lost half a day once picking the wrong method before I understood that there were even multiple options. Some platforms use a generic authentication method that works with any identity provider instead of a fixed list of pre-built connectors, more flexible, but only if you know which one actually fits your setup first.

Picking the wrong method wastes more time than the setup itself would take. I’m walking you through what SSO actually is, which of the three real methods fits your situation, and exactly how to implement it.

What Is SSO and How Does It Work?

That’s the definition. Here’s what actually happens behind it, step by step.

1. Someone tries to access the knowledge base. They click a link or navigate directly to a private site.
2. The knowledge base checks if they’re already authenticated. If not, it redirects them.
3. The identity provider takes over. This is whatever system already holds their credentials, Okta, Azure, Google Workspace, or an in-house directory, whatever your company already uses.
4. The identity provider confirms who they are. Username and password, a passwordless method, or an existing active session, however that provider handles login.
5. A signal gets sent back to the knowledge base. This might be a signed token, a hash, or another form of confirmation, depending on the method in use.
6. The knowledge base grants access. A session starts, and the person can browse whatever they’re authorized to see.

Getting SSO for knowledge base systems right starts with one distinction: authentication and authorization aren’t the same thing. Authentication confirms who someone is. Authorization decides what they’re allowed to see once they’re in. SSO handles the first part. Roles and permissions handle the second. A lot of confused setups come from treating SSO as if it covers both.

Which SSO Method Should You Use for Your Knowledge Base?

One prerequisite before any of these matters: SSO only applies to a private knowledge base. If your site is public, there’s nothing to authenticate against, so make sure private sites are turned on first. Everything below assumes that’s already done.

From there, the right method depends on what you actually have to work with, not on which one sounds most advanced. Here’s how to match your situation to the right approach for knowledge base single sign-on.

That last row matters. Not every team has a clean path here, and pretending otherwise wastes more time than it saves. If that’s your situation, the honest next step is deciding whether it’s worth bringing in a developer for a single script, rather than forcing one of the other two methods to fit.

How to Set Up Each SSO Method?

Each of these solves the same problem differently. Pick the one that matches what you already have, per the table in the last section, then follow the steps for that one specifically. You don’t need all three.

API Key SSO

This is the most flexible method, and the trade-off is that a developer needs to build a small script to make it work.

Step 1: Turn on Private Sites and SSO. In Settings, go to Private Sites, check Turn On Private Sites, then check Turn On Single Sign-On. This reveals your API Key, a shared secret between your system and your knowledge base that should never be made public.

Step 2: Build the redirect flow. When someone tries to access the knowledge base, they get redirected to your login page. Once they authenticate there, your server runs a script that passes your site URL and an encoded version of the API key back to the knowledge base. If that key matches, a session gets created, and the person is let in.

Step 3: Handle logout. Set a Logout URL in the same settings panel so that ending a session on the knowledge base also ends it on your side, not just one or the other.

This is genuinely provider-agnostic. Whether your login page checks against Okta, Azure, Google, or something built entirely in-house, the mechanism is the same: your server confirms the login, then passes the confirmation along, the same pattern behind any API integration between two systems. For the full walkthrough with sample scripts, see how single sign-on works.

SAML SSO With Active Directory

Knowledge base SAML SSO is the no-code path here, but it requires real IT infrastructure, not just a willing admin. If your company already runs Active Directory, this method lets you use that existing system as the source of truth instead of building anything new, but it does mean involving IT rather than handling this alone.

What you need first: An Active Directory instance with email addresses set as a user attribute, a knowledge base account on the Enterprise plan, and a server running Windows Server 2012 or 2008 with ADFS installed.

Step 1: Add a Relying Party Trust. In ADFS Management, create a new Relying Party Trust and import the connection details for your specific account.

Step 2: Create claim rules. You’ll need two rules: one that sends the user’s email address as an outgoing claim, and one that transforms that incoming claim into a Name ID formatted as an email address.

Step 3: Confirm the connection. The initial SAML configuration on the knowledge base side gets set up for you as part of enabling this method, not something you configure yourself from scratch.

Step 4: Test with a real user. Go to the login page and enter only an email address, no password. If that email exists in both Active Directory and your knowledge base account, you should land on your organization’s own AD login screen instead of a generic one. If you’re specifically running Azure AD rather than on-prem ADFS, the setup steps differ slightly; see how to integrate Azure AD for that specific path.

Acer integrated its existing ADFS setup with ProProfs Knowledge Base to enable secure login on its internal documentation site for employees across 160 countries, without rebuilding anything from scratch. See how they did it.

Read the Full Case Study

JWT SSO

This sits between the other two: it needs a developer, but it’s lighter to implement than the API Key method since it’s just a signed token rather than a full redirect flow.

Step 1: Gather your required parameters. You’ll need your API key and the email address of the user you’re granting access to. Optionally, you can restrict which specific sites they can view.

Step 2: Generate the token server-side. Your server builds a JWT with a header, a payload containing the user’s email and access rules, and a signature created using your API key. This has to happen on your server, never in the browser, since the API key can’t be exposed client-side.

Step 3: Redirect with the token. Once the JWT is built, redirect the user to your knowledge base’s SSO endpoint with the token attached as a parameter. A valid, correctly signed token grants access immediately.

Each token is time-limited by design, so this isn’t a one-time setup; your server needs to generate a fresh token every time someone needs access, not reuse an old one.

What Mistakes Break SSO Setups?

Building a secure knowledge base SSO setup isn’t usually a protocol problem. Most failures are basic mistakes that only show up once a real user tries to log in, not during testing, not in a demo, but the first time someone outside the project actually needs access. According to Verizon’s 2025 Data Breach Investigations Report, compromised credentials were the leading initial access vector in 22% of breaches analyzed, which is exactly the exposure a properly configured SSO setup is supposed to close.

• Enabling SSO Before Private Sites

SSO doesn’t do anything on a public site; there’s nothing to authenticate against. Skipping this order means checking the SSO box and then wondering why nothing changed.

• Exposing the API Key Client-Side

The JavaScript and URL-based alternatives pass your API key in a script tag or a link, visible to anyone who views the page source. The redirect-based method keeps the key on your server. Convenience isn’t worth that trade-off for anything that holds real credentials.

• Not Handling Logout on Both Sides

A session can end on your application, but stay active on the knowledge base, or vice versa. Set a Logout URL so that ending one session actually ends both.

• Testing Only With an Admin Account

An admin account almost always has broader access than a regular user. A test that only uses an admin login won’t catch a permissions problem that a real employee or customer would hit immediately.

• Assuming One Method Has to Cover Everything

A customer-facing help center and an internal employee wiki don’t need the same SSO method. Running API Key SSO for one and SAML for the other is a legitimate setup, not a compromise.

Does Your Knowledge Base Platform Matter for SSO, or Is This All Generic Config?

Most of what’s covered here, redirect flows, claim rules, JWT signing, isn’t platform-specific. It’s how SSO works, full stop. What actually varies by platform is what happens around it: whether a customer-facing site and an internal wiki can run different methods from the same account, and whether you can see what’s happening with access after the fact.

ProProfs Knowledge Base, the easiest customer support help center & internal employee knowledge base in one, is built for the first part directly: SAML for your employee wiki, API Key for your customer help center, same account, no second platform. 

SSO also isn’t the only thing it connects to; the same account supports integrations with the tools you already use, so you’re not setting up identity as a one-off connection separate from everything else. Once access is locked down, AI Insights & Reports is worth knowing about too, not for security specifically, but because a private, login-gated site still needs someone watching whether people can actually find what they’re looking for once they’re in.

None of this replaces getting the SSO configuration itself right. It just means the platform doesn’t disappear the moment login is working.

Pick the Method That Matches What You Actually Have

The mistake to avoid isn’t choosing the wrong SSO method. It’s spending time evaluating options that were never going to fit your setup in the first place, no developer means the API Key method isn’t happening this week, and no Active Directory means SAML isn’t either.

Check what you actually have before you check anything else. If it’s a developer, start with API Key SSO. If it’s Active Directory, start there instead. If it’s neither, that’s the honest answer worth sitting with rather than forcing a setup around resources you don’t have yet.

Whichever method fits, the outcome looks the same on the other side: an sso enabled knowledge base gives people one login, no separate password to remember, and IT no longer fields “I forgot my help center password” tickets on top of everything else.

If you want to see the Private Sites and SSO settings before committing to a method, ProProfs Knowledge Base has a free plan you can try first, no credit card required.