The past, the present, and the future of OAuth and OpenID Connect
The world is different, time for something new?
Jacob Ideskog, CTO @ Curity (curity.io)
The Past
For centuries, proving identity and allowing access to certain information, crossing borders, or gaining permission for a certain activity was a matter of official certifications, identity cards, passports, and special seals that proved who and what was allowed.
The internet revolution demands new ways of communicating, accessing information, and identifying the same who and what. The need for digital identity management was born and evolved through standards such as SAML, user directories, passwords, and then the introduction of more challenging authentication methods.
A particularly large disruption occurred in 2012 when Apple iPhone 5 and Samsung Galaxy 3 were released. There were 750,000 apps available for iOS and 600,000 for Android-operated phones with almost 20 and 15 billion downloads, respectively. Needless to say, those were record numbers that exceeded the total amount of all previous years combined.
It meant one thing: the universe of APIs began to grow exponentially (or at least the known universe 😀). This big bang led to another transition: instead of apps being monolithic development projects, they became thin clients communicating with the back-end and storing most logic and data elsewhere. We saw it both for first-party and third-party apps — the homegrown ones for our own companies and others using our APIs.
2012 was also the year when OAuth 2.0 entered the picture. It came on the scene when new challenges were arising and right after its ratification became a major success story. It solved a fundamental problem of the app-API communication allowing the API to recognize the caller and to involve the user in the process. The challenge was to limit the need for the app to have access to the user’s credentials risking possible security breaches or identity theft.
Luckily, OAuth 2.0 was now available to help solve it. It introduced the procedure that we are all familiar with now: the user gets an account with an OAuth server, which issues access tokens to let the client call the API. Moreover, since OAuth 2.0 was designed as a framework rather than a stand-alone protocol (it was meant to be built upon!), it is used as the starting point for many other protocols that require delegated access to solve related use cases. This might be seen as both an advantage and a disadvantage. More about that later.
The Present
Nowadays, OAuth 2.0 is one of the most popular and widely-used standards that ensures security and safety when it is necessary to provide third-party applications access to restricted resources. It has become fundamental to securing APIs, which have in turn developed dramatically over the years. Nowadays, there is a plethora of use-cases that continue to expand at a rapid rate.
However, the usage of OAuth 2.0 can be associated with certain shortcomings, some of which were intended by developers (i.e. of OAuth 2.0) but some are not. The scope of the problem includes use-cases not covered by the specs, security issues, and UX pains.
In a nutshell, it comes down to the delegation of access between the app and API. It gets complicated when you realize that this app could be anything: a mobile app, a browser app, a single-page app, TV, a server, a kiosk, etc. As many kinds of devices/clients there are, there are also many ways they interact with APIs and the levels of security they require. For instance, a banking-grade API and a weather API would demand different solutions and degrees of safety.
Do you support OAuth?
This rich variety of nuances and variants led to the necessary ratification of new specifications, which are being continuously added to the old ones. It resulted in a large number of protocols, which are used in different situations. These are just a few:
- Dynamic Client Registration
- Token revocation
- Token assertion
- Sender Constrained Tokens using mTLS
- PKCE
- Native APP BCP
- Device Flow
- SPA BCP
- JWT Bearer Tokens
While providing opportunities for the effective solution of use cases, the extent of this list has become an obstacle. Security specialists would agree that the simple question “Do you support OAuth 2?” has never been so complicated as providing a precise answer to it means making sure which protocol exactly needs to be supported.
Browser: the good, the bad, and the ugly
There is one more problem that has to do with authentication methods. Authenticators can be seen as ways to answer the question “Who are you?” with some degree of certainty. All these methods are mere “islands” as there is no standard way of integrating with them. In other words, there is no “bridge” to the “mainland”.
To address this, one standard was added on top of OAuth that enabled connecting them all — OpenID Connect. It unifies how to start and terminate authentication flows and solves problems of requesting a login, sharing user information, federation and everything OAuth does underneath the OpenID Connect layer.
The focus on the beginning and end has been enough because it required the use of a browser. Certainly, there are undeniable advantages in browsers: they enforce security in a good way, comply with security headers, manage cookies, handle redirects without anything interfering with them, and moreover, a server can rely on them.
However, in the context of the mobile world and the user experience (UX), using a browser (and optionally other apps needed for authentication) is not a perfect scenario. Developers want control over the UX, and handing it over to a browser gets in the way.
So, OpenID Connect creates a uniform protocol for requesting Authentication from an App or Website. Because the protocol relies on the application to be a “Passive” client (i.e. driven by the user in the browser), it works universally as long as there is a browser in the mix.
The protocol leaves out the entire part that happens from the point when the application calls the OpenID Connect provider until it gets to the process’s end. This is where the actual authentication takes place. We often talk about the “Authentication Hamburger”. OpenID Connect creates the nice top and bottom “bun” with a bunch of authentication methods in the middle but doesn’t provide the “meat”. It works only because of the browser and the “passive” client, but as the mobile clients get more sophisticated we must look beyond this paradigm.
The Future
Solving this “hamburger” problem, enabling secure, mobile native experiences should be the main focus of the industry experts. The coming years need to be all about tackling authentication and user identity and creating opportunities for the native experience and user control. In this context, the use of a browser and the need for redirects prevent us from this.
So what should be done to emulate the browser?
The answer is simple when you see it.
A browser is a client that understands a Hypermedia-Driven API based on REST and HTML. We need to adapt this and restrict it to a more domain-specific area of authentication. The goal is to allow mobile clients (and others) to integrate directly with the authentication service. This way it is not only the “bun” that is seen but the entire “meat” — the Hypermedia Authentication API (HAAPI, pronounced “happy”).
The beauty of this is that the OpenID Connect protocol will still work as it is. A HAAPI client will start the flow using a regular OpenID Connect Code flow and finish the same way. Thanks to the API, the client can interact with the Authorization Server directly, without the need of an intermediary but still adhering to the flows standardized by OAuth and OpenID Connect frameworks. It enables mobile clients to use native components to render authentication steps, without the need of dealing with HTML.
It also means that any changes to the look and feel of the authentication process are deployed on the client-side, not at the Authorization Server. This provides a better experience for the development and operations teams, which now don’t get to implement and deploy changes in separate projects.
Moreover, it is secure. It functions within a developed framework for guaranteeing the identity of the client using client attestation mechanisms combined with Proof-of-Possession (PoP) tokens providing a security posture that is beyond what regular OAuth and browsers were capable of. The API can be certain that it receives requests from an untampered app, and knows it was the same app the user authenticated to.
The future of OAuth and OpenID Connect is shaped by developers’ needs and industry trends. Having a Hypermedia Authentication API to authenticate users would address both of these challenges. It would provide a streamlined browser-less experience when users don’t have to leave the app and ensure that this process is secure to mitigate possible attacks.
Learn more about the Hypermedia Authentication API on and don’t hesitate to get in touch and let us know your thoughts.
