OpenID Connect

OpenID Connect (OIDC) lets Parseable delegate user sign-in to an identity provider while keeping Parseable roles and permissions in control of what each user can access after login. Teams usually use it when they already manage users in systems such as Auth0, Okta, Azure AD, Google Workspace, Keycloak, or Authentik.

Parseable connects to the identity provider through OIDC discovery. The provider must expose its metadata at a discovery URL such as https://identity-provider.example.com/.well-known/openid-configuration. Parseable uses that metadata to find the authorization, token, userinfo, logout, and JWKS endpoints required for the login flow.

Prerequisites

Before you start, keep these values ready:

• A Parseable instance with admin access.
• A public HTTPS URL for Parseable, for example https://demo.parseable.com.
• An OIDC client or application created in your identity provider.
• The OIDC client ID, client secret, and issuer URL.
• A redirect URI registered in the identity provider as <parseable-instance-url>/api/v1/o/code. For example, when Parseable is hosted at https://demo.parseable.com, register https://demo.parseable.com/api/v1/o/code.
• A default OIDC role in Parseable, or OIDC group claims that match role names already created in Parseable.

If you use group-to-role mapping, make sure your identity provider includes the groups claim in the ID token. Parseable reads those group values and matches them with roles created in Parseable.

Environment Variables

Set the following environment variables on the Parseable node that serves the Console and login endpoints:

Kubernetes with Helm chart 3.0.0 and later

Helm chart 3.0.0 and later configures environment variables per Parseable node. Add the OIDC variables to the node that serves the Console and login endpoints. The global parseable.env value used by chart 2.x is no longer supported.

Keep the values file containing P_OIDC_CLIENT_SECRET secure and do not commit it to source control.

Standalone OSS

parseable:
  standalone:
    unified:
      env:
        P_OIDC_CLIENT_ID: "<client-id>"
        P_OIDC_CLIENT_SECRET: "<client-secret>"
        P_OIDC_ISSUER: "https://identity-provider.example.com"
        P_ORIGIN_URI: "https://logs.example.com/"

Distributed OSS

The querier serves the Console and login endpoints:

parseable:
  distributed:
    querier:
      env:
        P_OIDC_CLIENT_ID: "<client-id>"
        P_OIDC_CLIENT_SECRET: "<client-secret>"
        P_OIDC_ISSUER: "https://identity-provider.example.com"
        P_ORIGIN_URI: "https://logs.example.com/"

Distributed Enterprise

Prism is the public entry point in an Enterprise deployment:

parseable:
  distributed:
    prism:
      env:
        P_OIDC_CLIENT_ID: "<client-id>"
        P_OIDC_CLIENT_SECRET: "<client-secret>"
        P_OIDC_ISSUER: "https://identity-provider.example.com"
        P_ORIGIN_URI: "https://logs.example.com/"

If a reverse proxy terminates TLS, configure it to preserve the original host and protocol headers. P_ORIGIN_URI must be the same public HTTPS URL that is used to register the redirect URI in the identity provider.

Privilege Management with OIDC

After a user signs in through OIDC, Parseable still needs to decide what that user can do. You can handle this in two ways:

• Set a default OIDC role for new OIDC users.
• Map OIDC groups from the identity provider to Parseable roles.

The group-to-role path is useful when your identity provider already manages teams such as platform, security, or support. The default role path is useful when every OIDC user should start with the same baseline access.

Assign default role to any new OIDC user

Users receive the default OIDC role when they are not part of any mapped group, or when their OIDC groups do not have matching roles in Parseable.

To set a default OIDC role:

1. Log in to Parseable as an admin.
2. Open Users from the left navigation.
3. Create a role with the privileges you want new OIDC users to receive.
4. Click Set Default OIDC Role.
5. Select the role you created and save the setting.

Once this is set, new OIDC users who do not match a group-specific role will be assigned this default role at login.

Multi-Role Support

Parseable can assign multiple roles to the same OIDC user. This is useful when a user belongs to more than one team or needs access to different datasets with different permissions.

For example:

• A platform user can have writer access on one dataset and reader access on another.
• A support user can receive read access across selected datasets without manual user-by-user setup.
• The same role assignments are respected by both the UI and API.

Map user groups to roles on Parseable

To map OIDC groups to Parseable roles, create roles in Parseable with the same names as the group values sent by your identity provider. For example, if the ID token contains a group named platform-admins, create a Parseable role named platform-admins.

You can create roles from the Parseable UI or through the create role API. Once the roles exist, users can sign in with SSO and Parseable will apply the matching role permissions during login.

Per-user customization is not available for OIDC users. If a user needs a different permission set, create a new role and manage that assignment from the identity provider.