The Unblu Financial CLoud allows you to use single sign-on (SSO) for your agents, visitors, or both. This article describes the different mechanisms used.
Agents are typically employees of your organization. As such, their details are often already stored in a directory service or identity provider of some kind. It makes sense to leverage this fact and link authentication for the Unblu Financial Cloud to your organization’s directory service.
Unblu offers SSO based on OpenID Connect, an identity layer on top of OAuth 2.0. For each organization on the Unblu Financial Cloud, it uses a dedicated subdomain of https://unblu.cloud, e.g. https://yourcompany.unblu.cloud.
To support SSO on the Unblu Financial Cloud, your identity provider (IDP) must meet the requirements listed below.
API clients must first acquire an access token using the OAuth 2.0 Client Credentials grant type. The client should then present Unblu with a valid access token in an
Authorization: Bearer <token>HTTP header.
The access token presented must be provided as one of the following:
The user attributes of your agents must be supplied in the claims agreed upon with Unblu. If Unblu user roles are not provided in a claim, they must be managed in Unblu, e.g. via the Account Configuration interface.
We recommend that the validity of the access tokens presented to the Unblu Financial Cloud be limited to a relatively short time period, for example 1 hour.
If the initial access token obtained from your identity provider includes a refresh token, we recommend that you set its validity to 10 hours. Unblu will use the refresh token to obtain a new access token when the initial access token expires.
For visitors, the Unblu UI is typically embedded as a widget in your website. Since OpenID Connect relies on browser redirects, this means it cannot be used as the authentication mechanism without leading to a poor user experience.
Visitor SSO works as follows:
Your application must issue a JWT signed with a private key and send it to Unblu from the visitor’s browser. The corresponding public key must be accessible to Unblu in the JSON Web Key (JWK) format wrapped in a JWK Set. You can rotate the keys regularly: Unblu will attempt to load any unknown key.
Unblu sets a session cookie authenticating all requests from the visitor’s browser until either the session expires or an explicit logout occurs.
Some browsers, notably Safari, block third-party cookies. Visitor SSO must therefore run on the same second-level domain as your host application. To this end, Unblu configures a dedicated subdomain of your domain, e.g. https://unblu.yourcompany.com, in the Unblu Financial Cloud. There are two additional steps required for the subdomain to work:
You must ensure that your DNS records are set up to redirect calls to the subdomain to the Unblu Financial Cloud.
You must provide Unblu with a valid SSL/TLS certificate for the subdomain. Alternatively, the certificate may be issued by Let’s Encrypt.
An implementation tutorial with code samples is available at unblu.github.io/unblu-visitor-sso-sample.
In the example below, the
CLIENT_ID="unblu-api-access" CLIENT_SECRET="very-secret" ACCESS_TOKEN=$(\ curl -s -X POST https://idp.yourcompany.com/token \ --user $CLIENT_ID:$CLIENT_SECRET \ -H 'content-type: application/x-www-form-urlencoded' \ -d 'grant_type=client_credentials' | jq --raw-output '.access_token' \ ) echo $ACCESS_TOKEN curl -s -H "Authorization: Bearer $ACCESS_TOKEN" -v https://unblu.yourcompany.com/unblu/rest/v3/authenticator/getCompactUser