SaaS authentication becomes expensive when every service carries its own customer-specific logic. One API checks a local user table. Another understands a specific enterprise identity provider. A portal keeps a separate mapping for groups, roles, or tenant keys. It may work for the first customers, but it creates an awkward question for every new enterprise onboarding: which parts of the application have to change before this customer can log in?
That is the wrong place for authentication variance to live. In a multi-tenant SaaS architecture, applications should have one trust relation to the identity platform. Customer-specific federation, tenant routing, and claim normalization should sit behind that boundary.
For ProAuth, that boundary is the ProAuth identity provider. Applications integrate with ProAuth through OpenID Connect and OAuth 2.0. ProAuth then handles the tenant-specific identity configuration behind the scenes: federated IdPs, tenant isolation, runtime configuration, and the claim rules needed to issue predictable tokens to applications.
The cost of scattered authentication
Most SaaS products do not start with scattered authentication on purpose. The shape appears over time.
A first customer may use the built-in user store. A larger customer may ask for federation to its corporate directory. Another customer may require a different identity provider, a different set of claims, or a tenant-specific login route. If each request produces application code, the SaaS platform starts to encode customer identity differences in places that should only know business behavior.
That creates operational friction:
- application deployments become part of customer onboarding
- service teams need to understand provider-specific claim formats
- tenant-specific branches make test coverage harder to reason about
- changes to one customer’s identity setup can affect services that should not care about it
The issue is not federation itself. Federation is useful because customers can keep their existing identity systems. The issue is letting every application and service become a small federation gateway.
One issuer for applications
A cleaner architecture gives the SaaS application one issuer to trust. The application validates tokens from ProAuth and treats ProAuth as the identity boundary. ProAuth is responsible for reaching the right upstream identity provider, applying the right tenant configuration, and issuing tokens with the claims the application expects.
flowchart LR
user["User"]
subgraph apps["SaaS application boundary"]
portal["Portal"]
api["Backend APIs"]
jobs["Worker services"]
end
proauth["ProAuth identity provider"]
subgraph tenants["Tenant-specific identity configuration"]
tenantA["Tenant A federation"]
tenantB["Tenant B federation"]
tenantC["Tenant C user store"]
end
idpA["Customer A IdP"]
idpB["Customer B IdP"]
storeC["Managed users and groups"]
user --> portal
portal --> api
api --> jobs
apps -->|"single trust relation"| proauth
proauth -->|"resolve tenant"| tenants
tenantA --> idpA
tenantB --> idpB
tenantC --> storeC
proauth -->|"normalized tokens"| appsThis does not remove the need for careful application authorization. Services still need to validate tokens, check audiences, and make their own authorization decisions. The important shift is that applications no longer need to know how each tenant authenticates its users.
That separation keeps the application contract stable. A new customer can bring a federated IdP without forcing every service to learn that provider’s metadata, claim names, or onboarding process. The application keeps speaking OIDC/OAuth to ProAuth.
Tenant isolation belongs in the identity layer
Multi-tenancy is more than a tenant ID in a database table. During login, ProAuth has to route the user into the right tenant context before the authentication pipeline can make the right decisions.
ProAuth supports tenant identification patterns such as tenant-specific routes, tenant-specific subdomains through redirect URI placeholders, IP address ranges for internal tenants, and OIDC authentication request parameters with acr_values. The earlier tenant identification post gives a deeper walkthrough of those options: How we identify tenants to provide a tailored authentication experience.
Once the tenant is known, ProAuth can use tenant-specific configuration. That matters because a tenant should not see or use another tenant’s identity providers. In practical SaaS terms, Customer A’s users should be routed to Customer A’s directory, while Customer B’s users are routed to Customer B’s directory, even though both customers use the same SaaS application.
Putting that isolation into the identity layer keeps tenant routing out of the application code path. The application asks ProAuth to authenticate the user. ProAuth resolves the tenant and applies the correct identity configuration.
Federation should not leak provider differences into services
Enterprise customers rarely agree on a single identity shape. Some use Azure AD. Some use ADFS. Some use another OIDC provider. Claims may differ in names, formats, group structures, or availability.
If those differences reach the SaaS services directly, every service becomes more brittle. A billing API should not need to know whether a customer’s directory emits email, mail, upn, or a custom claim. It should receive a stable identity contract.
ProAuth handles that through claim normalization. Claims from ProAuth and claims from federated identity providers can be processed before tokens are issued. The Claim Rule Engine can filter claims, transform claim types or values, create claims, and define whether a claim belongs in the ID token, the access token, or both. Claim rules can be associated at different levels, including subscription, tenant, client application, and combinations of client applications and IdP instances.
That gives platform teams a place to absorb identity-provider differences without spreading those differences across application services. The token contract stays intentional: applications receive the claims they need, in the shape they expect, from the issuer they trust.
Runtime configuration changes onboarding
Customer onboarding should not require a platform redeployment just because the customer needs a federated IdP or a tenant-specific login route. ProAuth is designed for runtime configuration through the Admin Application, Management API, and CLI. That includes tenant setup, identity provider configuration, and related tenant-specific authentication behavior.
This changes the operating model. Instead of opening an application release for every new identity setup, teams can automate onboarding around ProAuth configuration:
- create or update the tenant
- register the tenant-specific identity provider
- configure tenant routing through the selected identification pattern
- apply claim rules for the application’s identity contract
- validate login with the customer before broad rollout
The application still needs to be designed for multi-tenancy. It must make authorization decisions correctly and keep tenant data isolated. But the mechanics of authenticating through each customer’s chosen identity provider can move into the identity platform, where they belong.
A review checklist for SaaS teams
When reviewing a SaaS authentication architecture, these questions expose whether the trust boundary is clean:
- Do applications trust one issuer, or do they each understand multiple customer IdPs?
- Can a new tenant IdP be configured without redeploying application services?
- Is tenant identification handled before authentication reaches the customer-specific pipeline?
- Are upstream claims normalized before services consume them?
- Can claim behavior vary by tenant, client application, or IdP instance without service-specific code?
- Is there a clear line between authentication handled by ProAuth and authorization handled by the application?
The best answer is not “all identity logic belongs outside the application.” Applications still own application authorization. The better boundary is narrower and more useful: customer-specific authentication belongs in the identity platform, while applications consume a stable token contract from a single trusted issuer.
That boundary is what keeps SaaS identity manageable as customers, tenants, and services grow.
For more on the SaaS scenario, see the ProAuth SaaS software page, or contact us if you are reviewing the identity boundary in your own platform.