Authentication Configuration

Conncentric authenticates Portal users via OIDC (OpenID Connect). You register an application with your identity provider, then configure the provider details in two sections of your values.yaml: security.* (backend JWT validation) and portal.auth.* (frontend OIDC login flow).

What to configure

Both sections must reference the same OIDC provider. The security section controls how the Orchestrator validates JWT tokens from API requests. The portal.auth section controls how the Portal (running in the user's browser) initiates the OIDC login flow.

Values section	What it controls
security.provider	Provider identifier (must match portal.auth.provider)
security.jwt.issuerUri	OIDC issuer URI for backend token validation
security.jwt.audience	Expected audience claim (provider-dependent)
portal.auth.provider	Provider identifier (must match security.provider)
portal.auth.authority	OIDC issuer URL for the frontend login redirect
portal.auth.clientId	OAuth2 client ID for the Portal SPA
portal.auth.scope	OIDC scopes to request
portal.auth.redirectUri	Portal URL registered as the redirect URI
portal.auth.audience	Audience claim (provider-dependent)

See Helm Reference for the full list of authentication-related values.

The redirect URI

The single most common setup failure is a mismatched redirect URI. Get this right before configuring anything else.

The redirect URI is your Portal's root URL, the same address users open in their browser. It is not a /callback or /auth/callback sub-path. The Portal completes the login at its own root and reads the result there.

You set this value in two places, and they must be identical:

1. portal.auth.redirectUri in your values.yaml.
2. The list of allowed redirect (callback) URLs registered with your OIDC provider.

The provider compares the two with an exact string match. Each of the following differences produces a redirect_uri mismatch error at login, even when the two URLs look almost the same:

Difference between the two values	Still matches?
A trailing slash on one but not the other	No
Different scheme (http vs https)	No
An explicit port (such as :443) added to one	No
An extra path segment added to one	No

caution

The same root URL is also where users land after signing out. Register it as an allowed logout (sign-out) URL in your provider, in addition to the login redirect URL. These are usually two separate lists. If you register only the login URL, sign-in works but sign-out fails with a redirect error.

Provider guides

Auth0

Register the Portal as an SPA application in your Auth0 dashboard:

1. Create a Single Page Application.
2. Add your Portal URL to Allowed Callback URLs, Allowed Logout URLs, and Allowed Web Origins.
3. Create an API with an identifier (this becomes the audience value).

Values to set:

Field	Value
security.provider	auth0
security.jwt.issuerUri	https://your-tenant.auth0.com/
security.jwt.audience	https://your-api-identifier
portal.auth.provider	auth0
portal.auth.authority	https://your-tenant.auth0.com/
portal.auth.clientId	Your SPA client ID
portal.auth.scope	openid profile email
portal.auth.redirectUri	Your Portal URL
portal.auth.audience	https://your-api-identifier

Okta

Register the Portal as an OIDC application in Okta:

1. Create a Single-Page Application (SPA). This issues a public client that uses PKCE and no client secret.
2. Add your Portal URL to both Sign-in redirect URIs and Sign-out redirect URIs.
3. Under Security > API > Trusted Origins, add your Portal URL as a CORS trusted origin so the browser can complete the token exchange.
4. Note the issuer URI (usually https://your-tenant.okta.com/oauth2/default).

Values to set:

Field	Value
security.provider	okta
security.jwt.issuerUri	https://your-tenant.okta.com/oauth2/default
security.jwt.audience	Leave empty (Okta does not require audience for default authorization server)
portal.auth.provider	okta
portal.auth.authority	https://your-tenant.okta.com/oauth2/default
portal.auth.clientId	Your SPA client ID
portal.auth.scope	openid profile email offline_access
portal.auth.redirectUri	Your Portal URL
portal.auth.audience	Leave empty

Azure Entra ID

Register the Portal as a Single-page application in Azure:

1. In App Registrations, register an application and add a Single-page application platform under Authentication. Use the SPA platform (not Web) so the client uses PKCE with no secret.
2. Add your Portal URL as a redirect URI under that SPA platform. Azure reuses the registered redirect URIs for post-logout returns, so this one entry covers both sign-in and sign-out (there is no separate logout URL list).
3. Under Expose an API, create a scope (e.g., access_as_user).

Values to set:

Field	Value
security.provider	entra
security.jwt.issuerUri	https://login.microsoftonline.com/{tenant-id}/v2.0
security.jwt.audience	Leave empty
portal.auth.provider	entra
portal.auth.authority	https://login.microsoftonline.com/{tenant-id}/v2.0
portal.auth.clientId	Your SPA client ID
portal.auth.scope	openid profile email api://{client-id}/access_as_user
portal.auth.redirectUri	Your Portal URL
portal.auth.audience	Leave empty

The placeholders: {tenant-id} is your Entra directory (tenant) ID and {client-id} is the application (client) ID of the app registration you created above (the same value as portal.auth.clientId). See Microsoft's app-registration documentation for where these appear in the portal.

AWS Cognito

Register the Portal as an app client in your Cognito User Pool:

1. Create an App client with no client secret (public SPA client).
2. Configure the Portal URL as an allowed callback URL and logout URL.
3. Note the User Pool issuer URI (usually https://cognito-idp.{region}.amazonaws.com/{user-pool-id}).

Values to set:

Field	Value
security.provider	cognito
security.jwt.issuerUri	https://cognito-idp.{region}.amazonaws.com/{user-pool-id}
security.jwt.audience	Leave empty (Cognito access tokens do not include an audience claim)
portal.auth.provider	cognito
portal.auth.authority	https://cognito-idp.{region}.amazonaws.com/{user-pool-id}
portal.auth.clientId	Your app client ID
portal.auth.scope	openid profile email
portal.auth.redirectUri	Your Portal URL
portal.auth.audience	Leave empty

The placeholders: {region} is the AWS region hosting the pool (for example us-east-1) and {user-pool-id} is the pool's ID (format region_XXXXXXXXX). Both identify the pool you created above, and the issuer URI in step 3 combines them. See the AWS Cognito documentation for where to read them.

Other OIDC providers

Any standards-compliant OIDC identity provider works, even without a dedicated guide above. Use the provider's discovery document to find the values it needs:

1. Fetch the provider's discovery document at https://<provider-base-url>/.well-known/openid-configuration. The issuer value in that JSON is your issuer: set it as both security.jwt.issuerUri and portal.auth.authority.
2. Register the Portal as a public single-page (PKCE) client with no client secret, and use the resulting client ID as portal.auth.clientId.
3. Set portal.auth.scope to the scopes your provider requires. openid profile email is the common baseline; add any provider-specific scope needed to obtain a token your API accepts.
4. Register the Portal root URL as the exact redirect (and logout) URI in the provider, and set the same string as portal.auth.redirectUri. See The redirect URI.
5. Set security.jwt.audience and portal.auth.audience only if your provider stamps an audience claim into its tokens; otherwise leave them empty.

Set security.provider and portal.auth.provider to the same identifier of your choosing (any label that identifies the provider to you); they must match each other.

Verifying configuration

After deploying with your auth settings, navigate to the Portal URL. You should be redirected to your identity provider's login page. After authenticating, you will be returned to the Portal.

If the redirect fails or you see an error:

Symptom	Likely cause	Action
Browser shows "redirect_uri mismatch"	The redirect URL registered in the provider is not byte-for-byte identical to portal.auth.redirectUri	Register the Portal root URL exactly as set in portal.auth.redirectUri. Check for a trailing-slash difference, a wrong scheme (http vs https), or an accidental /callback path. See The redirect URI.
Sign-out fails or lands on a provider error page	The Portal root URL is not registered as an allowed logout (sign-out) URL	Add the Portal root URL to the provider's logout / sign-out redirect URLs. In most providers this is a separate list from the login redirect URLs.
Browser shows "invalid_client"	Wrong clientId	Confirm portal.auth.clientId matches the application registered in your provider
Portal loads but API calls return 401	security.jwt.issuerUri does not match portal.auth.authority, or the token's audience does not match security.jwt.audience	Confirm both issuer values point to the same provider. If you set security.jwt.audience, confirm it matches the API identifier the provider stamps into the token's aud claim; clear it if your provider does not issue an audience. Check Orchestrator logs for JWT validation errors.
Login page never appears	authority URL is unreachable from the user's browser	The OIDC issuer must be reachable from the browser, not just from inside the cluster. Test by opening the issuer URL directly in a browser.