Skip to main content

Authentication Patterns for Enterprise

SSO, MFA, OAuth, SAML. The authentication patterns that enterprise systems need and the common mistakes teams make implementing them.
10 November 2021·7 min read
John Li
John Li
Chief Technology Officer
engineeringstrategy
Authentication is the part of enterprise software that everyone assumes is solved and nobody gets right the first time. I've worked on authentication implementations for seven enterprise systems over the past three years. Every one of them had at least one significant authentication issue discovered after launch. The patterns are well-documented. The pitfalls are well-known. Teams keep falling into them because authentication looks simple until you're three weeks into an implementation and realise it isn't.

What You Need to Know

  • Enterprise authentication requirements are fundamentally different from consumer authentication
  • SSO (Single Sign-On) is the baseline expectation for enterprise software in 2021
  • MFA (Multi-Factor Authentication) is becoming a compliance requirement, not a feature
  • The most common mistakes are in session management and token handling, not in the authentication protocol itself

Enterprise vs Consumer Authentication

Consumer applications authenticate individuals. Enterprise applications authenticate individuals within an organisational context. The difference creates requirements that consumer patterns don't address:
Organisational identity. A user isn't just "john@example.com." They're a member of an organisation with specific roles, permissions, and access policies defined by their employer, not by the application.
Centralized control. When an employee leaves an organisation, their access to every enterprise application needs to be revoked from one place. The IT administrator shouldn't need to log into 30 applications to disable one person's access.
Compliance requirements. Regulated industries need audit trails of who accessed what, when. Password policies may be dictated by regulation. Session timeout policies may be mandated by compliance frameworks.
Multi-tenancy. The same application serves multiple organisations. Each organisation has different authentication requirements, different identity providers, and different compliance needs.
80%
of data breaches involve weak or stolen credentials
Source: Verizon Data Breach Investigations Report, 2021

The Patterns

SSO (Single Sign-On)

SSO allows users to authenticate once with their organisational identity provider (Azure AD, Okta, Google Workspace) and access all connected applications without re-entering credentials.
For enterprise software, SSO is table stakes. If your application requires enterprise users to create and manage a separate username and password, you've failed the first requirement. The user's organisation manages their identity. Your application should trust that identity.
Implementation: SAML 2.0 or OpenID Connect (OIDC). Both work. OIDC is newer and simpler to implement. SAML is more widely supported by legacy enterprise identity providers. Support both if your clients include large enterprises with older infrastructure.

MFA (Multi-Factor Authentication)

Something the user knows (password) plus something the user has (phone, hardware key) or something the user is (biometric). MFA is the single most effective measure against credential-based attacks.
For enterprise applications, MFA should be:
  • Enforced by the organisation's identity provider, not by your application
  • Supported natively if the application manages its own authentication
  • Configurable per-organisation (some require hardware keys, some accept SMS)
If your enterprise application stores passwords, you're probably doing it wrong. Mixing the two creates security gaps that neither team is fully responsible for.
John Li
Chief Technology Officer

OAuth 2.0

OAuth handles authorisation delegation. User A grants Application B access to Resource C. In enterprise contexts, OAuth is used for API access: a third-party integration needs to access data in your system on behalf of a user, with the user's consent and within the user's permissions.
The most common enterprise OAuth flow is the Authorization Code flow with PKCE (Proof Key for Code Exchange). It's suitable for web applications, mobile apps, and server-to-server communication.
Common mistake: using the Implicit flow. It was deprecated in the OAuth 2.1 draft because it exposes tokens in the browser URL. If your implementation uses the Implicit flow, migrate to Authorization Code with PKCE.

SAML

SAML is the older standard for SSO. It's XML-based, verbose, and complex. It's also the standard that most large enterprise identity providers support. If your clients include government agencies, financial institutions, or large corporates, SAML support is a requirement.
The SAML integration process is typically the longest part of enterprise client onboarding. Each organisation's SAML configuration is slightly different. Metadata exchange, attribute mapping, and certificate management all require back-and-forth with the client's IT team.

Common Mistakes

Session Management

The authentication protocol gets all the attention. Session management gets all the bugs. Issues I've seen in production:
  • Sessions that never expire (user stays logged in forever, even after leaving the organisation)
  • Sessions that don't propagate logout (user logs out of the identity provider but remains logged into the application)
  • Sessions stored only in cookies without server-side validation (session can't be revoked without user action)
Fix: Server-side session storage with configurable timeout. Validate the session on every request, not just on login. Implement single logout (SLO) so that an identity provider logout propagates to all connected applications.

Token Storage

JWTs stored in localStorage are accessible to any JavaScript running on the page. An XSS vulnerability gives an attacker the user's authentication token.
Fix: Store tokens in HTTP-only cookies. If you must use localStorage, implement token rotation and short expiry times. Better still, use a backend-for-frontend (BFF) pattern that keeps tokens server-side entirely.

Permission Caching

Enterprise permissions change. A user's role changes. Their department changes. They leave the organisation. If your application caches permissions at login and doesn't refresh them, a user who was removed from the organisation at 9am might still have access at 5pm.
Fix: Re-validate permissions on sensitive operations. Implement a maximum cache duration for permission data (15-30 minutes for most applications). For high-security applications, validate on every request.

Architecture Recommendation

For new enterprise applications, our standard architecture is:
  1. OIDC for SSO with SAML fallback for legacy providers
  2. Backend-for-frontend (BFF) pattern for token management
  3. Server-side session storage with configurable timeout
  4. Permissions fetched from the identity provider on login and refreshed periodically
  5. Audit logging for every authentication event
This pattern handles most enterprise requirements without custom authentication code. The identity provider handles authentication. The BFF handles tokens. The application handles authorisation based on the identity provider's claims.
Don't build authentication from scratch. Use your platform's established libraries and integrate with established identity providers. The creativity should be in your application, not in your login flow.