Federated Login#

Skalio ID supports authentication through registered external identity providers, based on OpenID Connect.

The following flows are supported:

• Authorization Code Flow
• Implicit Flow
• Formpost Flow

In all cases, the authenticity and the identity of the person is established by external identity provider. An external ID token is issued. Skalio ID validates the external ID token, locates the matching person and issues a Skalio ID token in return. The token includes a http://skalio.com/oidc_provider claim, identifying the external identity provider.

From this point on, authentication is completed successfully, and the person can use Skalio ID and its related services normally. Notice some restrictions apply for externally managed persons.

Implicit signup#

Persons authenticating via a registered external identity provider for the first time are auto-provisioned to Skalio ID automatically. The accounts are marked as external.

Auto-provisioning expects the external identity provider to ensure the email address of the person to be verified. As a result, no email-verification is started for the given email address.

Where possible, the name of the person is imported during initial setup.

Flows#

Authorization code flow#

The implementation follows the specification. In this flow, the client interacts with the external identity provider to authenticate himself and give consent to use Skalio ID. The identity provider returns a short-lived one-time key, the authorization code. The client forwards this authorization code to Skalio ID. From there, in a request towards the external identity provider, the authorization code is exchanged for an external ID token.

Skalio ID validates the external ID token and finds the matching person. If none is found, one is automatically auto-provisioned. The Skalio ID token is issued for the person and returned to the client.

Implementation notes:

• Use the code_verifier field where no clientSecret exists.

Implicit flow#

The implementation follows the specification. The client interacts with the external identity provider to authenticate himself and give consent to use Skalio ID. The identity provider returns the external ID token directly to the client. The client exchanges the external ID token at Skalio ID for a Skalio ID token.

Formpost flow#

The implementation extends the specification with preflight- and pickup-requests:

1. The client registers the intent to use the form-post flow with the Skalio ID backend. It sends the requested redirectUrl, where it expects notification of the completed authentication. The backend calculates a random state and returns it together with a short-lived pickup token, required at the end of the flow.
   • The registration of state as well as the associated pickup token expire after 5 minutes.
2. The client interacts with the external identity provider, requesting response_mode=form_post. The request includes the previously registered state and a redirect_uri pointing to Skalio ID.
3. The person interacts with the identity provider to authenticate himself and give consent to use Skalio ID.

4. The identity provider posts the external ID token to the redirect_uri at Skalio ID. Skalio ID associates the person with the state and redirects to the client.

   • Form-post flow requests without previous registration of the state are rejected.
   • The redirection response contains the URL registered during the preflight request.

5. The client fetches the Skalio ID token by providing the pickup-token.

Service restrictions#

Persons managed by external identity providers are limited in some of the Skalio ID functionality:

1. Password reset is disabled.
2. Authenticators, such as password or 2FA, cannot be changed or added.
3. The primary email address cannot be changed.
4. While secondary email addresses can be added, they cannot be elevated to the primary email address.