Domino uses the OpenID Connect (OIDC) protocol to generate user-specific JWT tokens, or “Domino Tokens”. This Domino token is signed by Domino and made available in your Workspace, Job, or App. As this token is securely signed by Domino, it can be used to authenticate to third party resources or data sources. Additionally, this token can be used to authenticate with the Domino API.
As the token is short lived and automatically refreshed by Domino, it can be used in scenarios where you would to limit a user’s access to, for example, a data source exclusively from Domino which has security advantages over provisioning them long lived keys that can be used anywhere or by anyone.
To disable this feature, your admin must add the central configuration value
com.cerebro.domino.auth.refreshTokenInRun.enabled and set it to
false. Services must be restarted for central configuration changes to take effect. This should not require downtime.
All workspaces, runs and apps will have a Domino Token for the user that can be found at path
/var/lib/domino/home/.api/token which is indicated by environment variable
DOMINO_TOKEN_FILE. By default the Domino Token has an expiration of 5 minutes, but will be automatically refreshed throughout your workspace or job.
For example, from a workspace, you can authenticate to one of the Domino APIs with the following:
TOKEN=`cat $DOMINO_TOKEN_FILE` curl -H "Authorization: Bearer $TOKEN" $DOMINO_API_HOST/v4/users/self
Configuring a service to trust Domino’s JWT¶
Each system will have different steps for configuration but will likely require you to enter Domino’s JWKS endpoint which is
<Domino URL>/auth/realms/DominoRealm/protocol/openid-connect/certs>. For offline services, retrieve and record the JWKS data to use offline with your library. Alternatively, you can use the public key or certificate which can be found at
By default, the Domino Token contains standard claims like name, username and email, but additional custom claims can be included by adding additional mappers in the domino-play client in Keycloak. This may be useful if you intend to set up bounded claims in the system you’re integrating to. For example, you might want to only authorize users with a specific organization claim or any other SAML assertion that flows into Domino from your Identity Provider.