OpenID Connect Configuration
The installation guide explain how to set up a new Keycloak instance to enable authentication on your datalab.
However, chances are that your organization already has an existing IAM system in place. This guide covers how to integrate Onyxia with various commonly used OIDC providers, including Keycloak, Auth0, and Microsoft Entra ID.
Onyxia use Public OpenID Connect client: no client Secret.
The technical term for a public OIDC client is Authorization Code Flow + PKCE.
It's the type of client that you create for Single Page Application (SPA).
API Reference
OIDC Provider Specific Configuration Guides
Onyxia Login Theme
Each version of Onyxia ships with a custom Keycloak login theme. You can download it from the release page. Specific instructions for loading the theme in your Onyxia instance can be found in this guide.
If you are deploying Keycloak using Helm, as instructed in the installation guide, here are the relevant lines in the Onyxia-ops repository.
Choosing the Unique User Identifier Claim
Onyxia requires a unique user identifier. You must specify which claim in the Access Token should be used for this purpose.
Ideally, you can use preferred_username as an identifier, but this requires ensuring it complies with RFC 1123. This means it must contain only lowercase alphanumeric characters and -.
Since this format is restrictive, if you already have an existing user base, preferred_username may not be an option. In that case, you have two alternatives:
Define a custom claim: Configure a Keycloak mapper to generate an RFC 1123-compliant claim in the Access Token.
Use
"sub": This claim is guaranteed to be unique and always present, but ensure that thesubvalues comply with RFC 1123.
If you are starting fresh with no existing users, you can enforce a regex pattern in the User Profile Attributes to require usernames that comply with the restriction.
More details can be found in the installation guide (search for "pattern").
Configuring Keycloak
Beyond what's covered in the installation guide, if you need a more general tutorial on setting up a public Keycloak OIDC client like Onyxia, refer to the following guide. It includes a test project to validate your configuration.
auth.lab.my-domain.net
<KC_RELATIVE_PATH>: /auth
<REALM_NAME>: datalab
<APP_DOMAIN>: datalab.my-domain.net
<BASE_URL>: /
<DEV_PORT>: 5173
✅ Note that Onyxia implement an auto logout countdown that will start to display once minute befor auto logout if you configure your client as a sensible appHere is an overview of what your Onyxia values.yaml should look like:
onyxia:
api:
env:
authentication.mode: "openidconnect"
# Example: "https://auth.lab.my-domain.net/auth/realms/datalab"
oidc.issuer-uri: "https://<KC_DOMAIN><KC_RELATIVE_PATH>/realms/<REALM_NAME>"
# Example: "onyxia"
oidc.clientID: "<ONYXIA_CLIENT_ID>"
# Examples:
# `"preferred_username"` if a regex pattern is enforced for usernames.
# `"my-custom-claim"` if a custom Keycloak mapper is configured.
# `"sub"` always works and is unique.
oidc.username-claim: "..."
OIDC Configuration for Services Onyxia Connects To
Onyxia uses an OIDC client for authentication, but it also connects to other OIDC-enabled services. Each of these services can have its own OIDC configuration, allowing Onyxia to authenticate using a separate client identity.
In the region configuration, you can specify an optional oidcConfiguration object for
each service:
S3 (MinIO STS) →
onyxia.api.regions[].data.S3.sts.oidcConfigurationVault →
onyxia.api.regions[].vault.oidcConfigurationKubernetes API →
onyxia.api.regions[].services.k8sPublicEndpoint.oidcConfiguration
Each configuration follows this structure:
type OidcConfiguration = {
issuerURI?: string;
clientID?: string;
extraQueryParams?: string;
scope?: string;
audience?: string;
idleSessionLifetimeInSeconds?: number;
};If no oidcConfiguration is provided for a service, Onyxia will reuse its own OIDC client
and the same Access Token for authentication. However, it is recommended to provide
a separate client ID for each service to improve access control and security.
Example Configuration in values.yaml
values.yamlonyxia:
api:
env:
authentication.mode: "openidconnect"
oidc.issuer-uri: "https://auth.lab.my-domain.net/auth/realms/datalab"
oidc.clientID: "onyxia"
regions:
[
{
data: {
S3: {
sts: {
oidcConfiguration: {
clientID: "onyxia-minio",
}
}
}
},
vault: {
oidcConfiguration: {
clientID: "onyxia-vault"
}
},
services: {
k8sPublicEndpoint: {
oidcConfiguration: {
clientID: "onyxia-k8s"
}
}
}
}
]Ensuring Claim Consistency Across Services
When a user logs in, the OIDC provider issues an Access Token for the onyxia client.
This token includes claims such as:
{
"sub": "abcd1234",
"preferred_username": "jhondoe",
"groups": [ "funathon", "spark-lab" ],
"roles": [ "vip", "admin-keycloak" ]
}If oidc.username-claim: "preferred_username" is configured in Onyxia’s main configuration,
then all services it connects to—such as onyxia-minio, onyxia-vault, and onyxia-k8s—
must also receive Access Tokens where the preferred_username claim exists and holds the same value.
To prevent issues, all OIDC clients (onyxia, onyxia-minio, onyxia-vault, onyxia-k8s)
should be configured within the same SSO realm in your OIDC provider.
This ensures that every issued Access Token follows the same claim structure and contains
consistent values for the same user.
If you're unsure whether your setup meets this requirement, check the JWT of each Access Token issued for different clients and confirm that the claims are aligned.
Last updated
Was this helpful?