OAuth 2.0 Security - How to Secure your OAuth

OAuth 2.0

OAuth is an open standard for authorization, commonly used as a way for Internet users to log in to third party websites using their accounts at Google, Facebook, Microsoft, Twitter, etc.—but without exposing their password.

Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner.

Figure 1 shows the OAuth 2.0 exchange at an abstract level and illustrates the main entities.  For most parts of this document the focus is on the interaction between the Client and the Authorization Server and between the Client and the Resource Server.

        +--------+                                                 +---------------+

        |             |--(A)- Authorization Request ->|   Resource    |

        |             |                                             |      Owner     |

        |             |<-(B)-- Authorization Grant ------|                    |

        |             |                                               +---------------+

        |             |

        |             |                                           +-----------------+

        |             |--(C)-- Authorization Grant -->| Authorization |

        |  Client |                                            |     Server      |

        |             |<-(D)----- Access Token --------|                    |

        |             |                                           +-----------------+

        |             |

        |             |                                            +-----------------+

        |             |--(E)----- Access Token -------->|    Resource   |

        |             |                                            |     Server      |

        |             |<-(F)--- Protected Resource -- |                    |

        +--------+                                              +-----------------+

                  Figure 1: OAuth: Abstract Protocol Flow

Security and Privacy Threats

As a flexible and extensible framework, OAuth's security considerations depend on many factors. The following sections provide implementers with security guidelines.

• Client Impersonation

A malicious client can impersonate another client and obtain access to protected resources if the impersonated client fails to, or is unable to, keep its client credentials confidential.

The authorization server MUST authenticate the client whenever possible.  If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients.  For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.

• Access Tokens

When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties.

The authorization server MUST ensure that access tokens cannot be generated, modified, or guessed to produce valid access tokens by unauthorized parties.

The client SHOULD request access tokens with the minimal scope necessary.  The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope and MAY issue an access token with less rights than requested.

• Authorization Codes

The transmission of authorization codes SHOULD be made over a secure channel, and the client SHOULD require the use of TLS with its redirection URI if the URI identifies a network resource.  Since authorization codes are transmitted via user-agent redirections, they could potentially be disclosed through user-agent history and HTTP referrer headers.

Authorization codes operate as plaintext bearer credentials, used to verify that the resource owner who granted authorization at the authorization server is the same resource owner returning to the client to complete the process.  Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require the use of TLS.

• Request Confidentiality

Access tokens, refresh tokens, resource owner passwords, and client credentials MUST NOT be transmitted in the clear.  Authorization codes SHOULD NOT be transmitted in the clear.

The "state" and "scope" parameters SHOULD NOT include sensitive client or resource owner information in plain text, as they can be transmitted over insecure channels or stored insecurely.

• Ensuring Endpoint Authenticity

In order to prevent man-in-the-middle attacks, the authorization server MUST require the use of TLS with server authentication as defined by [RFC2818] for any request sent to the authorization and token endpoints.  The client MUST validate the authorization server's TLS certificate as defined by [RFC6125] and in accordance with its requirements for server identity authentication.

• Credentials-Guessing Attacks

The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials.

The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

• Phishing Attacks

Wide deployment of this and similar protocols may cause end-users to become inured to the practice of being redirected to websites where they are asked to enter their passwords.  If end-users are not careful to verify the authenticity of these websites before entering their credentials, it will be possible for attackers to exploit this practice to steal resource owners' passwords.

• Cross-Site Request Forgery

A CSRF attack against the client's redirection URI allows an attacker to inject its 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 (e.g., save the victim's bank account information to a protected resource controlled by the attacker).

• Clickjacking

In a clickjacking attack, an attacker registers a legitimate client and then constructs a malicious site in which it loads the authorization server's authorization endpoint web page in a transparent iframe overlaid on top of a set of dummy buttons, which are carefully constructed to be placed directly under important buttons on the authorization page.  When an end-user clicks a misleading visible button, the end-user is actually clicking an invisible button on the authorization page (such as an "Authorize" button).  This allows an attacker to trick a resource owner into granting its client access without the end-user's knowledge.

• Code Injection and Input Validation

A code injection attack occurs when an input or otherwise external variable is used by an application unsanitized and causes modification to the application logic.  This may allow an attacker to gain access to the application device or its data, cause denial of service, or introduce a wide range of malicious side-effects.

The authorization server and client MUST sanitize (and validate when possible) any value received -- in particular, the value of the "state" and "redirect_uri" parameters.

• Open Redirectors

The authorization server, authorization endpoint, and client redirection endpoint can be improperly configured and operate as open redirectors.  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.

Open redirectors can be used in phishing attacks, or by an attacker to get end-users to visit malicious sites by using the URI authority component of a familiar and trusted destination. 

 A Word on User Interaction and User-Installed Apps

OAuth, as a security protocol, is distinctive in that its flow usually involves significant user interaction, making the end user a part of the security model.  This creates some important difficulties in defending against some of the threats discussed above.  Some of  these points have already been made, but it's worth repeating and highlighting them here.

• End users must understand what they are being asked to approve.  Users often do not have the expertise to understand the ramifications of saying "yes" to an authorization request and are likely not to be able to see subtle differences in the wording of requests.  Malicious software can confuse the user, tricking the user into approving almost anything.
• End-user devices are prone to software compromise.  This has been a long-standing problem, with frequent attacks on web browsers and other parts of the user's system.  But with the increasing popularity of user-installed "apps", the threat posed by compromised or malicious end-user software is very strong and is one that is very difficult to mitigate.
• Be aware that users will demand to install and run such apps, and that compromised or malicious ones can steal credentials at many points in the data flow.  They can intercept the very user credentials that OAuth is designed to protect.  They can request authorization far beyond what they have led the user to understand and approve.  They can automate a response on behalf of the user, hiding the whole process.  No solution is offered here, because none is known; this remains in the space between better security and better usability.
• Addressing these issues by restricting the use of user-installed software may be practical in some limited environments and can be used as a countermeasure in those cases.  Such restrictions are not practical in the general case, and mechanisms for after-the- fact recovery should be in place.
• While end users are mostly incapable of properly vetting applications they load onto their devices, those who deploy authorization servers might have tools at their disposal to mitigate malicious clients.  For example, a well-run authorization server must only assert client properties to the end user it is effectively capable of validating, explicitly point out which properties it cannot validate, and indicate to the end user the risk associated with granting access to the particular client.