OAuth 2.0 Security Best Current Practice


OAuth 2.0 Security Best Current Practice is an Internet Draft RFC Sub-series Best Current Practice (BCP).

OAuth 2.0 Security Best Current Practice Full text


Since OAuth 2.0 has been published in RFC 6749 and RFC 6750. Since publication, OAuth 2.0 has gotten massive traction in the market and became the standard for API protection and, as foundation of OpenID Connect, identity providing.

While OAuth 2.0 was used in a variety of scenarios and different kinds of deployments, the following challenges could be observed:

  • OAuth implementations are being attacked through known implementation weaknesses and anti-patterns (XSRF, referrer header). Although most of these threats are discussed in RFC 6819, continued exploitation demonstrates there may be a need for more specific recommendations or that the existing mitigations are too difficult to deploy.
  • Technology has changed, e.g. the way browsers treat fragments in some situations, which may change the Implicit Grant's underlying security model.
  • OAuth 2.0 is used in much more dynamic setups than originally anticipated, creating new challenges with respect to security. Those challenges go beyond the original scope of RFC 6749, RFC 6750, and RFC 6819.

Recommended Best Practice#

  • 2.1. Protecting redirect-based flows
Authorization Servers MUST utilize exact matching of client Redirect_uris against pre-registered URIs. This measure contributes to the prevention of Data Leakage of authorization_codes and access_tokens (depending on the grant type). It also helps to detect OAuth 2.0 Mix-Up Attacks.

OAuth Client SHOULD avoid forwarding the user's browser to a URI obtained from a query parameter since such a function could be utilized to exfiltrate Authorization Codes and Access Tokens. If there is a strong need for this kind of redirects, clients are advised to implement appropriate countermeasures against open redirection, e.g., as described by the OWASP.

Clients MUST prevent CSRF and ensure that each Authorization Response is only accepted once. One-time use CSRF tokens carried in the "OAuth state parameter", which are securely bound to the User-agent, SHOULD be used for that purpose.

In order to prevent OAuth 2.0 Mix-Up Attacks, OAuth Clients MUST only process redirect responses of the OAuth Authorization Server they send the respective request to and from the same user agent this Authorization Request was initiated with. Clients MUST memorize which Authorization Server they sent an Authorization Request to and bind this information to the user agent and ensure any sub-sequent messages are sent to the same Authorization Server. OAuth Clients SHOULD use Authorization Server-specific redirect URIs as a means to identify the Authorization Server a particular response came from.

Encoding claims in the OAuth 2 state parameter using a JWT gives advice on how to implement CSRF prevention and Authorization Server matching using signed JWTs in the "OAuth state parameter".

OAuth Credential Leakage#

Attacks in the Browser#

Dynamic OAuth Scenarios#

OAuth initially assumed a static relationship between OAuth Client, Authorization Server and Resource Servers. The URLs of Authorization Server and Resource Servers were know to the OAuth Client at deployment time and built an anchor for the trust relationship among those parties. The validation whether the OAuth Client talks to a legitimate server is based on TLS server authentication (see RFC 6819, Section 4.5.4).

OAuth Credentials Injection#

Credential injection means an attacker somehow obtained a valid OAuth credential (code or token) and is able to utilize this for impersonation the legitimate Resource Owner or to cause a victim to access resources under the attacker's control (XSRF).
  • Code Injection - In such an attack, the adversary attempts to inject a stolen Authorization Code into a legitimate client on a device under his control.
  • Access Token Injection - The attack described in this section is about injecting a stolen access token into a legitimate client on a device under the adversaries control. The attacker wants to impersonate a victim and cannot use his own client, since he wants to access certain functions in this particular client. ( https://tools.ietf.org/html/rfc6819#section-4.6.4)
  • XSRF - injection of code or access token on a victim's device (e.g. to cause client to access resources under the attacker's control)

Other Attacks#

Proof Key for Code Exchange by OAuth Public Clients (PKCE)#

Although not part of the current OAuth 2.0 Security Best Current Practice it has been proposed to make PKCE REQUIRED.

PKCE solves two problems:

The section of the OAuth 2.0 Security Best Current Practice BCP (4.5.3. Proposed Countermeasures) which says clients can do PKCE or use the nonce, is only talking about preventing authorization_code injection.

The nonce parameter solves authorization code injection if the client requests an Id_token. OAuth Public Clients using the nonce parameter are still susceptible to stolen authorization_codes so they still need to do PKCE as well.

The only case where OpenID Connect clients do not benefit from PKCE is if they are also OAuth Confidential Clients. OAuth Public Clients (even OIDC clients) still need to do PKCE even if they check the nonce.

Other Topics#

  • why to rotate refresh tokens
  • why audience restriction
  • how to support multi AS per RS
  • differentiate native, JS and web clients
  • federated login to apps (code flow to own AS in browser and federated login to 3rd party IDP in browser)
  • do not put sensitive data in URL/GET parameters (Jim Manico)

More Information#

There might be more information for this subject on one of the following: