SaaS authentication exposes the governance gaps IAM teams miss

At a glance

What this is: This guide explains how SaaS authentication should balance user experience, tenant isolation, MFA, API security, and delegated administration.

Why it matters: It matters because identity teams have to govern human access, NHI-backed APIs, and tenant-specific controls as one authentication surface, not three separate problems.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Descope's guide to SaaS authentication strategy and implementation

Context

SaaS authentication is the control layer that verifies users, service calls, and delegated admin actions before they reach tenant data and functionality. In a B2B SaaS model, that layer has to do more than log users in, because it also enforces tenant separation, supports federated access, and protects APIs that often carry identity assertions and tokens.

The governance gap appears when authentication is treated as a feature instead of an identity boundary. Once a platform supports SSO, MFA, JIT provisioning, and embedded admin workflows, the question shifts from login convenience to how access is issued, scoped, logged, and revoked across tenants and connected systems.

That is the right framing for human IAM, but it also matters for NHI-backed API traffic and workload identities behind the scenes. Authentication mistakes in SaaS rarely stay local, because weak tenant isolation or broad token scope can turn a single access path into cross-customer exposure.

Key questions

Q: How should security teams design authentication for multi-tenant SaaS apps?

A: They should make tenant context explicit in authentication, authorization, provisioning, and admin workflows. The goal is to prevent one customer’s identity state from affecting another customer’s data or permissions. Teams also need federated login, SCIM lifecycle handling, and audit logs that all preserve tenant boundaries rather than treating them as optional metadata.

Q: Why do multi-tenant SaaS platforms need tenant-specific authentication policies?

A: Because the same platform can serve different customers with different IdPs, roles, and compliance rules. Tenant-specific policy prevents one customer’s identity configuration from bleeding into another tenant’s access decisions, which is how cross-tenant exposure starts. Shared infrastructure is acceptable only when identity evaluation remains tenant-aware.

Q: What do security teams get wrong about SSO and JIT provisioning?

A: They often assume that because the login is centralized, the resulting access is automatically safe. In reality, SSO and JIT can create broad default trust if role mapping, token scope, and tenant context are not tightly controlled. JIT should create only the access needed at first login, not permanent privilege by accident.

Q: Who is accountable when delegated service access exceeds user intent?

A: Accountability sits with the organisation that allowed the delegation model to bypass explicit policy checks. When a service acts on behalf of a user, both identities must be part of the authorization decision. If they are not, the resulting access is technically authenticated but governance-wise unsupported.

Technical breakdown

Multi-tenant authentication and tenant isolation

Multi-tenancy means one SaaS platform serves multiple customers while keeping each customer’s users, roles, and data logically separated. The authentication challenge is that the same login surface may need different identity providers, claim mappings, roles, and policy settings for each tenant. If those settings are not isolated correctly, a valid identity from one tenant can be accepted in the wrong context, which turns configuration drift into cross-tenant access. Tenant-aware auth design therefore depends on per-tenant policy enforcement, not just shared infrastructure.

Practical implication: define tenant boundaries in the identity layer and test that every token, claim, and role is evaluated in the correct tenant context.

Phishing-resistant MFA and session risk

MFA lowers account takeover risk, but the control quality depends on the factor type and the session model around it. SMS and email OTPs remain vulnerable to phishing, SIM swap, and interception, while device-bound methods such as passkeys reduce replay risk. Adaptive MFA adds context by stepping up verification when device reputation, location, or login pattern changes. The technical point is that auth strength is not just factor count, but also whether the session can be trusted after the initial prompt.

Practical implication: use phishing-resistant factors for high-value tenants and trigger step-up auth when context changes materially.

API tokens, OIDC, and least-privilege scope

Modern SaaS platforms often depend on OpenID Connect and JWT-based access tokens to move identity across services and APIs. That creates a different kind of identity problem: a token is not a user, but it can still carry broad authority across systems. Short-lived tokens, narrow scopes, audience validation, issuer checks, and refresh-token handling all matter because they limit how far a compromised token can travel. Token introspection and audit logging add the evidence needed to detect misuse after issuance.

Practical implication: keep token lifetime short, scope access narrowly, and verify that audience and issuer controls block token reuse outside the intended service.

Threat narrative

Attacker objective: The attacker wants to turn one valid authentication path into broader tenant access, data exposure, or administrative control across connected SaaS workflows.

1. entry occurs when an attacker abuses weak SaaS authentication paths such as phishable MFA, overbroad tokens, or misconfigured tenant trust to obtain a valid session or API token.
2. escalation happens when that identity is accepted across tenants, delegated admin workflows, or connected services because authorization scope was broader than the original login context.
3. impact follows when the attacker uses that access to read tenant data, manipulate user lifecycle actions, or move laterally through APIs that were never meant to share the same trust boundary.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication is becoming a governance boundary, not a UI concern. SaaS teams still talk about login design as if it were separate from identity governance, but multi-tenancy, delegated administration, and API authorization all converge in the auth layer. That means authentication now defines who can act, in which tenant, and with what traceability. Practitioners should treat auth architecture as a control plane for identity, not a front-end convenience feature.

