The document provides an overview of OAuth 2.0 authorization framework and discusses common security issues. It begins with introducing the speaker and their background in security. The main topics covered include the history and core elements of OAuth, common grant types and flows, and vulnerabilities like insecure storage of secrets, CSRF attacks during authorization, scope permission issues, and account takeover risks. Best practices for clients and authorization servers to mitigate these threats are also outlined.
1. Pavan Kumar J
Security For OAuth 2.0 : How To Handle
Protected Data
An Introduction to OAuth Framework and Security Countermeasures
2. Our Speaker today
● Security Lead at we45.
● Seasoned security professional with over 5 years experience
leading Pen Testing projects.
● Written numerous automation scripts for automating host
environment reconnaissance.
● Specializes in custom security automation solutions.
● Ardent researcher around a host of different subjects (Cloud
Security, OAuth, SSO etc. )
3. Over the next 45 minutes...
● Comprehensive understanding of the OAuth 2.0 authorization
framework.
● Threats/Attacks specific to OAuth 2.0
● Practical demonstration of exploit vectors
● Outline of architectural best practices in OAuth 2.0
4. History of Authentication and Authorization
Authentication Protocol Authorization Framework
Built upon OAuth 2.0
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
5. Erstwhile OAuth….
● Storing of user credentials
● Complete Access to user’s accounts
● Insecure handling of user credentials.
● Users can't revoke access
● Compromised apps expose user's
password
6. Presenting OAuth2.0
● OAuth 2.0 stands for Open Authorization
● Protocol provides simple and secure authorization for
different types of applications
● A way to provide user access without exchange of
credentials
● One of the best method for consumers to interact with
protected data
7. Core Elements of an OAuth Flow
● Resource Owner - User
● Client - Coolmart (an example app)
● Authorization Server - Facebook / Google etc
● Resource Server - Facebook/ Google etc
8. OAuth 2.0 : Abstract Flow
1. Application redirects to Auth server
4. Request Access token using Authorization
code
6. Fetch protected data using Access Token
3. Application gets Authorization code
5. Application gets Access Token
7. Serves Protected data
User
Auth server
Resource Server
2. User Authorize the Request
9. OAuth 2.0 Grant Types
● Authorization Code Grant
● Implicit Grant
● Password Grant
● Client Credentials
10. Authorization Code Grant
1. Application redirects to Auth server
4. Request Access token using Authorization code
6. Fetch protected data using Access Token
3. Application gets Authorization code
5. Application gets Access Token
7. Serves Protected data
User
Auth Server
Resource Server
2. User Authorize the Request
11. Security Perspective : Auth Code Grant
● Two step protocol
● Authorization code is used to obtain access token
and refresh token
● Support for refresh tokens
● Uses Cookies
12. Implicit Grant
1. Application redirects to Auth server
4. Fetch protected data using Access Token
3. Application gets Access token
5. Serves Protected data
User
Auth server
Resource Server
2. User Authorize the Request
13. Security Perspective : Implicit Grant
● Can log into a site WITHOUT storage or knowledge
of client_secret key
● Does not supports refresh tokens
● Access token are returned directly
from authorization request.
● XSS Attacks
14. Resource Owner Password Grant
1. Application asks facebook credentials
5. Fetch protected data using Access Token
4. Application gets Access token
6. Serves Protected data
User
Auth server
Resource Server
2. User provide credentials to the application
3. Application forward credentials
15. Security Perspective : Password Grant
● Suitable for In-House/own
Organization applications
● Not suitable for external clients
● Clients will have user credentials
● Compromised apps expose user's
password
● Insecurely handle the credentials
16. Client Credential Grant
5. Fetch protected data using Access Token
4. Application gets Access token
6. Serves Protected data
Auth server
Resource Server
1. Application sends Client credentials
17. Security Perspective : Client Credentials
● Suitable for machine-machine
applications.
● No support for refresh token
● No authorization grant
● Chances of exposing Client
Credentials
20. Authorization Codes not invalidated
Attack Scenario:
● Authorization token must be revoked once it used.
● When user denies access for the application, with access token authorization codes must be revoke
https://clients.amazonworkspaces.com/webclient?auth_code=11QXVVW9Fm8qj29VD55kbfawj_14OqAqrbVqs_tzaEtuor4NL_g-K8eS
PW4QtCVRb_pKi7eELFJndQ0LBDaJrhgP2q65lJJQMhVRQg6sBwTu83Z6AKj9Vm7vCE4P2lnvrSLUba6ZAhVYo6QZ4I5O7WGajMslI98IcMy
Bk-tZHreaIgGaE52XVXB4VPQPFoIRuSfh1OyYlgF0OIy0JpywU®istrationCode=SLiad+RN58HY&errorHandlerUrl=aHR0cHM6Ly9sb2d
pbi5kYWFzLnVtdWMuZWR1LyMvV29ya3NwYWNlSWQ9d3MtMTl3Z3F4NnQxLw==#/main
23. Mitigation Strategy
● Do not accept used Authorization codes
● Client websites must never send authorization code in the referral header
● Ensure that pages containing sensitive information are only visible post authentication. .
○ Ensure that authenticated functionality is not cached using Cache Control
○ Consider implementing a robots.txt file to ensure that Search engines do not index and
cache sensitive pages
26. Mitigation Strategy
● Developers must consider the scope of grant given to different client website types while
setting up the authorization server.
● Client website MUST explain the scope of permissions it is asking of the user
28. Account Takeover using CSRF
Attacker
User
2. Sign-In with facebook1.Createsdummyacount
3 . Redirects to facebook
4.Getsauthorizationcode
5. Craft and Sends CSRF forged
request
6 . Clicks on Forged request
7 . Attacker FB connected to victim coolmart account
29. Mitigation Strategy
● OAuth 2.0 provides security against such attacks through the state parameter. It acts like a
CSRF token.
● Client websites must be sure to send a state parameter and handle requests
● Authorization servers must issue proper guidelines for generating and handling CSRF
tokens.
31. Stealing OAuth Tokens
● The attacker owns his website, www.attacker.com.
● After grabbing the victim's authorization URI, the attacker replaces the "redirect_uri" param to
"www.attacker.com".
● Then, After successful authentication, oauth-server redirects back to attacker URL, with the auth code.
● Using the code attacker can easily gets access token.
40. Mitigation Strategy
Configuring X-Frame-Options header
• DENY - Cannot be displayed in a frame.
• SAMEORIGIN - Only be displayed in a frame on the same origin
• ALLOW-FROM - Only be displayed in a frame on the specified origins
41. Best Practices - Client Applications
● Use secure communication channels
● Do not authorization code more than once
● Implement CSRF protection for its redirection URI
● Implement appropriate countermeasures against open redirection
42. Best Practices - Auth/Resource Server
● Do not accept used Authorization codes
● Never whitelist entire domains
● Validate client redirect URIs against pre-registered URIs
● Implement CSRF protection for its authorization endpoint
● Authorization server should redirects back to the client with "state" parameter.