
Why Mastercard Doesn't Use OAuth 2.0 - hitr
https://developer.mastercard.com/blog/why-mastercard-doesnt-use-oauth-20
======
alangpierce
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:

[https://hueniverse.com/oauth-2-0-and-the-road-to-
hell-8eec45...](https://hueniverse.com/oauth-2-0-and-the-road-to-
hell-8eec45921529)

------
simonw
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.

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.

~~~
ars
It's quite common for companies to MITM https requests (and install their
personal certificate on all company owned machines so the browser raises no
errors).

Some _countries_ do so as well, for example Kazakhstan and China.

~~~
gsich
And people from that country have those certificates installed? Voluntarily?

~~~
viraptor
In case of countries, you don't need the certificate installed for MITM to
work. You just need it if you want to get rid of the warning on every single
https website. Unless you tunnel your traffic, it's visible.

In case of large corps, you get assigned a laptop / desktop setup by the
company. You probably authenticate to the AD and don't even get the privileges
to add/remove certificates.

~~~
yorwba
Also, if the country has its own root CA, it can just sign arbitrary
certificates.
[https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates](https://en.wikipedia.org/wiki/CNNIC#Fraudulent_certificates)

~~~
yjftsjthsd-h
Notice of course that that little stunt resulted in them being removed from
everybody's trust stores. And it's not like you can just get away with it
these days, since certificates are all publicly logged now.

~~~
viraptor
> since certificates are all publicly logged now.

Only some of them are. All EV and some DV get published.

~~~
yjftsjthsd-h
Didn't realize that; apparently all Symantec certs require it, and I
misunderstood that as industry-wide.

------
narsil
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.

~~~
dogma1138
No it can potentially ensure integrity between the a client and the first TLS
hop that’s about it.

You don’t know which client it actually came from and you can’t ensure
integrity within the transaction flow of your app.

Say the request terminated at a LB proxy then passed through and API gateway
into an MQ then goes through multiple servers you need some form of integrity
checking for the request and OAUTH 2.0 doesn’t provide it.

------
dwaite
They did this to provide message-level integrity. OAuth 2 switched to
Transport-level confidentiality/Integrity.

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.

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).

Relying on message level integrity in a protocol where such a thing was
basically a side-effect of avoiding hosting costs would make me _very_
nervous.

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.

------
gsich
Using TLS makes it acceptable to send cleartext passwords. I don't know why,
seems lazy.

So, I understand why Mastercard doesn't rely on that.

~~~
viraptor
> TLS makes it acceptable to send cleartext passwords

What do you mean? There exists a NULL cipher, but it needs to be agreed on by
both sides. If mastercard doesn't allow NULL, you can't send anything in
cleartext. Or did you think of something else?

~~~
ge0rg
The problems are before and after the TLS tunnel.

I've seen a BigCorp load balancer / web firewall log the first 1KB of each
HTTP POST body into a permanent archive. A typical login submission is much
smaller than that. Also in some networks the TLS connection is terminated by a
frontend server and backend communication is plaintext HTTP.

While these examples are obviously bad practice, having your requests signed
and not leak user passwords would easily nullify their impact.

------
Noumenon72
I think
[https://aaronparecki.com/oauth-2-simplified/](https://aaronparecki.com/oauth-2-simplified/)
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.

So maybe OAuth 1.0 is only better for apps running on a server?

------
EGreg
I once asked a related question on StackOverflow

[https://security.stackexchange.com/questions/161734/why-
does...](https://security.stackexchange.com/questions/161734/why-does-oauth-
and-oauth-2-have-access-tokens-at-all)

------
smooc
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.

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.

I’m glad mastercard does not rely solely on TLS.

~~~
ploxiln
So I guess the alternative would be to tunnel TLS inside TLS. So they can set
up fake CAs to intercept the outer TLS, but not the inner TLS, satisfying both
bank regulators and actual security. Until regulators catch on and we have to
go around in circles again ...

------
woranl
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.

------
starptech
The problems reminds me of
[https://github.com/hueniverse/oz/](https://github.com/hueniverse/oz/) it's
from one of the former oauth guys.

------
jacksmith21006
Curious how many have moved from LDAP to using OAuth?

Would seem the future for enterprise will be OAuth.

