Kudoboard supports SAML 2.0 single sign-on with any compliant identity provider (IdP) — Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, and others.
This guide covers everything you'll do on the Kudoboard side. For the specifics of creating a SAML application in your identity provider's admin console, refer to that provider's documentation — the menus and labels vary, but the underlying SAML 2.0 setup pattern is the same.
SSO login is not available on Business and Pro plans.
Setting up SSO with Microsoft Entra ID
Before you start
- You'll need the Tech Admin role in Kudoboard. Without it you won't see the SSO settings page.
- You'll need administrator access to your identity provider to create and configure a SAML application.
Finding the SSO settings page
- Sign in to your Kudoboard tenant (i.e. https://<company-name>.kudoboard.com).
- Open the Admin Panel.
- Select SSO from the left navigation. (https://<company-name>.kudoboard.com/admin/sso)
How SSO setup works
SAML setup is a two-sided exchange:
- You give your IdP some information about Kudoboard so it knows where to send authenticated users.
- Your IdP gives you some information back so Kudoboard can verify the assertions it sends.
You'll do steps in both places — your IdP's admin console and the Kudoboard SSO settings page — and then save the result on the Kudoboard side.
What to give your IdP
The Service Provider Settings section at the top of the SSO page contains everything your IdP needs to create its SAML application for Kudoboard:
- SAML Version: 2.0
- SAML Binding/Method: POST
- SP Metadata URL — many IdPs let you import this URL to autofill the SP details automatically.
- SP Assertion Consumer URL (ACS URL) — where your IdP posts the SAML response after a user authenticates.
Required user attributes
Your IdP's SAML application must send these three attributes in every assertion. Use these exact names (case-sensitive):
-
Email -
FirstName -
LastName
In your IdP, map each one to the corresponding user profile field (email address, given name, surname). The attribute names on the IdP side must match exactly — email or e-mail or EmailAddress won't be recognized.
Persistent NameID
Kudoboard identifies each user by the SAML NameID issued by your IdP — not by their email. This means a user's account stays intact even if their email or display name changes in your IdP.
Your IdP's SAML application must be configured to send a Persistent NameID (SAML 2.0 format urn:oasis:names:tc:SAML:2.0:nameid-format:persistent). The value itself can be any stable identifier your IdP supports — what matters is that it doesn't change for a given user over time.
The IdP-specific guides (Okta, Microsoft Entra ID) cover the exact field names and recommended source attributes.
What to enter from your IdP
After you've created the SAML application in your IdP, you'll come back to the Kudoboard SSO page and fill in these fields with values your IdP provides:
| Field | What it is | Common IdP labels |
|---|---|---|
| Entity ID | Your IdP's unique identifier (a URI) | "Identity Provider Entity ID," "Issuer," "Identity Provider Issuer" |
| SSO URL | The URL Kudoboard sends users to when they start signing in | "Identity Provider Single Sign-On URL," "Login URL," "SAML SSO URL" |
| SLO URL (optional) | The URL Kudoboard hits to end the IdP session when a user logs out of Kudoboard | "Single Logout URL," "SLO Endpoint" |
| Public x509 Certificate | Your IdP's signing certificate — Kudoboard uses it to verify that SAML responses really came from your IdP | "X.509 Certificate," "Signing Certificate" |
Most IdPs let you download the certificate as a .cer, .pem, or .crt file, or copy it as text. Paste the certificate contents into the Public x509 Certificate field — including or excluding the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines both work.
SSO login requirements
The SSO Login Requirements dropdown controls how SSO interacts with standard email/password login:
- Disabled — SSO is turned off. Users sign in only with email and password.
- Optional — Users can sign in with either SSO or email and password. Recommended while you're testing the setup.
- Required — Users must sign in via SSO. Email/password login is disabled.
Start with Optional while you verify everything works end to end, then switch to Required when you're ready to enforce SSO for your team.
Save and test
- Fill in Entity ID, SSO URL, SLO URL (if you're using it), and the Public x509 Certificate.
- Set SSO Login Requirements to Optional.
- Click Submit.
- Sign out, then sign back in using the SSO option to confirm the flow works.
Once a test sign-in succeeds, you can switch SSO Login Requirements to Required
Notes on specific identity providers
Most major identity providers — Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, JumpCloud, Auth0 — support SAML 2.0 in the same general way described above. The specific menus, field names, and attribute-mapping UIs differ; consult your IdP's SAML application documentation for exact steps in their admin console.
When you're following your IdP's setup wizard, here's how their terms map to ours:
- They'll ask for an ACS URL or Reply URL — paste Kudoboard's SP Assertion Consumer URL.
- They'll ask for an SP Entity ID, Audience URI, or Identifier — paste Kudoboard's SP Metadata URL.
- They'll ask which attributes to send — configure
Email,FirstName,LastName(case-sensitive) mapped to the user's email address, given name, and surname.
Need help?
If you run into problems during setup or your test sign-in fails with an unexpected error, reach out to sso@kudoboard.com with:
- The name of your identity provider
- The exact error message you saw
- The time the sign-in attempt happened
Our team can look up the corresponding logs and walk you through the fix.