Sign-in decides how members authenticate to the organization: whether two-factor or single sign-on is required, which sign-in methods are allowed, and how long a sign-in lasts. Identity-provider connections are the organization's own, and their secrets are write-only. Configure the provider before requiring SSO so administrators do not lock out the organization.
- 1
Add the provider
Enter the issuer and client information supplied by the organization’s identity system.
- 2
Verify the connection
Test that the provider answers, register the redirect URI it shows you, then try a real sign-in.
- 3
Set organization policy
Decide whether single sign-on is required, and whether a second factor is.
- 4
Roll out safely
Keep a verified administrator path while moving employees to the provider.
Allowed sign-in methods
Email codes, Google and Microsoft can each be turned off. Google can be limited to one Google Workspace domain. Under Microsoft you enter your organization's Microsoft tenant — one tenant ID per line if you are several companies. Only accounts from those tenants can sign in with Microsoft, and they are who Everyone in the organization means for an agent in Microsoft Copilot. Leaving the Google domain or the Microsoft tenant empty allows every account of that kind to sign in; with no Microsoft tenant, nobody gets answers in Copilot without signing in. If you signed in with Microsoft yourself, the page offers your own tenant while none is set. Your own SSO connections are always allowed. At least one way in must remain, and Tindre refuses a change that would turn off the method you signed in with when you would have no other way back in.
Turning a method off, or limiting it, signs out the sessions that used it.
Requiring two-factor
Set up two-factor for your own account first; until you have, the switch is off-limits to you. Turning it on gives members seven days. Everyone without an authenticator gets an email saying what is required and by when, and sees a reminder in Tindre with a link to set it up. Until the date they sign in as before. After it, sessions without two-factor are signed out and connected AI clients have to connect again. Someone whose only organization requires two-factor is asked to set it up when they sign in. Someone who also belongs to other organizations signs in to one of those, and sees this one as locked, marked «Requires two-factor», until they set it up. Turning it off cancels the date; turning it on again starts a new seven days.
Two-factor coverage
The two-factor block lists the members who have not set up an authenticator, and while a requirement is on its way, how many days they have left.
Session lifetime
By default a sign-in lasts the platform's standard period. You can choose 1, 7, 14, 30 or 90 days instead. A shorter period also applies to people who are already signed in.
Secrets are never returned
Client secrets can be written and replaced but not read back. Store the original in the organization’s secret-management system and rotate it when the upstream provider changes.
Policy is per organization
One tenant can require SSO while another permits platform sign-in. The policy is resolved inside the organization and does not weaken API or MCP authentication, and it does not apply to an anonymous visitor, who never signs in at all.
Test failure paths
Check disabled users, invalid claims, and provider downtime before enforcing the connection broadly. A successful administrator test alone does not prove every employee mapping works.
Audit changes
Provider and policy changes affect the organization’s main door. Treat them as controlled administrative actions.