Single sign-on

About single sign-on

Skovik supports SSO (Single Sign-On).
The protocol we use is OpenID-Connect.
This protocol works with Google Workspace, Microsoft Azure, Office 365, Okta, OneLogin, Ping Identity, Gluu, Auth0 and many others.

📘
Ready Made Integrations
If you are using one of the providers below, we have ready-made integrations. In that case the instructions below are not needed, instead just contact us and we'll help you with the setup.

Office 365

Google Workspace

Microsoft Azure AD

Even without one of the providers above, integration is easy and takes mere minutes.
Almost all complexity is handled at the protocol level and abstracted away by Skovik and the authentication provider.

Basic setup

Only a few values about the authentication provider must be specified in Skovik.
A complete integration takes no more than 15-30 minutes.

The following values are set in Skovik:

- issuer
- token_endpoint
- authentication_endpoint
- client_id
- client_secret

Remember to protect the client_secret (treat it like a password).

The following redirect URIs must be allowed by the authorization provider:

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

Advanced topics

This section contains extra details on the implementation. The basics above are sufficient for most integrations.

These details are typically not needed for an integration, but may be useful in 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.
Scopes openid and email are requested.

The email claim must match a known employee in the Skovik system (or otherwise an alternative claim reference key can be specified).
Most authentication providers include the email claim by default, so typically no adjustment is required.

Protocol overview

The OpenID Connect protocol, in abstract, follows these steps.

The RP (Client) sends a request to the OpenID Provider (OP).
The OP authenticates the End-User and obtains authorization.
The OP responds with an ID Token and usually an Access Token.
The RP can send a request with the Access Token to the UserInfo Endpoint.
The UserInfo Endpoint returns Claims about the End-User.

These steps are illustrated in the following diagram:

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+