Skip to main content
The Tightknit community site supports two access modes: Public Access and Restricted Access. Site privacy and user login are configured independently. You can enable login on a public site so users can access personalized features, or restrict access entirely so only authenticated users can view content.

​
Access Control Options

​
Public Access

  • All pages are publicly accessible to anyone on the internet
  • No login required to view content
  • Content is discoverable by search engines
  • Perfect for public communities and open knowledge sharing
  • Users can optionally sign in for personalized features

​
Restricted Access

  • All pages require authentication
  • Only authenticated users can access the site
  • Content is private and not indexed by search engines
  • Ideal for internal teams and private communities
  • Certain public-facing actions are automatically hidden (see below)

​
Enabling Authentication

You can configure site access and authentication settings from the Community Site settings in Studio or from the Slack app home:
  1. Go to the Tightknit app home in Slack
  2. Navigate to the Community Site module
  3. Click General to open the site settings
  4. Under Site Access Control, select 🔒 Restricted Access - login required
  5. Save your changes
Site access control settings modal

Site access control settings modal

Site privacy (public vs. restricted) is managed separately from which login methods are enabled. You can enable login providers on a public site to allow users to sign in for personalized features, without requiring login to view content.

​
Supported Login Methods

Tightknit supports a variety of login methods for your community site. You can customize which authentication providers appear on your login page from the community site authentication settings in Studio.

​
OAuth Providers

Sign in with third-party accounts using industry-standard OAuth 2.0:
  • Google - Sign in with any Google account
  • Microsoft - Sign in with a Microsoft account
  • GitHub - Sign in with a GitHub account
  • Slack - Sign in with a Slack account that’s a member of your workspace

​
Email Sign-in Code

  • Email Sign-in Code - Users enter their email address and receive a one-time 6-digit verification code. They enter the code on the site to sign in. No password required.
Sign-in emails can be blocked, quarantined, or filtered as spam by strict corporate email security, and members sometimes sign in with a different email than the one on their profile. For member-friendly guidance (including how to allowlist our senders), see Not receiving emails from Tightknit.

​
Single Sign-On (SSO)

  • Enterprise SSO - Integrate with your organization’s identity provider using OIDC, SAML 2.0, or token-based JWT. Learn more about SSO.
All login methods use secure, industry-standard authentication protocols.

​
Connected accounts

Members who sign in with one method can link additional sign-in methods under Settings > Account on the community site. For example, a member who first signed in with an email code can later connect their Slack or Google account so they can use either method going forward. Linking works by verifying ownership: the member is already signed in, and the provider they connect confirms a second identity belongs to them. No admin action is required.

​
Managing connected accounts

Members open Settings from the profile menu, select the Account tab, and manage their linked methods under Sign-in methods:
  • Link a provider — Click Connect next to an available provider (Slack, Google, or GitHub). A sign-in window opens to verify the account, and the provider is added as a linked sign-in method.
  • Unlink a provider — Click Disconnect next to a linked provider to remove it. Tightknit blocks the disconnect if it would leave the member with no way to sign in to one of their communities.
These settings belong to the member’s global Tightknit account, not to a single community. If a member belongs to several Tightknit communities, connecting or disconnecting a method applies everywhere, across all of them. A method the member has connected can be unusable in a community that does not enable that provider.
A provider is offered as linkable only when both conditions hold: it is one of the providers Tightknit supports for linking (Slack, Google, and GitHub), and it is enabled in your community’s authentication settings. Microsoft can be offered as a login method but is never linkable (see the tip below). If you disable a provider, members can no longer sign in with it or link new accounts to it. Members who previously linked a disabled provider still see it listed, marked as not enabled in the current community, so they can disconnect it.
Connected accounts give members flexibility without requiring admin intervention. A member who joined via SSO can link their Google account as a backup sign-in method, or a member who signed in with Slack can connect their GitHub account as an alternative way to sign in.
Linking is only offered for providers that prove the member owns the email address they return. Microsoft does not provide a verified email claim that Tightknit can rely on, so it is never offered as a connectable method, even in communities that enable it for sign-in. Members can still sign in with Microsoft, and a member who already has it linked can still disconnect it.The same email-verification requirement governs automatic linking at sign-in, which is where a custom SSO integration can be affected. A Token-based JWT issuer that does not assert an email_verified claim leaves the account’s email unverified, so a later Google or Slack sign-in with the same address will not merge into that account. The member ends up with two separate accounts. If you run a custom SSO integration and want sign-ins to converge on one account, have your issuer send email_verified and contact Tightknit to enable email-based linking for it. OIDC and SAML SSO are not affected: Tightknit trusts the email address those providers assert.

​
Authentication audit trail

Studio provides two views for monitoring authentication activity across your community:
  • Per-member — Open a member’s detail page in Studio Members and select the Authentication tab to see that member’s sign-in history and connected accounts. See Member detail page for details.
  • Community-wide — Go to Workspace > Audit in Studio and open the Authentication section to browse all authentication events across every member, with search and filtering.
Both views show successful sign-ins, failed attempts, and account linking activity. Use them to investigate sign-in issues, monitor for unusual patterns, or verify that members are using the expected login methods.

​
Enabling interactivity

Interactivity lets members do more than read content. Once enabled, members can sign in, create posts, and leave comments that sync back to your Slack workspace. Because every interaction is tied to a signed-in member, you enable interactivity by turning on login and offering at least one login method. Configure these settings in Studio under Site > Authentication:
1

