OAuth 2.0 Security: OAuth Open Redirector

This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification and in the OAuth 2.0 Threat Model and Security Considerations . In particular focuses its attention on the risk of abuse the Authorization Server (AS) as an open redirector. It contains the following content: Describes the Authorization Server Error Response as defined in . Describes the risk of abuse the Authorization Server as an open redirector. Gives some mitigation details on how to hinder the risk of open redirector in the AS.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 . Unless otherwise noted, all the protocol parameter names and values are case sensitive.

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. Used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.

The OAuth 2.0 specification defines the Error Response associated with the Authorization Code Grant flow and the Implicit Grant flow. Both flows use a redirection endpoint where the resource owner's user agent is directed after the resource owner has completed interacting with the authorization server. The redirection endpoint is also used in the error response scenario. As per RFC6749 Section 4.1.2.1 and 4.2.2.1 if the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the AS redirects the user-agent by sending the following HTTP response: HTTP/1.1 302 Found Location: https://client.example.com/cb?error=access_denied

As described in an attacker could utilize a user's trust in an AS to launch a phishing attack. The attack described here though is not mitigated using the countermeasures listed in . In this scenario the attacker: Performs a client registration as per the core specification . The provided redirection URI is a malicious one e.g. https://attacker.com (namely the one where the victim's user agent will land without any validation) Prepare a forged URI using the assumption that the AS complies with the OAuth 2.0 specification . In particular with the AS Error Response described in the previous section ( ). As an example he can use a wrong or not existing scope e.g. https://AUTHORIZATION_SERVER/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fattacker%2Ecom&scope=INVALID_SCOPE Attempt the pishing attack trying to have the victim clicking the forged URI prepared on the previous step. Should the attack succeeds the victim's user agent is redirected to https://attacker.com (all with any user interaction) The HTTP referer header will be set to the AS domain perhaps allowing manipulation of the user.

The attacker can use a redirect error redirection to intercept redirect based protocol messages via the Referer header and URI fragment. In this scenario the attacker: Performs a registration of a malicious client as per the core specification . The provided redirection URI is a malicious one e.g. https://attacker.com (This URI will capture the fragment and referrer header sent as part of the error) Creates a invalid Authentication request URI for the malicious client. As an example he can use a wrong or not existing scope e.g. https://AUTHORIZATION_SERVER/authorize?response_type=code&client_id=malicious_client&redirect_uri=https%3A%2F%2Fattacker%2Ecom&scope=INVALID_SCOPE Performs a OAuth Authorization request using the invalid Authorization request as the redirect_uri. This works if the AS is pattern matching redirect_uri and has a public client that shares the same domain as the AS. (line breaks for display only)

Receive the response redirected to https://attacker.Com The legitimate OAuth Authorization response will include an access token in the URI fragment. Most web browsers will append the fragment to the URI sent in the location header of a 302 response if no fragment is included in the location URI. If the Authorization request is code instead of token, the same technique is used, but the code is leaked by the browser in the referer header rather than the fragment. This causes the access token from a successful authorization to be leaked across the redirect to the malicious client. This is due to browser behaviour and not because the AS has included any information in the redirect URI other than the error code. Protocols other than OAuth may be particularly vulnerable to this if they are only verifying the domain of the redirect. Performing exact redirect URI matching in OAuth will protect the AS, but not other protocols. It should be noted that a legitimate OAuth client registered with a AS might be compromised and used as a redirect target by an attacker, perhaps without the knowledge of the client site. This increases a the attack surface for a AS.

In order to defend against the attacks described in and the AS can either: Respond with an HTTP 400 (Bad Request) status code. Perform a redirect to an intermediate URI under the controll of the AS to clear referer information in the browser that may contain security token information. This page SHOULD provide notice to the resource owner that an error occurred, and request permission to redirect them to an external site. If redirected, the fragment "#_=_" MUST be appended to the error redirect URI. This prevents the browser from reattaching the fragment from a previous URI to the new location URI.