“If you think about where OAuth started, it was really about securing comments on blog posts and now we’re talking about enterprises, so it’s a whole different class of security.”

This is how Travis Spencer, CEO at the identity company Curity, opened his talk at our 2019 Austin API Summit, and it’s an astute summary of the way many products (particularly in the tech scene) are tweaked or re-engineered beyond their original purpose.

As Spencer clarified in his talk, “when we say banking grade we’re not just talking about banks, we’re talking about healthcare, government, and high security.” In other words, financial grade security is something that’s relevant to any data-centric API.

It’s often true that products struggle to adapt to tasks they were not originally designed for. In this post, we’ll be looking at whether or not that’s the case here, i.e. how the likes of OAuth have evolved from humble beginnings and if it’s truly capable of being used for financial grade protection.

Can OAuth Make The Grade?

Early in his talk, Spencer provides a summary of some things you can do with your OAuth implementation to provide financial grade security:

• Mutual TLS constrained tokens
• PKCE (Proof Key for Code Exchange)
• Consent
• Signed request/response objects
• Pairwise Pseudonymous Identifiers (PPIDs)
• Phantom tokens
• Strong authentication
• Prefix scopes
• Dynamic clients

There’s no denying that’s a pretty comprehensive list and suggests that OAuth is more than capable of holding its own when it comes to security. In other words, OAuth shouldn’t be seen as insufficient when it comes to securing data. In fact, Spencer outlines a number of ways in which it works very well for financial grade protection.

For example, Spencer mentions how PPIDs can be used to prevent collusion between unrelated apps while allowing interaction between, say, sites and their associated mobile apps. He also describes how phantom tokens (vs., say, a JSON web token) allow for a smaller regulated space while preventing clients from accessing any Personally Identifiable Information (PII) and front-end clients from depending on the content of access tokens.

Some Tokens Are Unbearer-able

The way OAuth is used by developers isn’t, however, always perfect. The two main vulnerabilities of OAuth as seen by Spencer? Bearer tokens and the redirect. “Those two things are the primary attack vectors in OAuth.”

Spencer likens the former to bearer bonds; “if you bear the bond, then…you can get a million dollars for each piece of paper and have a great life!” That’s particularly problematic here because, unlike with bearer bonds, there’s no way to lock tokens away in a physical safe.

“That’s the Achilles heel because, if I can snatch someone else’s token, I can become them.” So what’s a solution that can get around this? “The opposite of this is a holder of key token or proof of possession token, and that’s what mutual TLS constraint tokens are.”

From “Financial Grade APIs Using OAuth and OpenID Connect,” by Travis Spencer, CEO at Curity.

In simple terms, the addition of a hash of a certificate to the token exchange process means that works something like using a cipher to decode a message; without the proper credentials, the token won’t function properly when used for an API call.

Unfortunately, that isn’t the end of the story…

Away With The PKCEs

When talking about redirects, Spencer refers to the vulnerability in callbacks that exists if…

• It’s not confidential, i.e. not done over TLS
• There’s no authentication done on the token endpoint
• The callback is not unique per client, or per client operator

“In cases where it’s possible for a bad actor to intercept the credentials, they may be able to entirely sidestep the use of mutual TLS tokens outlined above.” He also highlights that this is something particularly prevalent in mobile devices.

The solution? Proof Keys for Code Exchange (PKCE). “We can add a step 0 into this process…The legitimate application uses a proof key to prove that it is the actual application that started this flow, with the OAuth server refusing to finish it unless that proof is verified.”

You could think of this as a more robust version of Dennis Nedry’s “ah ah ah, you didn’t say the magic word” in Jurassic Park…

Signed, Sealed, Delivered

Spencer highlights the issue that, in most cases, OAuth flows go through the user agent. Malware installed in the browser, for example, on the user side can undermine all of the measures taken above.

“How do we know that OAuth flows aren’t being tampered with in flight?” Spencer asks. “We sign the request from the client sent to the server and back…We can also sign the response that’s sent back to the client as well so they know nothing was tampered with on the way back.”

All of this signing and hashing is something that’s already proven its worth in recent years: read an article about data leaks by big companies and you’ll notice, in cases where it’s been done, how eager they are to talk about hashing passwords.

Although hashing passwords, signing requests etc. isn’t always 100% secure, there are cases, for example, in which weak hashing has been cracked. It is, at this point in time, about the best thing we can do.

What’s Next For Financial Grade API Security?

It seems likely, for now at least, that the status quo will continue as the norm in the world of financial and financial grade APIs.

From PayPal and Stripe to Coinbase, and probably Facebook’s Libra in the not too distant future, there are plenty of financial services utilizing APIs that are built around existing frameworks and services like OAuth.

If actual financial services are already relying on these then there’s very little incentive for other API developers to go beyond what already, in effect, constitutes financial grade API security…barring massive data leaks or the exposition of serious vulnerabilities.

In the meantime, we would expect to see OAuth continue to be one of those rare exceptions: a service that was built with something minor (securing blog comments) has effectively expanded to something much more robust than that its original intent.