Related: here's a write-up from one of the OAuth 2 authors on the problems he sees in OAuth 2 and why he thinks OAuth 1 is better:<p><a href="https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529" rel="nofollow">https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...</a>
It looks like they are concerned that OAuth 2.0 doesn't include a cryptographic signature of the request body, as seen in OAuth 1.0.<p>My understanding is that OAuth 2.0 dropped that signature in favour of requiring TLS to protect against tampering. I'd be interested to know why Mastercard doesn't consider this to be as good as the request body signatures in OAuth 1.0.
I'm not sure I understand the concern with integrity of OAuth 2.0 payloads. Sending the request over HTTPS already ensures that the request is not tampered with, and also guards against replay attacks.
They did this to provide message-level integrity. OAuth 2 switched to Transport-level confidentiality/Integrity.<p>It's worth noting that message-level integrity was not a design goal of OAuth 1; it is was a consequence of being based on OpenID 1/2, which were explicitly meant to run on HTTP without TLS so that they could be adopted by blogs. This was pre SNI, and pre cheap certs, so requiring HTTPS increased the hosting cost of a blog by an order of magnitude.<p>When the constraints changed such that requiring HTTPS was feasible, it greatly simplified OAuth. Some of these simplified proposals for OAuth became the input for OAuth 2 (where complexity was subsequently added back in the form of variants to support new use cases).<p>Relying on message level integrity in a protocol where such a thing was basically a side-effect of avoiding hosting costs would make me <i>very</i> nervous.<p>The clearest issue I can point to is that there is no response message integrity in MasterCard's system - an intermediary can block requests to MasterCard and give back fraudulent responses (yes, of course that payment went through!). This throws a ton of application-dependent security considerations into the system.
Using TLS makes it acceptable to send cleartext passwords. I don't know why, seems lazy.<p>So, I understand why Mastercard doesn't rely on that.
I think <a href="https://aaronparecki.com/oauth-2-simplified/" rel="nofollow">https://aaronparecki.com/oauth-2-simplified/</a> explains that the cryptographic signature approach (if that's what they mean by "client secret") was discarded because mobile apps and single-page Javascript apps can't maintain the confidentiality of a secret anyway.<p>So maybe OAuth 1.0 is only better for apps running on a server?
I once asked a related question on StackOverflow<p><a href="https://security.stackexchange.com/questions/161734/why-does-oauth-and-oauth-2-have-access-tokens-at-all" rel="nofollow">https://security.stackexchange.com/questions/161734/why-does...</a>
Any app that takes security seriously will need to take a layered approach. So while Oauth 2, which is just a framework contrary to oauth 1.0a, seems to outsource its integrity protection to TLS this isnt enough: others have already pointed out that many companies hijack TLS at their edge proxies. Banks do this bu requirement of the regulator.<p>So you would need additional defenses against tampering such as OpenID Connect. In the banking apps that I have been working with we implemented additional symmetric encryption on top of the protocol (yes obfuscating the keys) and all other kinds of small things.<p>I’m glad mastercard does not rely solely on TLS.
It’s unfortunate that Big companies are pushing for OAuth 2.0 and trying to blindsided developers as if OAuth 2.0 is an upgrade to OAuth 1.0a. It is not! OAuth 1.0a provides authenticity, integrity, and non-repudiation. Something that OAuth 2.0 cannot match.
The problems reminds me of <a href="https://github.com/hueniverse/oz/" rel="nofollow">https://github.com/hueniverse/oz/</a> it's from one of the former oauth guys.