Allow members to log in

Under Access, turn on Allow members to log in. If your site uses Restricted Access, login is required and this setting is enabled automatically.
2

Enable at least one login method

Give members a way to sign in by enabling one or more methods:
  • Methods — Email Sign-in Code (passwordless email sign-in via one-time code)
  • Providers — Slack, Google, Microsoft, or GitHub
  • Single Sign-On — your organization’s SSO provider
3

Allow posting on your Feeds

To let members create posts and comments from the site, enable Post from Site on each Feed where you want it. See Feed settings.
Posting and commenting are controlled per Feed. Once login is enabled, members can sign in, but they can only create posts or comments on Feeds that have Post from Site turned on.

​
Limitations

​
Google Groups and Aliases

Google Sign-in does not support email aliases, Google Groups, or other distribution list emails. OAuth authentication requires individual user accounts, not shared or group email addresses.
If a user attempts to sign in with a Google Group email (e.g., [email protected]) or a distribution list, the authentication will fail. Users must sign in with their personal Google account.
Examples of unsupported email types:

​
Restricted access behavior

When your site is set to Restricted Access, several public-facing actions are automatically hidden across the site since all visitors are already authenticated members:
  • Share — The Share button and Share overflow menu are hidden on all pages, including feeds, posts, events, members, and resources.
  • Embed — Embed options are hidden since content is not publicly accessible.
  • Follow (RSS) — The Follow/RSS button is hidden on feed pages.
  • Explore — The Explore button is hidden on feed pages.
These elements remain visible on public sites where they serve their intended purpose of helping visitors share and discover content.

​
Login page customization

You can customize the appearance of the login page’s side marketing panel from Studio under Site > Login Page. The following options are available:
  • Enabled — Toggle the marketing panel on or off.
  • Color theme — Choose a color theme for the panel.
  • Background color — Set a solid background color (hex) that overrides the default branding gradient.
  • Background image — Upload an image to use as a full-cover background on the side panel. When set, the background image takes precedence over the background color.
  • Title and description — Customize the marketing copy shown on the panel.
  • Media image — Upload a featured image to display on the panel.
The background color and background image options give you full control over the panel’s appearance. Use a background image for a branded visual, or a solid color for a clean, minimal look.
You can configure legal links that appear in the footer of the login form. These links are displayed as a consent line (e.g., “By continuing, you agree to our User Agreement and Privacy Policy”). To manage legal links, go to Legal & Terms in Studio. You can add up to 5 links, reorder them via drag-and-drop, and customize each link’s label and URL.

​
User Agreement

The Tightknit User Agreement is a required legal link that appears on every community site login page. It cannot be removed because it establishes the legal relationship between your community members and the Tightknit platform. The User Agreement is required because:
  • User consent — When members sign in to your community site, they are creating an account on Tightknit’s platform. The User Agreement ensures they understand and consent to how their data is collected, stored, and processed.
  • Community standards — The agreement sets baseline expectations for acceptable behavior and content on your community, protecting both you and your members.
  • Legal compliance — Displaying the User Agreement at sign-in satisfies regulatory requirements for informed consent, including GDPR and CCPA obligations around data processing transparency.
The User Agreement URL is required and cannot be modified.
In addition to the required User Agreement, you can add your own legal links such as a Privacy Policy or Terms of Service. Each link requires a label and a valid HTTPS URL. All configured links appear together in the login form consent line.

​
Session Management

Once signed in, users remain authenticated for 7 days. After this period, they’ll need to sign in again to access restricted content. Sessions are automatically refreshed when users are active on the site. If a user accesses the site within 24 hours of their last activity, their session is extended for another 7 days. This means active users won’t be logged out unexpectedly during normal use.

​
Security Features

  • Secure Cookies - All authentication cookies are encrypted and secure
  • HTTPS Only - Authentication only works over secure connections
  • Session Timeout - Automatic logout after 7 days of inactivity
  • OAuth 2.0 - Industry-standard authentication protocol
  • Token Encryption - OAuth access tokens and refresh tokens are encrypted at rest in the database to protect against unauthorized access if the database is compromised

​
Login error codes

When authentication fails, the login page displays an error message based on an error code in the URL query parameter. These codes help identify the specific failure reason.
If you use an external identity provider (such as Auth0) with a post-login action that checks membership via the Tightknit API, you can redirect rejected users to your login page with these error codes to display a meaningful message. For example: https://your-community.tightknit.ai/login?error=member_not_found

​
Troubleshooting

​
Users Can’t Sign In

  • Ensure the user is using a supported browser
  • Check that they have a valid account for one of the enabled login methods
  • Verify the user is a member of your Slack workspace (for Slack login)
  • If using Email Sign-in Code, check that the verification code email was not caught by a spam filter
  • If an SSO member is told to check their email, they are being asked to confirm connecting SSO to an account that already exists — see Connecting SSO to an existing account

​
Session Issues

  • Clear browser cookies and try again
  • Check that the site is using HTTPS
  • Ensure cookies are enabled in the browser

​
Access Denied

  • Confirm the user is a member of your Slack workspace (if using Slack login)
  • Check that the site access control is set to “Restricted Access”
  • Verify the user completed the full authentication flow

Related topics

Tightknit Infrastructure & Application SecurityCLIMembersSecurity at TightknitSingle sign-on (SSO)