Single sign-on (SSO) with OIDC: how it works

Kanroo lets you sign in by email or through your organization’s sign-in provider. SSO sign-in uses single sign-on (SSO): you authenticate with your organization’s provider and return to Kanroo.

You can use both sign-in methods with the same linked Kanroo account. Your memberships, roles, and existing work stay with that account. What changes is which access your current browser session has verified.

Quick steps

To sign in with SSO, choose Continue with SSO on the sign-in page.

The Sign in with SSO page with three numbered boxes: Organization, Continue, and Use a different provider account — SSO sign-in for the organization klabs

Enter the organization’s slug (box 1).
Choose Continue (box 2). Your provider signs you in and sends you back to Kanroo.
If the provider picks the wrong account, choose Use a different provider account (box 3) instead.

Owners connect the provider in Organization settings › SSO.

The SSO tab with three numbered boxes: the redirect URL, the provider fields, and Save draft — Connect an identity provider

Copy the Redirect URL (box 1) and register it in your identity provider. It shows the address of your Kanroo instance.
Enter the Issuer URL, Client ID, and Client secret of your provider (box 2).
Choose Save draft (box 3), then Test and connect. The provider becomes active only after a successful test sign-in.

The pages for Keycloak, Okta, and Microsoft Entra ID list the values for each provider.

What does “personal account” mean?

Personal sign-in means entering your Kanroo email address and the one-time code sent to it. It verifies access to your account and unlocks the protected personal settings: API keys, security activity, and Webhooks.

“Personal” describes the sign-in method. You can use your work email address; you do not need a private email address or a second account.

Personal sign-in still respects each organization’s rules. If an organization requires SSO, email verification alone does not unlock its boards and tasks.

What does “SSO” mean?

On the sign-in page, Continue with SSO takes you through the provider configured by your organization. Enter the organization’s slug: the short name used in its Kanroo URL. For example, an organization at /o/design-team/... uses design-team. Ask the Owner for the slug or for the SSO sign-in link if you do not know it.

Owners find that link in Settings → SSO below the redirect URL once a provider is connected. Copy SSO sign-in link copies a URL that opens SSO sign-in with the organization already selected; share it with members instead of explaining the slug. Do not register this link in the identity provider: that is what the separate redirect URL is for.

A SSO-only session verifies access to that organization. It does not unlock your protected personal settings or unrelated organizations. Everyday preferences stay available: your avatar, display name, task emails, and this browser’s theme, push notifications, and installation. Your role remains the same: SSO sign-in does not turn a Member into an Administrator or change an Owner into a Member.

Current sign-in	Personal settings	Organization access
Personal email sign-in	Available	Your memberships, subject to each organization’s SSO and access rules
SSO sign-in only	Everyday preferences available; API keys, security activity, and Webhooks require a one-time personal verification	Organizations you have signed in to through their provider in this session
Personal sign-in followed by SSO sign-in for the same account	Available	Personal access plus the organizations whose SSO sign-in you completed

Board permissions still apply in every case. Being signed in does not grant access to every board or permission to edit it.

The user menu offers Personal settings and Organization settings in every session. In a SSO-only session, the Account and Notifications tabs show your profile, appearance, notification, and install preferences. Display name, avatar, and task emails apply to all your organizations; appearance, push, and installation belong to this browser. The API keys, Webhooks, and Security tabs, and the Reply by email section on the Notifications tab, show Personal verification required instead: they are account-wide credentials, so Kanroo requires you to verify your own email before opening them. One organization’s sign-in provider cannot unlock them on its own.

To open the locked areas:

Select Verify personal account in the locked notice.
Select Send code. The code goes to the email address of your Kanroo account; you cannot enter a different address.
Enter the code. The locked areas open in place. You stay signed in with the same session, the same organizations, and the same SSO sign-in; nothing needs to be repeated.

The verification applies to this browser session, including its other tabs. A new session, for example after signing out, asks again.

Only the current organization Owner can manage SSO, its policies, and recovery codes. An Administrator does not receive those owner permissions. Owners also need SSO sign-in to manage these settings when SSO is required; ownership does not bypass enforcement. Owner billing and recovery access remain available through personal sign-in.

The first login links the identity supplied by your provider to your Kanroo account. Kanroo requires its own email verification even if the provider says your address is already verified. This prevents account linking based only on a matching email address.

