> For the complete documentation index, see [llms.txt](https://docs.kinesis.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kinesis.network/organizations/single-sign-on.md). # Single sign-on Connect your identity provider, manage first-sign-in roles and require SSO for organization access. Single sign-on (SSO) lets your team access a Kinesis organization through its identity provider, such as Okta, Microsoft Entra or Google Workspace. Kinesis uses WorkOS for the provider connection; organization roles and resource permissions remain in Kinesis. ## Set up your organization 1. As an organization admin, open **Organization → Settings → Single sign-on**. If it says **Not set up**, contact Kinesis support to connect your provider. 2. Work with support and your IT administrator to establish an active provider connection and verify your organization's email domain. A domain can route SSO to only one Kinesis organization. 3. Once enabled, return to Single sign-on. The card shows the enabled date, verified email domains, sign-in link and role on first sign-in. 4. Copy the organization's sign-in link and test it before requiring SSO for everyone. Admins can subsequently use **Set up the connection** and **Verify a domain** to open the hosted setup portal. After IT verifies a new domain there, select **Refresh domains** in Kinesis. Domain changes are not copied into Kinesis until refreshed. If no verified domain remains, the refresh is refused; contact support to resolve the setup or turn SSO off. Other members can read the SSO details once it is enabled. Only admins change them. Kinesis support enables or disables the provider connection; **Require single sign-on** is a separate organization control. ## Sign in Use any of these entry points: * On the [sign-in page](https://portal.kinesis.network/signin), choose **Continue with Single Sign-On** and enter your work email. Its verified domain identifies the organization. * Use the sign-in link copied from Settings: `https://portal.kinesis.network/sso/`. It goes directly to the provider without asking for an email first. * Open the Kinesis tile in your identity provider, when your IT administrator has configured one. The short [SSO link](https://portal.kinesis.network/sso) opens sign-in with the SSO option selected. Complete authentication with your provider, then return to Kinesis. Your email must be on a domain verified for the organization, including when you use its direct link. ## First sign-in and roles | Person signing in | Result | | -------------------------------------- | ------------------------------------------------------------------------------ | | Existing organization member | Keeps their current role | | Person with a valid pending invitation | Joins at the invitation's role and receives any resource access included in it | | Person without an invitation | Joins at the configured **Role on first sign-in** | Admins choose **Developer** or **Viewer** as the default first-sign-in role. Changing it does not change existing members. Grant Admin access through normal member administration or an appropriate invitation. SSO signs in to the existing Kinesis account with the same email when there is one; see [Bring existing members to SSO](#bring-existing-members-to-sso). A new person gets an account and membership in this organization, without a separate organization of their own. An account created through SSO has no Kinesis password; authentication and its second factor are handled by the provider. A person can later set a Kinesis password through **Forgot password**. ## Bring existing members to SSO Turning SSO on changes no existing account. Members keep their account, role, projects, apps, API keys and billing; nothing is exported, re-created or moved. Each account is linked to the provider the first time its person signs in through it. At that first sign-in, Kinesis finds the account with the same email (ignoring capitals) and links it to the person's identity at the provider. Later sign-ins follow that link, even if their email at the provider changes. Members keep their password and two-factor settings, but once SSO is required, a password sign-in on a verified domain goes to the provider. If an account's email was never verified, its password is removed and the provider becomes its sign-in. To roll SSO out: 1. Check that each member's Kinesis email is the one the provider sends for them, on a verified domain. Members can't change their Kinesis email themselves; if one differs, align it at the provider or contact Kinesis support. 2. Ask every member to sign in once with the organization's sign-in link or the provider tile, so problems show up before SSO is required. 3. Have the owner turn on **Two-factor authentication** in Account settings. It keeps their [recovery sign-in](#require-sso) working once SSO is required. 4. Turn on **Require single sign-on** from a session that signed in through the provider. | Situation | What happens | What to do | | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | A member's email at the provider differs from their Kinesis email | Their first SSO sign-in creates a second account, which joins at the first-sign-in role. The old account stays a member until an admin removes it. | Align the emails before rollout, or contact support. Otherwise give the new account its role and remove the old one; resources stay with the organization. | | A member's email is on a domain the organization hasn't verified | Kinesis refuses their SSO sign-in, so they lose browser access once SSO is required. | Verify that domain too, or give them an account on a verified domain. | | Someone on a verified domain has a Kinesis account but isn't a member | Their first SSO sign-in adds them to this organization. Their own organizations and resources stay theirs. | [Move](/organizations/move-resources.md) any resources you want in this organization. | ## Require SSO An admin who has signed in through the organization's provider can turn on **Require single sign-on** in Settings. The control cannot be enabled from a session that has not completed that organization's SSO, even by the owner. When required, members need a browser session that signed in through this provider **within the last 24 hours**. Other sessions see a prompt to continue with SSO and return to the page afterward. A member attempting password sign-in with an email on the organization's verified domain is sent to its provider. The requirement applies to access to this organization, including its resources. It does not sign the person out of every other organization. Turning SSO off and on again invalidates the earlier SSO sign-in for this requirement. The owner retains a recovery path using a Kinesis password and a second factor. Authorized Kinesis support access also remains possible. Both are recorded in the organization's audit log. Contact support if a provider outage locks the organization out; support can stop requiring SSO. ## API keys and connected apps Existing API keys and connected apps keep working under their existing scopes, roles and organization limits. They do not need browser SSO renewed every 24 hours. Requiring SSO does not itself revoke them. Creating a key, changing where a key works, or approving a connected app that reaches an organization requiring SSO checks that the browser session is allowed into that organization. If Kinesis asks for SSO, complete it and repeat the credential setup. You can instead limit the credential to organizations the session can already access. The owner's recovery session follows the access exception described above. SSO settings are managed through the portal and support. The public REST API and MCP organization-setting actions do not configure SSO. ## Remove access Kinesis doesn't sync people from your provider (SCIM) yet. Remove the person from the Kinesis organization **and unassign them from Kinesis at the identity provider**. While SSO remains enabled, someone still allowed by the provider can rejoin at the default role on their next SSO sign-in. Removing membership ends their key and connected-app access in that organization; their resources remain and apps keep running. ## Troubleshoot sign-in | Message or situation | Next step | | ----------------------------------------------------- | -------------------------------------------------------------------------------- | | SSO is not set up | Ask an organization admin to contact support | | Email is outside the verified domains | Use the correct work email; IT can verify the domain and an admin can refresh it | | Login belongs to another organization | Start again from the intended organization's sign-in link | | Sign-in started elsewhere or expired | Start a fresh sign-in in the same browser | | Provider did not complete sign-in | Check the provider's app assignment and sign-in result; retry or ask IT | | Require SSO is unavailable | Sign in through this organization's provider first | | Key creation or OAuth approval returns `sso_required` | Complete SSO for the organizations the credential will reach | [Members and roles](/organizations/members.md) · [Settings and audit log](/organizations/settings.md) · [Get support](/support.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.kinesis.network/organizations/single-sign-on.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.