For the complete documentation index, see llms.txt. This page is also available as Markdown.

Single sign-on

Overview

Single Sign-On (SSO) is a mechanism by which you delegate login to a identity provider (IdP). This identity provider will decide what security checks to perform, for example requiring two-factor authentication. Another benefit is that employees can use the same password for many services.

For Microsoft Entra ID and Google Workspace we have ready-made integrations, but any identity providers supporting the OpenID-Connect protocol (OIDC) is supported.

To avoid interrupting the login flows for regular employees, you can temporary use the soft-mode to verify that SSO works as expected. See enforcement level below.

Ready-made integrations

  • Go to Settings -> Single sign-on.

  • Press the Create button.

  • Choose your identity provider.

  • Click the Begin external steps link, which will guide you through the setup.

  • Choose the enforcement level.

  • If you are using Microsoft Entra ID you must enter your tenant ID.

  • If you are using Google Workspace, your domain must also be verified. Ask us for help.

Enforcement levels

Soft

Intended for testing purposes, before SSO is fully rolled out. Employees continue to log in only with their password, but admins can choose between password and SSO.

Discretionary

Allow both Skovik password and SSO for all employees (SSO is the default choice, though). Useful if you have temporary problems with your identity provider.

Mandatory

Require SSO for regular employees. Admins can log in with both password and SSO, avoiding the risk lockout. This is the recommended mode for most companies.

Inescapable

Require SSO for everyone, including admins. It's a good choice if you want to enforce two-factor authentication (via your SSO provider) for everyone. If your identity provider has issues, you will be temporarily locked out.

Manual setup

For IdPs where we don't have a ready-made integration, you can still setup OIDC manually, which should take little more than half an hour.

The following values are configured in Skovik for a manual setup:

  • issuer

  • token_endpoint

  • authentication_endpoint

  • client_id

  • client_secret (must be protected, treat it like a password)

The following redirect URIs must be whitelisted by the IdP:

  1. https://skovik.com/dz/login/oidc

  2. https://skovik.com/dz/login/oidc/native

Advanced topics

This section contains advanced details, the basics above are sufficient for most integrations.

Information for certain advanced cases:

  • We use the Authorization Code Flow (response_type=code).

  • The user’s email is provided as login_hint with the initial request, unless login hints are disabled.

  • The scopes openid and email are requested.

The email claim must match a known employee in the Skovik system (or an alternative claim key can be specified). Most authentication providers include the email claim by default.

Protocol details

For more information about the OpenID-Connect protocol, visit the OpenID Foundation.

Last updated

Was this helpful?