Tenant isolation fails when auth state is reused too broadly. Per-tenant IdP connections, custom roles, and delegated admin are useful only if the tenant context survives every token, claim, and session transition. This is where many SaaS implementations drift into implicit trust, because once a user is authenticated the platform assumes the rest of the journey is safe. The more connected the platform becomes, the more dangerous that assumption gets.

Phishing-resistant MFA is necessary, but it does not solve lifecycle scope. Passkeys and device-bound authenticators reduce account takeover risk, yet they do not fix overprivileged tokens, stale sessions, or weak offboarding of tenant admins. That is why authentication and lifecycle governance have to be viewed together. If the same identity can continue to act long after the original trust decision, MFA alone is only partial control.

Named concept: tenant trust spillover. This occurs when a SaaS platform allows identity decisions made for one tenant, user, or session to influence access in another context. The problem is not just misconfiguration, but the assumption that authentication events can be safely reused across a shared environment. Practitioners should audit where trust decisions persist beyond the tenant boundary.

Delegated administration increases the need for identity evidence. Self-service user management and per-tenant policy control reduce operational burden, but they also increase the number of actors who can shape identity outcomes inside the product. That makes logging, approval traceability, and policy inheritance essential. The governance question is no longer whether tenant admins can act, but whether their actions are observable and reversible in time.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That same governance gap is why OWASP NHI Top 10 and agentic AI identity guidance need to be applied before auth sprawl becomes policy debt.

What this signals

Tenant trust spillover: SaaS teams should look for places where one authentication event can influence more than one tenant, session, or delegated workflow. That is the point where identity decisions stop being local and start becoming systemic.

Authentication governance is converging with workload identity governance because API tokens, JIT provisioning, and delegated admin all extend the same trust model beyond the browser. If the programme cannot explain where trust starts, where it ends, and how it is revoked, it is not ready for scale.

With 98% of companies planning to deploy even more AI agents within the next 12 months, identity teams should expect SaaS auth flows to be reused by non-human actors more often. The practical response is to tighten claims, shorten sessions, and make tenant context explicit at every hop.

For practitioners

• Enforce tenant-bound identity evaluation Verify that tokens, roles, and claims are evaluated inside the correct tenant context at every access decision. Test cross-tenant boundary cases, especially where a single IdP or shared admin workflow exists.
• Replace phishable MFA paths on high-risk flows Use passkeys or other device-bound authenticators for admin, support, and tenant-owner access. Reserve weaker fallback methods for low-risk recovery paths and monitor their use closely.
• Shorten token lifetime and narrow token scope Issue access tokens with the least privilege required, keep expiration tight, and validate audience and issuer claims before any downstream service accepts them.
• Log delegated admin and JIT provisioning actions Capture who changed roles, who approved access, which tenant was affected, and when the change was revoked so lifecycle events can be reconstructed after an incident.
• Review offboarding for shared SaaS access paths Confirm that leaving a tenant, role change, or vendor relationship actually removes access from embedded widgets, support tooling, API keys, and cached sessions.

Key takeaways

• SaaS authentication is now a cross-tenant governance control, not just a login mechanism.
• Phishing-resistant MFA helps, but tenant isolation, token scope, and offboarding determine whether access stays bounded.
• Identity teams should treat delegated administration and API tokens as part of the same auth boundary as human logins.

Key terms

• Tenant Trust Spillover: A failure mode where an authentication decision made for one tenant, user, or session influences access in another context. In SaaS environments, this usually appears when shared tokens, broad claim mappings, or reused session state weaken the logical boundary between customers.
• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Delegated administration: Delegated administration allows local operators to make approved configuration changes without waiting on a central platform team. It improves speed, but it only remains safe when permissions are narrow, changes are logged, and validation prevents policy drift.
• Just-in-Time Provisioning: Just-in-time provisioning creates an account or entitlement at the moment it is needed, then removes it later. It reduces standing access duration, but it still relies on a static identity or role existing during the access window, which leaves room for misuse if revocation lags.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on implementing SSO, MFA, and JIT provisioning in SaaS environments.
• Vendor-specific examples of delegated administration widgets and tenant-level policy setup.
• Practical implementation tips for token handling, session duration, and user lifecycle workflows.
• Integration considerations for teams choosing between build and buy for customer identity.

👉 The full Descope post covers authentication methods, tenant administration, and implementation trade-offs in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.