JWT based SSO integration

Using JWT tokens to integrate SSO without using Monterosa / Interaction SDK

SSO with JWT

If you are not using Monterosa / Interaction SDK, it is still possible to integrate SSO using JSON Web Tokens (JWT).

JWT is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This approach will require you to have a system in place that generates valid JWT and passes it to our frontends. A JSON Web Key (JWK) is also required to allow our backend to validate the JWT received. Additionally, our SDK provides a series of utilities and libraries to simplify this integration for you.

Advantages:

• Reduces the need for users to remember multiple passwords, resulting in a more seamless user experience

• The use of JWT tokens ensures that user data is encrypted and cannot be tampered with

• Our SDK simplifies the integration process for our customers

Disadvantages:

• Requires a certain level of technical knowledge to implement the system

• If your Identity Provider is not already using JWT, it may require additional development work to implement

If you want to use this approach to achieve SSO between your apps and Monterosa / Interaction Cloud, your next steps will be:

• Get in touch with Sales or your Account Manager to arrange for a solutions architect to review your identity solution. We can help avoid common pitfalls and ensure the solution is scalable. We’ll additionally ensure you receive the right level of support during all the lifecycle of this integration

• Optionally set up your IdP to issue JWT tokens that IdentifyKit can validate. This typically involves configuring your Identity Provider to use the OpenID Connect protocol and providing it with the necessary information to authenticate users and issue tokens, but the specifics on how to achieve this may vary depending on your authentication ecosystem

• Provide us a JWK key that your Identity Provider uses to sign the JWT tokens, enabling us to validate the signature present in the JWT token

• Integrate your application with Identify either via its API or using our SDK

See also our SSO Integration guidelines for more general information on this integration

JWT format support

Signature validation keys

Both asymmetric and symmetric signature algorithms are supported. Keys for both are accepted in a JWK/JWKS format according to RFC 7517. If multiple keys are supplied, each JWK and each JWT header must contain a kid claim to match the keys.

Public keys for asymmetric algorithms may be downloaded and rotated from a well-known location specified via the Studio configuration UI.

Keys for both symmetric and asymmetric algorithms may be uploaded using the Studio configuration UI.

User identifier

By default, we expect the user identifier to be supplied as a value of the sub claim. Alternatively, a non-standard claim name may be specified via the Studio configuration UI.

Token expiration time

For security reasons, we only assume the user identity is valid for the duration of the JWT validity window, which is determined using standard claims: exp (mandatory), iat (optional) and nbf (optional). If your token does not contain the exp claim or if you want to disable the expiration check for any other reason (see below) it can be done via the Studio configuration UI.

Token refresh

Token refresh is not supported out-of-the-box due to the refresh method always being implementation-specific, but the SDK comes with a comprehensive API framework designed to interop with your existing refresh mechanism.

If the SDK is not used for the SSO integration, we could either look at a custom refresh mechanism implementation or disable the JWT expiration checks via the Studio configuration UI.

Please note, that disabling JWT expiration checks may have a negative effect on the overall security of the solution, as in an unfortunate event of a JWT leakage, the token may be used to impersonate the user it has been issued for indefinitely.

Supplying the token for validation

The most convenient way to supply the JWT is by using a designated SDK API, which will also provide you with callbacks when the token expires or its validation fails for any other reason. If the SDK implementation is not feasible, the token may be supplied as a URL parameter or a cookie. The name for both may be specified via the Studio configuration UI.

Please note that the token can only be supplied via a URL parameter or a cookie at the start time only, which makes it impossible to refresh the token if it expires while the Experience is running.