SSO vs Per-App Auth

SSO simplifies. The decision.

SSO

Single Sign-On is the architectural decision to centralize authentication for every application a user touches. The user authenticates once at the identity provider; that authentication grants access to every application the user has been provisioned into. The alternative (per-application accounts) creates a lifecycle nightmare and a security posture that does not survive scale.

What SSO actually offers:

• Single auth source.: The Identity Provider (Okta, Azure AD, Google Workspace, JumpCloud, AWS IAM Identity Center) holds the authoritative user database. Every application checks identity against the IDP rather than maintaining its own. The user's credentials live in one place; the place is the IDP.
• Easier user lifecycle.: When an employee joins, they are provisioned in the IDP; the IDP propagates to every application via SCIM (System for Cross-domain Identity Management). When they leave, deprovisioning happens at the IDP and propagates everywhere. The "deprovisioned in 5 systems but still has access to 12 others" scenario disappears.
• Centralized MFA enforcement.: MFA is enforced at the IDP. Every application benefits without each having to implement MFA separately. Strengthening MFA (moving from TOTP to FIDO2 hardware keys) happens once at the IDP layer; every application inherits the strength.
• Standard for enterprise.: Enterprise customers expect SSO. Integrating with their IDP via SAML or OIDC is part of being enterprise-ready. Vendors that do not support SSO lose enterprise procurement decisions; vendors that do support it gain pricing leverage.
• Better audit trail.: Authentication events are logged in one place. When investigating account access, the IDP audit log is the source of truth. Compared to chasing logs across many applications, the centralized log is dramatically more useful.

SSO is the modern default. The cases where it does not apply are exceptions that need explicit justification, not a default the team can drift into.

Per-app

Per-application authentication is the legacy pattern: each app has its own account database, its own login form, its own password policy. This was the dominant pattern through roughly 2010 and remains in some legacy contexts. The pattern's limitations have become severe enough that most organizations are actively migrating away from it.

• App-specific accounts.: Each app maintains its own user database. Users have separate credentials per app. Password reuse is rampant; password fatigue is real; account hygiene varies wildly across apps.
• Limited integration with org-level identity.: When an employee leaves, the team has to remember to deprovision them from each app. The list of apps is rarely complete; deprovisioning rarely happens fully. Ex-employees retain access to apps for months or years after departure.
• Niche, legacy, mostly being replaced.: Per-app auth is the model for tools that were built before SSO was common, that have not been updated to support it, or that operate in contexts where SSO is genuinely not applicable. Each is a special case.
• Specific persisting use cases.: Some legitimate cases remain: tools that authenticate machines rather than users, tools that operate in air-gapped environments, third-party tools your team does not control. The use cases are bounded; treating them as the default is wrong.
• MFA enforcement is per-app.: Each per-app account has its own MFA setting. Ensuring MFA is enabled across all apps becomes a manual audit. The IDP-centralized model makes this trivial; the per-app model makes it gatewayed by manual discipline.

Per-app authentication is the pattern to retire as quickly as possible. The remaining instances are exceptions that require justification.

Decide

The decision is not "pick one"; it is "default to SSO; treat per-app as exception." Most apps in a modern environment can integrate with SSO; the exceptions need explicit handling.

• SSO for everything possible.: Every app that supports SSO integration is integrated. The migration may be incremental, but the direction is clear: each app moves to SSO. Apps that cannot be migrated get an explicit "no SSO supported" tag and a documented reason.
• Per-app only for unsupportable cases.: Some apps genuinely cannot integrate with SSO. Internal tools without SSO support, third-party tools that do not offer SSO at the team's pricing tier, legacy systems that cannot be modified. The exceptions are documented, reviewed periodically, and gradually retired or replaced.
• Migration is worth the effort.: The cost of migrating an app from per-app auth to SSO is real (technical work, user retraining, occasional brief disruption). The benefit is permanent: every future security improvement at the IDP layer benefits the migrated app. The investment compounds.
• Centralized auth for service accounts too.: The same logic applies to machine-to-machine authentication. Workload identity systems (IRSA, GCP Workload Identity, OIDC federation) replace per-service credentials with centralized identity. The principle generalizes from human users to workloads.
• Audit progress over time.: Track the percentage of apps integrated with SSO. Track the percentage of users authenticated via SSO across all apps they use. The trajectory is the leading indicator of whether the migration is actually progressing or has stalled.

SSO versus per-app auth is a one-sided decision in 2026: SSO wins almost everywhere; per-app survives only as an exception. Nova AI Ops integrates with the IDP audit stream, surfaces apps that have drifted away from SSO authentication, and tracks the migration progress so the team can see whether the centralization discipline is holding.