> For the complete documentation index, see [llms.txt](https://docs.skovik.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skovik.com/for-it-and-developers/single-sign-on.md).

# 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.

{% hint style="info" %}
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.
{% endhint %}

## 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.

{% hint style="warning" %}
To activate Single Sign-on, you will need to be an **Admin** in Skovik and have the required permissions in your IdP, for example **Global Admin** or **Application Administrator** in Microsoft Entra ID and **Administrator** for Google Workspace.
{% endhint %}

## Enforcement levels

<table><thead><tr><th width="130"></th><th width="602"></th></tr></thead><tbody><tr><td><p></p><p>Soft</p></td><td>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.</td></tr><tr><td>Discretionary</td><td>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.</td></tr><tr><td>Mandatory</td><td>Require SSO for regular employees. Admins can log in with both password and SSO, avoiding the risk lockout. <em>This is the recommended mode for most companies.</em></td></tr><tr><td>Inescapable</td><td>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.</td></tr></tbody></table>

## 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](https://openid.net/).