If the provider supplies an email address, Kanroo sends the linking code there.
If it supplies no email, Kanroo asks you to enter an address and verify it.
If that verified address belongs to an existing Kanroo account, linking keeps its data and memberships. Otherwise, SSO onboarding creates the account when admission succeeds.
A first SSO signup does not create an additional personal organization.

The linking code verifies the link; it is not a personal sign-in. You can therefore complete email verification during SSO onboarding and still see Personal verification required in the protected personal settings afterwards. Use that action separately to unlock them.

Later SSO sign-ins with the same linked identity do not repeat the linking code. A different provider or a changed provider identity can require a new link, even if the email looks the same. SSO sign-in does not overwrite your verified Kanroo email or profile.

How do I join an organization?

SSO authentication and organization membership are separate requirements.

Existing member: sign in through the configured provider. Your existing role is retained.
Invited user: open the invitation and explicitly accept it as part of onboarding.
Automatic joining enabled: the owner can enable just-in-time provisioning (JIT), which lets eligible provider users join as Members, subject to organization limits.

A matching email domain alone does not grant membership, and provider groups do not assign Kanroo roles automatically. With JIT off, you need an existing membership or a valid invitation.

If you leave or are removed, JIT will not automatically add you back. Ask an administrator for a new invitation addressed to you; a general shared invitation link does not clear that block. For owners: creating that new direct invitation clears the removal block. Canceling the invitation afterwards does not restore it; with JIT on, remove the member again if access must remain blocked.

When you belong to several organizations, Kanroo leaves the choice to you. Select one in the organization menu. An empty selection on the overview does not mean your memberships are gone. With exactly one membership, a fresh personal session selects that organization automatically.

In a SSO-only session, the menu lists only organizations whose SSO sign-in you have completed and whose access is still valid. To add another, open SSO sign-in in the same browser session and enter that organization’s slug. Do not sign out between the two logins. You can then switch between them while both remain accessible.

Organizations using the same provider identity can share the existing account link, so joining the second one need not repeat email linking. Membership and SSO sign-in are still checked separately for each organization.

Yes. One Kanroo account can belong to organizations with different sign-in requirements. For example, you might belong to all three of these:

Organization	Required sign-in
A shared organization without SSO	Personal sign-in by email
An organization requiring Microsoft Entra ID	SSO sign-in through that organization’s Entra provider
An organization requiring Okta	SSO sign-in through that organization’s Okta provider

To use all three in the same browser session:

Sign in personally with your Kanroo email and the emailed code. You can access the organization without SSO and all Personal settings.
Select the Entra organization and complete its SSO sign-in when prompted.
Select the Okta organization and complete its SSO sign-in when prompted.
Switch organizations as needed. Do not sign out between these steps.

Each SSO sign-in for the same linked Kanroo account adds access to the current session. The Okta login does not replace the Entra access or remove personal access. Your role is still determined separately by each organization.

The first link to each provider requires its own Kanroo email verification. Both provider identities must link to the same Kanroo account to combine access in one session; a matching email address alone never establishes that link. Later logins with those linked identities do not repeat the linking code.

Each organization trusts its own provider. Being signed in through Okta cannot satisfy another organization’s Entra requirement, and personal email sign-in cannot bypass either requirement. Each SSO sign-in grants access for that organization’s own 24-hour period. When one expires, renew that organization’s SSO sign-in; the other access remains subject to its own validity.

If you start with SSO sign-in only, unrelated memberships and the protected Personal settings are not available yet. Use Verify personal account in your existing Kanroo account, then complete the required SSO sign-ins in that personal session. You do not need another Kanroo account or a separate browser for each organization.

A successful SSO sign-in verifies an organization’s access for 24 hours. Using Kanroo, refreshing the page, or reconnecting live updates does not extend that period. Afterwards, complete SSO sign-in again. Your provider may recognize its existing session and return you to Kanroo without asking for a password.

You may also need to sign in again after signing out, changing browser contexts, starting a new personal session, or an owner changing the organization’s SSO requirements or provider. Signing in personally first and then completing SSO sign-in for the same account lets one session hold both kinds of access.

Signing out of Kanroo does not also sign you out of your SSO provider. That is why a later SSO sign-in may complete automatically. Use the provider’s own sign-out controls when needed.

Your provider can reuse an existing browser sign-in without showing an account picker. That provider account may differ from the Kanroo account you intended to use. Signing out of Kanroo does not sign you out of Microsoft or Okta.

