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 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

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#

  • Using the Authorization Server as Open Redirector - error handling Authorization Server (redirects) (draft-ietf-oauth-closing-redirectors-00)
  • Using the Client as Open Redirector
  • redirect via status code 307 - use 302

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: