Skip to main content
Tightknit supports enterprise Single Sign-On (SSO) to integrate with your organization’s identity provider and authenticate community members through OIDC, SAML, or a custom JWT flow.

​
Supported Protocols

Tightknit supports the following industry-standard SSO protocols:
  • OIDC (OpenID Connect) - Modern authentication protocol built on OAuth 2.0
  • SAML 2.0 - Enterprise-grade XML-based authentication standard
  • Token-based JWT - Custom integrations for IdP-initiated flows

​
Supported Authentication Flows

​
SP-Initiated Flow

Users start at your Tightknit community and are redirected to your identity provider to authenticate. After successful authentication, they are returned to Tightknit and logged in automatically.

​
IdP-Initiated Flow

Users start at your identity provider portal and can access your Tightknit community directly from there. They land on Tightknit already authenticated without needing to sign in again.
IdP-initiated SSO requires Token-based JWT configuration. Please contact support to enable this feature.

​
Supported Identity Providers

Tightknit works with major enterprise identity providers, including:
  • Google Workspace
  • Microsoft Azure AD / Entra ID
  • Okta
  • Auth0
  • OneLogin
  • And other OIDC/SAML-compliant providers

​
Where to configure this

In Studio, go to Site > Authentication and use the Single Sign-On section to add and manage providers.

​
Set up an OIDC or SAML provider

You can configure up to five providers from Studio. A new provider starts disabled so you can review the configuration before making it available to members.
1

Open authentication settings

In Studio, go to Site > Authentication and find Single Sign-On.
2

Choose the connection type

Select Add provider, then choose OIDC or SAML. Tightknit suggests a provider ID based on your community and protocol. The provider ID must be globally unique and cannot be changed after creation.
3

Configure your identity provider

Copy the callback URL shown by Tightknit into your identity provider. SAML setups also receive an ACS URL and entity ID. Use Provider help for concise Auth0, Okta, Microsoft Entra ID, or Google Workspace instructions.
4

Enter the provider configuration

For OIDC, enter the issuer, client credentials, endpoints, and scopes. For SAML, paste the IdP metadata XML or enter the sign-on URL and the IdP signing certificate. Paste the certificate as PEM text with real line breaks; a certificate copied as a single line with literal \n characters is rejected.
5

Create and test the provider

Save the provider while it is disabled, then enable it immediately before a controlled test with an existing community member. Review Settings > Audit under Authentication after the test. If the test fails, you can correct the configuration without disabling the provider first; see Editing a live provider.
For an end-to-end provider example, see Set up Auth0 SSO.
Custom token (JWT) setup requires a coordinated review of the issuer, signing keys, audience, login URL, and account-linking behavior. Select Custom token (JWT) in Studio to contact the Tightknit team.

​
Reviewing a provider’s connection details

Each OIDC or SAML provider row in the Single Sign-On section has an info button that reopens the setup wizard on the Connect step. Use it to copy the callback URL, ACS URL, or entity ID again when your identity provider’s configuration needs them, without changing anything on the provider. Custom token (JWT) providers, and providers the Tightknit team set up with more than one configuration, do not have this button; contact support for their connection details.

​
Editing a live provider

OIDC and SAML providers you set up yourself can be edited while they are enabled, using the same rows that offer the info button above. Because the change applies immediately, Studio asks you to confirm before saving: choose Save live changes to apply, or cancel to keep the current configuration. A configuration that no longer matches your identity provider interrupts member sign-ins until you correct it, so review each step of the wizard before confirming. When editing a SAML provider, the stored signing certificate is masked. Leave the IdP signing certificate field blank to keep the current certificate, or paste a new one to replace it.

​
Connecting SSO to an existing account

When a member signs in with SSO using an email address that already has a Tightknit account created another way — an email sign-in code, or a Google, GitHub, or Slack login — Tightknit does not merge the two automatically. Trusting the identity provider’s word alone would let a misconfigured or compromised IdP claim someone else’s account. Instead, the member is sent a confirmation email:
  1. They sign in with your identity provider as usual.
  2. The login page tells them to check their email, and Tightknit emails the asserted address a confirmation link naming your community and the identity provider.
  3. Opening the link shows a confirmation page. Nothing changes until they select Connect — simply opening the email is not enough.
  4. After confirming, they return to the login page and sign in with SSO again, which now succeeds.
This happens once per member, per identity provider. Afterwards, SSO sign-in works normally. The confirmation email is always required when the asserted address belongs to someone who is not yet an established member of your community. An invitation on its own is never enough for your identity provider’s claim to attach to an existing Tightknit account. A Tightknit account can belong to several communities, so only the person who can open that mailbox may connect it to yours.
Confirmation links are single-use and expire after 10 minutes. If a member misses the window, they can start again by signing in with SSO — a new link is sent. A member who never confirms keeps their existing sign-in methods and loses no access.
Administrators can see this activity in Settings > Audit under the Authentication section: SSO link confirmation sent, SSO link confirmed, SSO link expired, and SSO link rate-limited.

​
Troubleshooting

Use the info button on the OIDC or SAML provider row to reopen the Connect step and copy the callback or ACS URL again. It must match exactly, including the protocol, path, provider ID, and trailing slash behavior.
Confirm the provider is enabled and Allow members to log in is enabled under Access. A disabled provider remains hidden while you configure it.
SSO verifies identity but does not create community access. Confirm the user’s email address belongs to an existing, active community member.
Confirm the issuer and every endpoint use HTTPS, the client secret is current, and the application allows the openid, profile, and email scopes. Review the Authentication audit log for the recorded provider error.
Confirm the IdP sends the member email as email or NameID, the assertion is signed when required, and the IdP metadata or certificate is current.
If the audit log does not identify the problem, contact [email protected] with the provider type, provider ID, error message, and a redacted screenshot. Never send a client secret or private key by email.