On Kanroo’s SSO sign-in page, enter the organization and select Use a different provider account instead of Continue. Kanroo then asks your provider to show its account picker. If your provider supports it, select the identity linked to your intended Kanroo account. Continue lets the provider use automatic sign-in; the provider may still show an account picker based on its session. Microsoft displayed the picker when account choice was explicitly requested during testing; provider logout alone did not reliably display it.

Keycloak 26.7.3 does not support this account picker. With an existing Keycloak browser session, Use a different provider account can still sign you in as the same account. Kanroo cannot force account choice for this provider.

If the provider signs you in as a different linked Kanroo user, Kanroo changes accounts; it does not combine those users’ access. An old organization link may then show Page not found. Check the current Kanroo account before continuing. Combining organization access requires all provider identities to be linked to the same Kanroo account.

What happens when access is removed?

Removing your Kanroo membership blocks further access to that organization, including from an already-open tab or an API key. A login already in progress does not bypass the removal. Other organization memberships are not removed by that action.

Disabling a user only at the SSO provider does not immediately revoke existing Kanroo access. Owners and administrators must also remove the user in Kanroo when access must end.

Deleting an organization makes its old links and SSO sign-in unavailable. An open page may still display previously loaded content, but that does not mean it can fetch more data or save changes. A rejected save is not a saved change.

What should owners know about Require SSO and recovery?

Connecting a provider and enabling Require SSO are separate actions. With enforcement off, personal sign-in remains usable for members. With it on, personal sign-in alone cannot access the organization, including for its Owner or Administrators.

Before enabling Require SSO, complete your own SSO sign-in and generate recovery codes under Settings → SSO. Verify the requested email code, save the recovery codes securely, and acknowledge that you saved them.

The new policy applies to your own session too. If your session has no SSO sign-in from the last 24 hours, Kanroo sends you to SSO sign-in right after saving and returns you to the same settings afterwards. A session with a recent SSO sign-in stays on the page.

If the provider becomes unavailable:

Sign in personally as the current organization Owner.
Open /auth/company/recovery on your Kanroo instance and select the organization.
Request the recovery email code and submit it with one unused recovery code.

Successful recovery disables Require SSO, consumes that recovery code, and keeps the provider configuration. It does not remove members or restore a paid subscription. The emailed code for recovery is separate from the code used to sign in personally.

There are ten codes in a set, each usable once. Generating a new set invalidates all previous codes. Codes belong to the organization and survive an ownership transfer, but only its current Owner can use them. Hand them over securely or have the new Owner regenerate them. If the mailbox or recovery codes are lost, contact your installation operator or hosted support.

Can personal API keys still access an SSO organization?

The Owner controls Allow personal API keys separately from Require SSO. When allowed, a key can access resources within its permissions and its user’s current membership and board access; it does not perform an interactive SSO sign-in.

When the policy is disabled, all personal keys lose access to that organization, including the Owner’s. The key remains valid for other organizations that allow it. Creating and managing personal keys requires personal sign-in. API keys cannot manage SSO settings.

SSO sign-in is available on every hosted plan and with self-hosted Enterprise. Self-hosted Core does not provide it.

Common messages

Message or situation	What to do
Personal verification required in API keys, security activity, or Webhooks	Select Verify personal account and enter the code sent to your Kanroo email; the session and its SSO sign-in stay as they are.
No access to this organization	Ask an administrator to check your membership or send a new invitation. Repeating provider login alone will not restore removed access.
SSO sign-in could not be started	Check the organization’s slug. If it is correct, ask the Owner to check that the organization and its SSO configuration are available.
SSO sign-in failed	Start a fresh SSO sign-in. If it keeps failing, ask the Owner to check the provider connection.
Your session is no longer valid	Sign in again. If the open page stays stuck, preserve any unsaved text before reopening Kanroo’s sign-in page.
Live updates are unavailable. Reconnecting…	This can indicate a connection problem. If it starts after access or SSO rules changed, preserve unsaved text and reopen the organization to check whether sign-in is required.
The code or recovery code was not accepted	Check that the email code belongs to the current recovery attempt and the recovery code is unused and from the current set for this organization.
Page not found on an old organization link	Check the link and your membership with the Owner. A removed or deleted organization is not available through an old URL.

For provider configuration, see Keycloak, Okta, or Microsoft Entra ID.

Personal sign-in and SSO sign-in