OAuth2
Why do we need OAuth2?
The Pre-Social-Network Era
Before the social network era, authentication and authorization were isolated and restricted to specific domains. Each service managed its own identity silo.
Social Networks and Mobile
The rise of Web 2.0 and mobile apps required connecting previously isolated information islands. Two problems needed to be solved:
- Delegated authorization — allowing a third party to act on a user’s behalf
- Duplicate registration — users having to create separate accounts for every service
Could cookies solve this? No.
- Cookies are designed for a specific domain
- Cookies have no concept of scope (partial permissions)
- Cookies were born with the web and are not suitable for REST APIs
OAuth2 Grant Types
- Authorization Code
- Implicit
- Password
- Client Credentials
Common Vulnerabilities in OAuth2 Authorization Code Flow
1. Missing state parameter The state parameter prevents CSRF attacks. The start URL should only be generated by the client, not constructed by an attacker.
2. Authorization code replay If a code can be used multiple times, it may be captured and replayed by an attacker.
3. Redirect URI manipulation If the redirect URI is replaced with another valid client URL, an attacker may intercept the authorization code and obtain a token.
4. Token revocation If access tokens cannot be revoked, protected resources remain at risk for the entire token lifetime. The same applies to refresh tokens.
Customizing OAuth2
Customizing OAuth2 is a complex task. It is essential to follow best practices, use a well-known and trusted OAuth2 library, and adhere closely to the OAuth2 specification to avoid security vulnerabilities. Thorough testing is critical to ensure the implementation works as expected and to identify potential issues.
OAuth2 facilitates communication across the world.