Authentication decisions are increasingly made by people who aren't security engineers — product managers, CTOs at smaller companies, engineering leads who inherited a system they didn't build. OAuth 2.0, MFA, SSO, OpenID Connect: the terminology is dense and the stakes are high.
This post cuts through the jargon. By the end, you'll understand what OAuth 2.0 actually does, how MFA types compare in practice, and how to make the right implementation decisions for your context — without needing to be a security specialist.
Why authentication is the most-exploited attack surface
Authentication failures account for a disproportionate share of data breaches. The reasons are predictable: weak passwords, credential stuffing from breached password databases, phishing attacks that capture session tokens, and applications that don't invalidate sessions on logout.
The good news is that the countermeasures are well-understood. OAuth 2.0 with proper implementation and MFA on all privileged accounts eliminates the vast majority of common attack vectors.
OAuth 2.0 explained without jargon
Think of OAuth 2.0 like a hotel key card system. When you check in, the hotel doesn't give you a copy of the master key — they give you a limited key card that opens only your room, and only for your stay. When your stay ends, the key card stops working.
OAuth 2.0 works the same way. Instead of sharing your credentials with every application that needs to access your data, OAuth issues limited-scope tokens that:
- Expire after a defined period
- Can be revoked without changing your password
- Can be scoped to specific resources and actions
- Can be refreshed without requiring re-authentication
The flows you actually need to understand
OAuth 2.0 defines several authorization flows for different use cases. You only need to understand two for most enterprise implementations:
Authorization Code Flow with PKCE — the correct flow for web applications and mobile apps. The user authenticates with the authorization server, receives a code, and exchanges it for tokens. PKCE (Proof Key for Code Exchange) prevents code interception attacks. Use this flow for user-facing applications.
Client Credentials Flow — for machine-to-machine communication with no user involved. A service authenticates with a client ID and secret and receives an access token. Use this for API-to-API communication.
avoid the implicit flow
The OAuth 2.0 implicit flow — where tokens are returned directly in the URL — is deprecated and insecure. If you're using it, migrate to Authorization Code + PKCE. Many security audits will flag implicit flow as a finding.
MFA: the types and when to use each
Not all MFA is equal. Here's an honest comparison:
| MFA type | Security level | User experience | When to use |
|---|---|---|---|
| SMS / text message | Low — vulnerable to SIM swapping | Easy | Better than nothing, but not for privileged accounts |
| TOTP app (Google Authenticator, Authy) | Good | Moderate — requires an app | Standard choice for enterprise applications |
| Push notification (Duo, Okta Verify) | Good — beware push fatigue attacks | Very easy | Good for high-frequency authentication |
| Hardware key (YubiKey, FIDO2/WebAuthn) | Excellent — phishing-resistant | Easy once set up | High-security contexts: admin accounts, privileged access |
| Passkeys | Excellent — phishing-resistant | Excellent | Modern applications, replacing passwords entirely |
For enterprise applications, TOTP (authenticator apps) is the practical baseline — well-understood, widely supported, and resistant to the most common attacks. For admin and privileged accounts, hardware keys or passkeys are worth the additional setup cost.
Common implementation mistakes
- Not validating token expiry on every request. Access tokens must be validated server-side on every API call, not just at login.
- Storing tokens in localStorage. Tokens in localStorage are accessible to JavaScript and vulnerable to XSS. Use httpOnly cookies for session tokens.
- Long-lived access tokens. Access tokens should expire in minutes to hours, not days. Use refresh tokens for session continuity.
- Not implementing token revocation. Users must be able to revoke all active sessions. This requires a server-side token invalidation mechanism.
- SMS MFA for high-risk accounts. SIM-swapping attacks are common and can bypass SMS MFA. Privileged accounts should use TOTP or hardware keys.
Integrating OAuth into Drupal and enterprise apps
Drupal has solid OAuth 2.0 support through the Simple OAuth module for acting as an authorization server, and the OAuth2 Client module for delegating authentication to an external provider. For enterprise SSO, the simpleSAMLphp module handles SAML integration with identity providers like Okta, Azure AD, and Ping Identity.
For new enterprise applications, we recommend building on a dedicated identity provider (Okta, Auth0, or self-hosted Keycloak for on-premise requirements) rather than building authentication logic into the application. Identity providers handle token management, MFA enrollment, and compliance reporting — problems you don't want to solve from scratch.