OAuth Implementation Mistakes That Get Startups Hacked

OAuth 2.0 is the industry standard for delegated authorization. Almost every SaaS product implements it, either as a provider (allowing third-party apps to access your API) or as a consumer (letting users sign in with Google, GitHub, or Slack). The protocol itself is well-designed. The implementations are where things go wrong.

Mistake 1: Not validating the redirect URI

The redirect URI is where the authorization server sends the user after they approve access. If you do not validate this URI strictly, an attacker can substitute their own URL and steal the authorization code or access token. This is the single most exploited OAuth vulnerability.

Always use exact string matching for redirect URIs. Do not allow wildcard subdomains, path prefixes, or partial matches. Register every redirect URI explicitly in your OAuth configuration. If your application needs multiple redirect URIs (for different environments or features), register each one individually.

Mistake 2: Using the implicit flow

The implicit flow was designed for browser-based applications that could not securely store a client secret. It returns an access token directly in the URL fragment. This token is visible in browser history, server logs, and referrer headers. The implicit flow is officially deprecated by the OAuth working group.

Use the authorization code flow with PKCE (Proof Key for Code Exchange) instead. PKCE works in browsers, mobile apps, and server-side applications. It prevents authorization code interception attacks and does not expose tokens in URLs.

Mistake 3: Long-lived access tokens without refresh

Some implementations issue access tokens that last for days or weeks. If one of these tokens is compromised, the attacker has extended access. Instead, issue short-lived access tokens (15 minutes to 1 hour) and use refresh tokens for long-term access. Refresh tokens should be single-use and rotated on every use.

Implement token revocation so that when a user disconnects an integration or changes their password, all associated tokens are invalidated immediately. This seems obvious but many startups skip it and only discover the gap during a security assessment.

Mistake 4: Skipping the state parameter

The state parameter prevents CSRF attacks against the OAuth flow. Without it, an attacker can trick a user into authorizing a malicious application by initiating the OAuth flow from a forged page. Always generate a random, unguessable state value, store it in the user session, and verify it when the callback is received.

Mistake 5: Insufficient scope validation

When your application acts as an OAuth provider, third-party applications request specific scopes (permissions). A common mistake is granting all requested scopes without letting the user see or modify them. Always show users exactly what permissions an application is requesting and let them deny individual scopes where possible.

On the consumer side, request only the minimum scopes you need. An application that asks for read and write access to a user is entire GitHub account when it only needs to read their email address is a red flag that will reduce your OAuth consent rates.

Mistake 6: Storing tokens insecurely

Access tokens and refresh tokens are credentials. Treat them like passwords. Store them encrypted at rest in your database. Never log them. Never include them in error messages. Never store them in localStorage in the browser (use secure, HttpOnly cookies or in-memory storage instead).

If you are building a mobile app, use the platform keychain (iOS Keychain, Android Keystore) to store tokens. These provide hardware-backed encryption and are significantly more secure than shared preferences or plain file storage.