ORGANIZATION ADMINISTRATION
Single sign-on (SSO)
3 min
to get started with sso, reach out to your kognic contact overview kognic supports single sign on, allowing your organization's users to log in through your existing identity provider instead of managing separate kognic passwords we support both saml 2 0 and openid connect, and sso works with providers like okta, azure ad, google workspace, and onelogin sso is configured per email domain all users with a given domain, for example @acme com, are routed to the same identity provider sso users are passwordless within kognic, meaning there is no kognic password to set or manage, and actions like changing your password, resetting your password, or resetting mfa are automatically hidden in the platform all credential and mfa management is handled through your identity provider the userβs display name in kognic is inferred from their email address unless provided by the identity provider setting up users there are two ways users get access to the kognic platform when sso is enabled organization admins can invite users from docid\ xsnwyhqvd7uqphl1iglgn the invited user receives an email with a link that routes them to the correct sso provider they authenticate with their identity provider and their account is activated on first login there is no password setup step alternatively, just in time provisioning (jit) can be enabled to link an email domain to a kognic organization when enabled, a user who logs in via sso for the first time will automatically have an account created in kognic with the member role assigned to them there's no need for sending out invites manually you have full control over which users can access kognic by managing the allowed email addresses in your identity provider offboarding when a user leaves your organization, we recommend that an administrator removes or locks the user in the kognic platform as part of your offboarding process, in addition to deprovisioning them from your identity provider while their kognic user account is active, users can still use any api credentials, even though they will not be able to log in through their external sso provider
