!!! Overview [2]
[Attackers] both "white-Hat and others will find the [Vulnerability] of all systems.
Without a doubt, the biggest weaknesses in [OAuth 2.0] reside within the implementation details.
Beyond that, a few [{$pagename}] have been discovered and are worth mentioning.
!! [OAuth 2.0] Controversy [4]
In July 2012, [Eran Hammer] resigned his role of lead author for the OAuth 2.0 project, withdrew from the IETF working group, and removed his name from the specification.
Since then Eran Hammer has become a potty mouthed bitter individual. His posts must be considered adult material.
!! General Guidelines
You should be using the [Authorization Code Grant] if it is a server based client.
There are some issues Browser JS, For the moment the only standard for the in browser client is fragment encoding. In the future we hope to have more modern methods based on post message.
For people using [openID Connect] who want a [Identity Token] in the [Hybrid Flow] they should use the [form post|https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html|target='_blank'] response mode.
[Browsers|user-agent] now re-append fragments across [HTTP 302] [URL redirection] unless they are explicitly cleared this makes fragment encoding less safe than it was when originally specified.
Do NOT use [HTTP GET] for [Authorization Response] (from [Authorization Server]) which has [Data Leakage] issues. [OpenID Connect] OpenID Connect formally defined a [HTTP POST] response mode.
!! A Comprehensive Formal Security Analysis of OAuth 2.0[3]
A Comprehensive Formal Security Analysis of OAuth 2.0 ([FETT]) was performed by Daniel Fett, Ralf Küsters, Guido Schmitz in which they summarize:
''The [OAuth 2.0] [protocol] is one of the most widely deployed [authorization]/single sign-on ([SSO]) protocols and also serves as the foundation for the new [SSO] standard [OpenID Connect]. Despite the popularity of OAuth, so far analysis efforts were mostly targeted at finding bugs in specific implementations and were based on formal models which abstract from many web features or did not provide a formal treatment at all.
In this paper, we carry out the first extensive formal analysis of the [OAuth 2.0] standard in an expressive web model. Our analysis aims at establishing strong [authorization], [authentication], and session [integrity] guarantees, for which we provide formal definitions. In our formal analysis, all four OAuth [Grant Types] (authorization [code grant|Authorization Code Grant], [implicit grant|Implicit Grant], [resource Owner Password Credentials Grant], and the [client Credentials Grant]) are covered. They may even run simultaneously in the same and different [relying parties|Relying Party] and [Identity Provider (IDP)], where malicious relying parties, identity providers, and [browsers] are considered as well. Our modeling and analysis of the [OAuth 2.0] standard assumes that security recommendations and [Best Practices] are followed, in order to avoid obvious and known [attacks].
When proving the security of [OAuth|OAuth 2.0] in our model, we discovered four [attacks] which break the security of OAuth. The vulnerabilities can be [exploited|Exploit] in practice and are present also in [OpenID Connect].
We propose fixes for the identified vulnerabilities, and then, for the first time, actually __prove the security of OAuth in an expressive web model__. In particular, we show that the fixed version of OAuth (with security recommendations and [best Practices] in place) provides the [authorization], [authentication], and session [integrity] properties we specify.''
The most prevalent [Attacks] was a related to [Malicious Endpoints]
!! Four Attacks on [OAuth] – How to Secure Your OAuth Implementation
Although primarly aimed at the OAUth] 1 implementations there are some that need to be looked at for the [OAuth 2.0].
! Lack Of Data Confidentiality and Server Trust [2]
The paper[2] discusses several items relating to the protocol not insisting on the use of [TLS]/[HTTPS]. Of course everyone should use [TLS]/[HTTPS].
!! Insecure Storage of Secrets[2]
This is a real implementation issue and a lot of discussions on the [Insecure Storage of Secrets|Web Storage] is present in the forums are on this subject. The paper[2] does provide several good suggestions.
!! Attack: [HTTP 307] [URL redirection][1]
In this [attack|attacker], the [Attacker] (running a [malicious] [Relying Party]) learns the user’s [credentials] when the user logs in at an [Identity Provider (IDP)] that uses the __wrong HTTP redirection__ status code.
The Attack: [HTTP 307] [URL redirection] attack applies to the [Authorization Code Grant] mode and the [Implicit Grant] of [OAuth 2.0]. (more of the [Malicious Endpoints] theme)
! Fix
The fix it to be certain that [OAuth 2.0] implementations __require [HTTP 303] redirects__ for the steps mentioned above in order to fix this problem.
!! Attack: [Identity Provider (IDP)] Mix-Up[1]
The [attacker] confuses an [Relying Party] about which [Identity Provider (IDP)] the user chose at the beginning of the login/authorization process in order to acquire an authentication code or access token which can be used to impersonate the user or access user data.
Just as the previous attack, the [Identity Provider (IDP)] mix-up attack applies to the [Authorization Code Grant] mode and the [Implicit Grant] of [OAuth 2.0]. (more of the [Malicious Endpoints] theme)
To launch the attack, the attacker manipulates the first request of the user such that the [Relying Party] thinks that the user wants to use an identity managed by an [Identity Provider (IDP)] of the attacker while the user instead wishes to use her identity managed by an honest [Identity Provider (IDP)]. As a result, the [Relying Party] sends the authorization code or the access token (depending on the OAuth mode) issued by the honest [Identity Provider (IDP)] to the attacker, who then can use these values to login at the [Relying Party] under the user’s identity (managed by the honest [Identity Provider (IDP)]) or access the user’s protected resources at the honest [Identity Provider (IDP)].
! Fix
A fundamental problem in the [Implicit Grant] of the [OAuth 2.0] standard (and similarly for the [Authorization Code Grant]) is that the redirect in Steps 6 and 7 in Figure 2 does __not__ contain information from where the redirect was initiated. And hence, the RP cannot check whether the information contained in the redirect stems from the IdP that was indicated in Step 1. (This attack is fairly sophisticated and details will not be detailed here. See the reference [1])
Our fix therefore is to include the identity of the [Identity Provider (IDP)] in the redirect in some form. More specifically, we propose that [Relying Party]s provide a unique redirection endpoint for each [Identity Provider (IDP)]. Hence, the information which [Identity Provider (IDP)] redirects the browser to the [Relying Party] is encoded in the request and the [Relying Party] can detect a mismatch.[1]
%%information
The communication at this point in the [protocol] is secured with [HTTPS] (as when following the OAuth security recommendations) and cannot be manipulated by the [attacker].
%%
Note that the communication at this point in the protocol is secured with HTTPS (when following the OAuth security recommendations) and cannot be manipulated by the attacker.
We show in Section 5 that this fix is indeed sufficient. In addition, one could try to prevent the [Identity Provider (IDP)] mix-up directly at the beginning of the protocol. (Nonetheless, in any case the [Relying Party] should be able to check consistency in Step 7) We have not considered such additional countermeasures because, as we show, our fix is sufficient for the security of [OAuth 2.0] (as far as [authorization] and [authentication] goes).
An [Internet Draft] [OAuth 2.0 Mix-Up Mitigation|OAuth 2.0 Mix-Up Attack] has been presented.
!! Implications to [OpenID Connect] [1]
Both, the 307 redirect attack and the [Identity Provider (IDP)] mix-up attack, can be applied to [OpenID Connect] as well.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [A Comprehensive Formal Security Analysis of OAuth 2.0|http://arxiv.org/pdf/1601.01229v2.pdf|target='_blank'] - based on information obtained 2016-04-08
* [#2] - [OAuth User Profile Attack|https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20.pdf|target='_blank'] - based on information obtained 2016-04-08
* [#3] - [A Comprehensive Formal Security Analysis of OAuth 2.0|https://arxiv.org/pdf/1601.01229v3.pdf|target='_blank'] - based on information obtained 2016-06-27
* [#4] - [OAuth 2.0 Controversy|Wikipedia:OAuth#Controversy|target='_blank'] - based on information obtained 2016-06-27