Skip to main content

Managing OIDC IDP Providers for Customers and Users

Overview​

Use this guide to manage how OIDC providers are exposed and enforced across customers and users in Atria. It helps you control login behavior by configuring defaults, access levels, inheritance, and deep-link behavior in a predictable way. The outcome is a governed authentication experience that aligns provider routing with your tenant model and support processes.

Provider Behavior in Login​

This section defines how user sign-in options change based on provider configuration state. It is useful for confirming that login UX matches the intended authentication policy for each customer.

Atria login behavior depends on configured providers:

  • No default OIDC provider: user sees password and provider buttons.
  • Default OIDC provider configured: user is auto-redirected after username/customer resolution.
  • SSO-only tenant policy: password path is blocked and SSO buttons are shown.

Deep links let you force deterministic login entry points for support, testing, and integrated portals. They are especially useful when troubleshooting provider routing and customer context resolution.

Use deep links for deterministic login paths:

  • /login?username=<user>
  • /login?customerUniqueId=<guid>
  • /login?customerUniqueId=<guid>&username=<user>

Effects:

  • Username is prefilled.
  • Customer link loads that customer provider options immediately.
  • If customer has default SSO, redirect can occur automatically on page load.

Access Level and Inheritance​

Access level controls where a provider is visible and usable in customer hierarchy. These settings are critical for preventing accidental exposure of shared providers to the wrong tenants.

For provider visibility control:

  • Current Customer: only that customer sees the provider.
  • Current and All Sub-Customers: provider is inherited to child customers.

Validation:

  1. Set Current Customer and confirm child customer does not see provider.
  2. Set Current and All Sub-Customers and confirm child customer does see provider.

Default Provider Rules​

Default behavior determines whether users are redirected directly to an IdP without choosing a method. Use these rules carefully, since defaults can override expected password-based login paths.

  • Only one default provider is kept per customer scope.
  • Setting a new default clears the previous default.

Auto Linking and Manual Linking​

Linking behavior determines how external identities are bound to Atria users over time. Understanding both paths helps with onboarding new users and handling account-mapping issues.

Auto linking:

  • On first successful OIDC login, Atria links the provider subject to user.
  • Next login can resolve through linked subject directly.

Manual linking:

  • User starts link from Change Password > Link provider.
  • User authenticates at IdP.
  • Provider shows as linked after callback completes.

Operational Test Checklist​

Use this checklist as a release gate before rolling provider changes to production users. It validates routing, sign-in outcomes, account-state handling, and linking behavior.

  1. Entry and prefill links behave as expected.
  2. Provider selection and redirect behavior matches defaults.
  3. OIDC callback returns successful sign-in.
  4. Auto-linking works on first login and repeat login.
  5. Manual linking succeeds and duplicate-link attempts are handled.
  6. MFA/locked/disabled account behaviors are enforced.

Use the following pages to configure providers and investigate failures identified during operational checks.