This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
OAuth 2.0 Security Best Current Practice
OAuth 2.0 Security Best Current Practice

Version management

Difference between version and

At line 1 added 88 lines
!!! 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' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop