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
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.
OAuth Credential Leakage#
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).
- Access Token Phishing by Counterfeit Resource Server
- Mix-Up - Potential Mitigation:
- OAuth 2.0 Mix-Up Mitigation
- Authorization Server returns client_id and its iss in the response. Client compares this data to Authorization Server it believed it sent the user-agent to.
- id_token carries client_id and issuer (requires OpenID Connect)
- Clients use Authorization Server-specific redirect_uris, for every Authorization Request store intended Authorization Server and compare intention with actual Redirect_uri where the response was received (no change to OAuth required)
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)
- Using the Authorization Server as Open Redirector - error handling Authorization Server (redirects) (draft-ietf-oauth-closing-redirectors-00)
- Using the Client as Open Redirector
- Redirection via HTTP Status Code HTTP 307 - use HTTP 302
PKCE solves two problems:
- stolen authorization_codes for OAuth Public Clients
- authorization_codes injection for all OAuth Clients
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.
- 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)