Skip to main content

OIDC IDP Provider Setup

Overview​

Use this guide to configure both Multi-Tenant and Single-Tenant OIDC providers for SSO to the Atria platform. Multiple provider types can be configured per customer, allowing you to support different identity requirements within the same hierarchy. You can also set a new default provider to replace the traditional AD username/password authentication path for that scope.

Before You Start​

Use this section to collect the exact provider values needed for a successful first-time setup. Having these inputs prepared in advance reduces save-time validation errors and callback failures during testing.

From your IdP admin console, collect:

  • Well-known URL (for example, for a Multi-Tenant Microsoft Configuration https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration)
  • Client ID and Client Secret
  • Registered redirect URIs:
    • https://{AtriaWeb}}/oidc/callback
    • https://{AtriaWeb}/oidc/link/callback

Decide upfront:

  • Provider display name and optional icon URL
  • Claim used for auto-linking (for example email or upn)
  • Atria user property used for matching

Provider Type Setup​

Use the tabs below to apply the correct configuration model for your tenant design. The only intended difference is scope and issuer behavior, while the core provider fields remain the same.

  1. Go to Customer > Identity Provider Configurations.
  2. Click Add.
  3. Set Access Level to Current Customer.
  4. Enable Default only if this customer should always use this provider.
  5. Enter Display Name, Client ID, Client Secret, and Well-known Endpoint.
  6. Wait for well-known validation (cloud checkmark) and select scopes.
  7. Optional: enable auto-linking and set OIDC Claim + User Property.
  8. Save the provider.

Issuer guidance:

  • Prefer Exact mode for single-tenant issuers.
  • Use Regex only when issuer format requires pattern matching.

Authentication Provider Settings Reference​

This reference explains what each setting controls in the provider editor. Use it to align IdP configuration values with their runtime behavior in Atria login.

Definitions of Properties
SettingPurpose
Display NameName shown on the login screen. Must be unique per customer scope.
Wellknown EndpointOIDC discovery endpoint used to fetch endpoints/scopes/claims. Must be HTTPS and reachable.
Client IdOIDC client identifier from your IdP app registration.
Client SecretSecret used when exchanging authorization codes for tokens; stored securely.
IconPublicly accessible URL for login button icon.
DefaultEnforces this authentication method for all login attempts for users of that IdP type; other providers are effectively blocked for that scope. See warning below.
Access LevelControls exposure: Current Customer or Current and All Sub-Customers.
OIDC ClaimsClaim used for auto-linking (for example email, upn).
User PropertiesAtria user field mapped to the selected OIDC claim.
ScopesRequested scopes used for token retrieval and claim availability (openid plus optional scopes).
Issuer Validation ModeExact requires exact issuer match; Regex allows multi-tenant pattern matching.
IssuerRequired when mode is Exact. Pre-filled from discovery where available.
Issuer Regex PatternRequired when mode is Regex; full-string matching is enforced.
Enable Auto LinkingAllows sign-in without manual account linking by mapping claim to user property.
danger

If this provider is set as Default and the OIDC connection fails or is misconfigured, users for that scope may be unable to log in to the portal and support intervention will be required.

If this occurs, contact Atria Support: Contact Support

Validation and UI Messages​

These are the most common validation and save-time messages shown in the provider editor. Use them to identify whether an issue is input formatting, provider metadata, or required-field enforcement.

MessageMeaning / Action
A provider with the specified name already exists.Choose a unique Display Name.
Failed to save the provider.Save operation failed; check configuration and retry.
Unable to save. The wellknown endpoint failed to load dataDiscovery endpoint failed validation or retrieval.
The wellknown endpoint must use HTTPS.Update endpoint to https://....
A client secret is required for providers that support the authorization code flow.Provide Client Secret before save.
Issuer is required when issuer validation mode is Exact.Populate Issuer.
Issuer regex pattern is required when issuer validation mode is Regex.Populate regex pattern.
Issuer regex pattern is invalid.Fix regex syntax.
Select an OIDC claim to enable auto-linking.Choose an OIDC Claim when auto-linking is enabled.
Select a user property to enable auto-linking.Choose a User Property when auto-linking is enabled.
This provider does not advertise supported claims...Enter claim manually (for example email, upn).

Validate the Setup​

Use this validation sequence to confirm the provider is visible, routable, and authenticating correctly for the intended scope. This is the minimum go-live check before enabling broad user access.

  1. Open login with a known customer user.
  2. Confirm provider visibility aligns with configured Access Level.
  3. If provider is default, confirm automatic redirect behavior.
  4. Complete sign-in and verify first login links subject to user.

Use the following pages for operational management and incident handling after initial setup.