jspωiki
OAuth 2.0 Security Best Current Practice

Overview#

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

Summary#

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

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: