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.

API Reference

Overview of all the available parameters
apps/onyxia/values.yaml
onyxia:
  api:
    env:
      # Mandatory and no other authentication mode is currently supported.
      authentication.mode: "openidconnect"

      # Mandatory: The issuer URI of the OIDC provider.  
      oidc.issuer-uri: "..."

      # Mandatory: The client ID of the OIDC client representing the Onyxia Web Application.
      oidc.clientID: "..."

      # Mandatory: Defines which claim in the Access Token's JWT serves as the unique 
      # user identifier.  
      # This identifier must contain only lowercase alphanumeric characters and `-`. 
      # Specifically, it must comply with RFC 1123: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names
      #
      # - If your usernames already conform to this constraint, you can use 
      #   `"preferred_username"` for a more human-readable identifier.
      # - If usernames contain special characters, use another claim 
      #   such as `"sub"` (Ensure that the `sub` values comply with RFC 1123).  
      #
      oidc.username-claim: "..."

      # Optional: Defaults to `"groups"`. Defines which claim represents user groups.
      # See: https://docs.onyxia.sh/admin-doc/setting-up-group-projects
      oidc.groups-claim: "..."

      # Optional: Defaults to `"roles"`. Defines which claim represents user roles.
      oidc.roles-claim: "..."

      # Optional: Additional query parameters to append to the OIDC provider login URL.  
      # Example: If using Keycloak with Google OAuth as an identity provider, you might want  
      # to preselect Google as the login option using `"kc_idp_hint=google"`.  
      # 
      # ⚠️ This string is appended as-is. Ensure it is properly URI-encoded.  
      # If adding multiple parameters, separate them with `&`.  
      #
      # Example: `"foo=foo%20value&bar=bar%20value"`
      oidc.extra-query-params: "..."

      # Optional: Expected audience (`aud`) value in the Access Token.  
      # If set, Onyxia-API validates the `aud` claim and rejects requests
      # where it doesn’t match (or isn’t included if `aud` is an array).  
      # This setting applies only on the server side.
      # Defining it here won’t change how the OIDC client requests tokens.  
      # Refer to your provider’s documentation below for details.
      oidc.audience: "..."

      # Optional: Specifies the OIDC scopes requested by the Onyxia client.  
      # Defaults to `"openid profile"`.  
      # This is a space-separated list. `"openid"` is always requested, 
      # regardless of this setting.
      oidc.scope: "..."
      
      # Optional: Automatically logs out users after a set period of inactivity. 
      # If you are using Keycloak do not provide this value, it's inferred automatically. 
      oidc.idleSessionLifetimeInSeconds: "..."

      # Optional: The Onyxia API fetches `<issuer-uri>/.well-known/openid-configuration` 
      # to retrieve JWKs for validating Access Tokens (used as Authorization Bearers).  
      #
      # ⚠️ In development, if you lack proper root certificates, you can disable TLS verification.  
      # However, in production, it is strongly recommended to mount the correct `cacerts` instead.
      oidc.skip-tls-verify: "true|false"

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 the sub values 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.

For Onyxia, use these substitutions in the guide: <KC_DOMAIN>: 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 app

Here is an overview of what your Onyxia values.yaml should look like:

apps/onyxia/values.yaml
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: "..."
      # NOTE: By default, Access Tokens issued by Keycloak have an `aud` claim 
      # of "account". You can change this value in your protocol mapper and 
      # update this setting accordingly.  
      oidc.audience: "account"

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 client instance 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.oidcConfiguration

  • Vaultonyxia.api.regions[].vault.oidcConfiguration

  • Kubernetes APIonyxia.api.regions[].services.k8sPublicEndpoint.oidcConfiguration

Each configuration follows this structure:

type OidcConfiguration = {
    issuerURI?: string;
    clientID?: string;
    extraQueryParams?: string;
    scope?: string;
    idleSessionLifetimeInSeconds?: number;
};

If no oidcConfiguration is provided for a service, Onyxia will reuse the same access_token used for onyxia-api.

However, defining a separate OIDC client for each service is recommended to improve access control and security.

You might find it strange that Onyxia requires creating multiple OIDC clients to communicate with different resource servers (e.g. onyxia-api, minio, vault, or the Kubernetes API). You’ll typically end up with several clients such as onyxia, onyxia-vault, onyxia-minio, and onyxia-kube. At first, this can feel counterintuitive, a client ID seems like it should represent one application, not multiple variants of it.

Conceptually, a single client requesting tokens for multiple resource servers (each with its own audience and claims) would make more sense. However, Keycloak doesn’t model things that way. While Onyxia supports any OpenID Connect provider, it’s primarily designed around Keycloak’s behavior and limitations.

In Keycloak’s model, an OIDC client actually represents an application talking to a specific resource server, not just an application itself.

Example Configuration in values.yaml

onyxia:
  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-k8smust 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?