!!! Overview
[{$pagename}] is an [Internet Draft] [RFC Sub-series] [Best Current Practice] ([BCP]).

[{$pagename}] [Full text|https://tools.ietf.org/id/draft-ietf-oauth-security-topics-13.html|target='_blank']

!! 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|URI Fragment Identifiers] 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|Unvalidated redirects and forwards], 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|Authorization 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.


%%information
[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]
* Insufficient [redirect_uri] validation
* [Attacks] on [Authorization Code Grant]
* [Attacks] on [Implicit Grant]

!! [Attacks] in the [Browser]
* [Code|Authorization Code] in [browser] history
* [Access Token] in [browser] history
* [JavaScript] Code stealing [Access Tokens]

!! 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|Malicious Endpoint] - Potential Mitigation:
** [OAuth 2.0 Mix-Up Mitigation|OAuth 2.0 Mix-Up Attack]
** [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 [iss]uer (requires [OpenID Connect])
** Clients use [Authorization Server]-specific [redirect_uri]s, 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|Authorization 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|https://tools.ietf.org/html/rfc6819#section-4.6.4|target='_blank'])
* [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|Unvalidated redirects and forwards] - error handling [Authorization Server] (redirects)  (draft-ietf-oauth-closing-redirectors-00)
* Using the Client as [Open Redirector|Unvalidated redirects and forwards]
* [Redirection] via [HTTP Status Code] [HTTP 307] - use [HTTP 302]

!! [Proof Key for Code Exchange by OAuth Public Clients] ([PKCE])
Although not part of the current [{$pagename}] it has been proposed to make [PKCE] [REQUIRED].

[PKCE] solves two problems: 
* stolen [authorization_codes] for [OAuth Public Clients]
* [authorization_codes] injection for all [OAuth Clients]

The section of the [{$pagename}] [BCP] (4.5.3.  Proposed Countermeasures) which says clients can do [PKCE] __or__ use the [nonce], is only talking about preventing [authorization_code] [injection|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:
[{ReferringPagesPlugin before='*' after='\n' }]