Our Flawed World of Identity and Rights?

Our Flawed World of Identity and Rights?

Which protocol moved from Version 1.0 to Version 2, and became more complex, less interoperable, less useful, more incomplete, and less secure? That will be OAuth.

The industry has been swept along by OAuth 2 through its adoption by Google and Facebook. Other improved methods which aimed to provide fewer opportunities for spying on accesses, such as with Microsoft CardSpace, have generally failed in their adoption. For Google, Facebook, and Twitter, to be the ID provider of choice allow these companies to extend their reach, and be the core of identity on the Internet. Basically, these companies “own your identity”.

Industry experts have, for many years, been highlighting the major problems of OAuth 2 and its over-simplistic usage of long-term tokens. But still there is little thought about a sustainable long-term solution … and where we are stuck in a pre-GDPR model of the world with no way of fixing it.

Put simply, a single flaw in the implementation of OAuth 2 could open up billions of applications on the Internet. It was, for example, recently identified that over 40% of applications which used OAuth 2 were vulnerable to attack.

In some cases, it is a lazy solution to the true identity problem, and where OAuth 2 is used to issue a token which then grants access rights to a range of services. In many cases, the provision of a username and a password can gain you long-term rights to access a wide range of services. Unfortunately, if you gain someone else’s token, you have all their rights, without even requiring their password.

Basically, you open the front door with your key, and get a note to get back in. If someone sees your note, they can get in too, without your keys.

Only with smart contracts, true identity signing and in the usage of cryptography keys, can we provide an improved identity world. For just now we are just creating methods which make life easy for developers and administrators, and not really thinking about the true identity of a person. This easy fix could all come crashing down, and we need to find ways to improve the provision of rights and identity, and for improved trust levels.

Federated ID and OAuth2

Facebook, as with many other major Cloud Service Provider, including Google, use the OAuth2 authentication protocol for providing an ID token to a user. The token, itself, does not contain the password, but just the fact that the user has identified themselves, and has rights on the system for a given amount of time. This token can also be trusted on other sides — with federated identity. Thus if you use Facebook to log into Spotify then Facebook proves your identity and then passes an OAuth2 token back to you, to give to Spotify. The scope of the breach could thus involve other external services which use Facebook as an identity provider.

Within OAuth 2, a user requests a service, and then is told the identity providers that the service trusts. The user then selects onto and proves their identity to the identity provider, and is given a token back which is passed to the service. This token can then be used to log the user into the system:

The problems

While OAuth 2 solves many problems in logging into systems and in traversing across trusted systems, many security experts criticize its usage, as the tokens can be captured, and where long periods of access can be granted on a single provision of user identity. The basic process into the user accessing a web service and is then redirected to the identity provider, who will request the identity details of the user. On a successful entry of these details, the identity provider will send back an access token to the service provider:

A recent article on Medium defined that OAuth 2 was the gatekeeper of the growing API industry, but also its Achilles Heel:

Its simplicity in its operation allows developers to quickly authenticate the user, and then allow them to gain the required rights. But it has major flaws. The major hack of Facebook ID tokens shows that a large-scale breach could open up many services on the Internet to abuse.

Along with this, the identity provider can spy on the user but looking at the services that are being asked for, so that Facebook could tell every time you logged into Spotify. While we all like single sign-on in our corporate systems, it does cause major problems when the back-end infrastructure is breached.

In 2016, researchers from the University of Hong Kong outlined a paper on “Signing into One Billion Mobile LApp Accounts Effortlessly with OAuth 2.0.” Within this, they identified an attack on poor OAuth 2.0 implementations and which put over one billion applications at risk:

Token Binding 1.0

We increasingly live in a digital world where we identify ourselves once and then receive an authorization token. This token can then be passed to trusted services, where the user does not have to be re-authenticated.

It is a well-known secret that OAuth and other token-based systems have a massive problem — and where an authentication token can be stolen and then used for a replay attack. And so Microsoft and Google have collaborated in creating RFC 8471 (The Token Binding Protocol Version 1.0):

Overall it aims to remove the token replay:

At the core of the change is that the token is created with the details of the device or the device’s configuration integrated into the token. This makes it difficult to recreate the device conditions in order to use the token. RFC 4871 defines the creation of a public and a private key (and which could possibly be linked into a TPM (Trusted Platform Module) and linked to the private key built into the hardware. The private key is used to sign elements of the negotiation steps.

The RFC defines the linkage of HTTPS security cookies and OAuth tokens to the TLS layer. These tokens would then be difficult to recreate for replay attacks. With the TLS connection to a server, the client generates a key pair for each of the servers that they connect to.

There are two other related RFCs:

• RFC 8472. TLS extension using the Token Binding Protocol.
• RFC 8473. Application of the protocol to HTTP.

The updates, it is hoped, will not affect existing implementations.

Conclusions

I repeat again … only with smart contracts, true identity signing and the usage of cryptography keys, can we provide an improved identity world. We need a world which is more focused on users, and less on what developers and administrators find easy to set up. OAuth 2 should only be seen as a short-term solution to a trust infrastructure, the long-term solution is to put identity and rights back into the hands of those that matter … the citizen. We are still stuck in the 20th Century and have to look at creating systems which are truly integrated, and that respect the rights of the citizen to privacy and consent.