The OAuth authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. The current OAuth version (2.0) is defined in the IETF’s RFC6749 specification.
OAuth 2.0 provides a mechanism to allow distributed applications to access resources on another application, but it is not itself an authentication protocol which is a frequent point of confusion. Instead, OAuth 2.0 can be used inside of authentication protocols like SAML or OpenID.
How We Approach OAuth Threat Patterns
IriusRisk provides a threat modeling platform based on threat patterns and diagrams. With the new support for OAuth 2.0 in our threat libraries, IriusRisk now includes the following new components with their associated threat patterns:
- Client Application: An application, or application component making protected resource requests on behalf of the resource owner. The term “client” does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices), it refers to any application that attempts to gain access to resources.
- Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. It presents the interface where the user approves or denies the request and may be the same server as the resource server but it is not common.
- Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. For example, the API server used to access the user’s information.
- The client application (e.g. Android Client Device) uses the OAuth2 Client Application to perform a request to the OAuth2 Authorization Server.
- The OAuth2 Authorization Server authorizes the OAuth2 Client Application and returns an access token if the authorization is successful.
- With the token, the OAuth2 Client Application can make authenticated requests to the OAuth2 Resource Server, which returns the requested resources. This way the resource server delegates all the authorization and authentication to the OAuth2 Authorization Server and doesn’t have to check if the client is properly authorized.
In order to help you design secure applications more easily IriusRisk includes predefined threat patterns for each of these components, along with recommended countermeasures. The top five most important threats to take into account when interacting with an OAuth system are:
- Authentication bypass: OAuth2 has the ability to add an authentication layer such as OpenID or SAML to provide both authentication and authorization. These authentication layers should be used whenever possible to avoid common authentication bypass errors.
- Insecure grant type: there are OAuth flows (Implicit flow and Resource Owner Password Credentials flow) that shouldn’t be used anymore due to the existence of threats like credential leakage via referrer headers or attacks through browser history. Instead, use Authorization Code or Client Credentials flows.
- Token injection: an adversary can inject a leaked, stolen or forged access token when a third-party application accepts access tokens from sources other than the return call from the token endpoint. To prevent this, securing the tokens with cryptographic signatures and following best practices to store sensitive data are among the most recommended countermeasures.
- Open redirection: An attacker could use the end-user authorization endpoint and the redirect URI parameter to abuse the authorization server as an open redirector. An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. In order to fix it an authorization server should require all clients to register their “redirect_uri” and the “redirect_uri” should be the full URI.
- Cross Site Request Forgery: CSRF is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering an attacker may trick the users of a web application into executing actions of the attacker’s choosing. A CSRF attack against the client’s redirection URI could allow an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker’s protected resources rather than the victim’s.
Getting Ready For OAuth 2.1
At IriusRisk we strive to provide the latest technical threat libraries based on published standards and for that reason we are including specific countermeasures for those users who might change their authorization framework from OAuth 2.0 to OAuth 2.1 when the latter is officially released possibly by the end of 2020.
OAuth 2.1 consolidates both the changes over the years in OAuth 2.0 and the details of the OAuth 2.0 Security Best Current Practices document, with a focus on better default security. The goal is to have a single document detailing how to best implement and use OAuth, removing the need for developers to delve into multiple RFCs and standards.
- The authorization code grant is extended with functionality from PKCE
- Redirect URIs must be compared using exact string matching
- The Implicit flow and Resource Owner Password Credentials flow are omitted
- Bearer token usage omits the use of bearer tokens in the query string of URIs
- Refresh tokens must either be sender-constrained or one-time use
Sign up to our community version and start threat modeling today! If you would like to see a full demo of IriusRisk you can download our Secure Design Webinar for free, or alternatively, if you would like to talk to our team for a custom demo of IriusRisk get in touch.
Bringing you the latest on all things threat modeling and architectural security.