Authenticating users
At Stonal, we use a dedicated service for identity management.
We support only the OpenID Connect (OIDC) protocol for authentication.
Authentication
Workflow
We use authorization_code grant type flow for OIDC authentication.
Description
All Stonal APIs are protected by authentication and authorization mechanisms.
By default, our platform frontend fetches the user connected authorization through an internal API Gateway. The API Gateway is responsible for checking if current user is connected via a secured cookie.
Depending on whether the user is connected, the API Gateway will use the access and refresh tokens (JWT tokens) stored alongside with the cookie in a private data store to fetch the user connected authorizations and access Stonal private APIs.
If the user is not connected, the API Gateway will redirect the user to our SSO service to authenticate. When authenticated, our SSO service will redirect the user back to the API Gateway with an authorization code which will be exchanged for an access token and a refresh token associated with the user and stored in the private data store alongside with the cookie.
Be aware, users account need to be created before users can authenticate through the SSO.
Go to Managing users for more information.
Identity delegation
We support identity delegation using OIDC protocol.
When we add a new identity provider, we will proceed as follows:
- SSO: We save a new identity provider for the customer (we call it
organization) that would like to use their own identity management system. (eg:orga) - Customer Identity System: Customer creates a new client (usually customer called it
stonal) OIDC protocol.
The customer will provide us the following information:
discovery endpoint: The identity provider standard OIDC discovery endpoint,client_id: The client ID associated with client created on the customer identity system for our SSO,client_secret: The client secret of the client created on the customer identity system for our SSO.
We only need one required information to be present in identity provider token response: email claims in payload.
We provide the following information to the customer:
redirect_uri: The redirect URI of the client created on the customer identity system that will redirect to our SSO.
At the end, we will provide the final link to our customer to be used if they want their user to be authenticated though their own SSO.
Our customers includes this link into their own portal.
This step requires usually a small meeting between our technical team and the customer technical team.