Gartner's Hype Cycles are built with stages to help readers understand when particular technologies are maturing, how long they will take, and when they have reached mainstream adoption. Gartner publishes Hype Cycles for both Digital Identity and APIs, which are interesting for Curity and our customers as they map the state of the market around API security and identity.

The Hype Cycles are a good indicator of when to start considering new technologies. Some are harder to implement and could require significant experimentation before an organization is comfortable deploying them. Emerging technologies, such as zero-knowledge proofs and decentralized identity, are extremely promising. Although they will have a huge impact, the standards are not yet finished. Despite this, it's time to experiment with them.

As a vendor, we are actively adopting new technologies and encourage customers to do the same. One reason is that Gartner expects the influence of these technologies to be very strong. This means that customer expectations for these methods will come as an avalanche once the trends catch on. By then, organizations within industries where these nascent technologies are useful will need to be ready.

In the remainder of this blog post, I want to zoom in on one part of this cycle a little closer, namely the OAuth bullet. OAuth is described as having reached a high point on the "Slope of Enlightenment." This means it's close to reaching the "Plateau of Productivity." This is in line with how I view OAuth as well, considering the technology's adoption and maturity.

However, there's a lot underneath this single bullet that I want to highlight. OAuth is an evolving standard that encompasses more than the single spec defining that protocol, especially when combined with OpenID Connect (which is trailing behind in the cycle at the bottom of the "Slope of Enlightenment"). Looking at these two points on Gartner's Hype Cycle, we can broaden our perspective to include related technologies distributed across the entire cycle.

To structure my thoughts around this focus on OAuth and OpenID Connect, I have created my own model to depict where different yet related technologies are at in their adoption cycles. To this end, I'd like to introduce the OAuth and OpenID Connect Adoption Funnel.

The OpenID Foundation and the IETF OAuth Working group frequently add new standards to the OAuth and OpenID Connect suite of specifications. However, even if a protocol makes it through the standardization process in these groups, it doesn't mean it will be broadly adopted. Only when the industry finds that it solves a relevant use case and implementations are broadly deployed can we call it a de facto standard.

So, follow me through the funnel and prepare for an acronym fest. (Links to our explanatory articles are sprinkled throughout so you can dig into the alphabet soup).

The OAuth and OpenID Connect Adoption Funnel

Experimental

We are working with the OpenID Foundation to create future standards for issuing, verifying, and holding credentials (such as your driver's license). The work is ongoing and includes three related specifications: Verifiable Credential Issuance (VCI), Verifiable Presentation (VP), and Self-Issued OpenID Provider (SIOP). The work is receiving a lot of attention and enthusiastic contributions. There are already draft implementations even though the standards themselves are each a fast-moving work in progress. As a company, we believe these will be impactful protocols that will move all the way through the funnel over the coming years. In fact, we are currently adding these as experimental features to our product.

Rich Authorization Requests (RAR) and Grant Management have been in the works for quite some time. These are both interesting for financial-grade scenarios, but it's too early to say if they will reach adoption in that niche. RAR is partly used in the VCI specification, so it will gain adoption as VCI gets traction. It's hard to say if it will get broad adoption on its own, however. Currently, I believe RAR will be used for particular purposes in other specifications, limiting the generality of its implementations. So, we'll have to wait and see how far it progresses through the funnel.

On the other hand, Grant Management makes a concrete specification out of some assumptions made in the first OAuth specification. It's useful in some scenarios where those assumptions should not be implicit. Grant Management will progress further through the funnel if it gets incorporated into open banking regulations. If not, it may fall out of favor. In that case, the assumptions may be left unspecified in most deployments, as is the case today.

HTTP Signatures is a specification being discussed as another way to constrain tokens to the entity to which that token was issued. This sender-constraint protocol is an alternative for Demonstration of Proof of Possession (DPoP) and Mutual TLS (MTLS) in some cases. It is still too early to see if it will gain enough traction to move down the funnel. It puts some implementation burden on the client side, which could be handled by HTTP client libraries. This was always the argument for signing in OAuth 1.0, though, and that protocol is so far gone it's not even in the reject pile of the funnel anymore! So, we'll see in a couple of years on this.

Lastly, it's worth mentioning the OpenID Connect Federation specification. It's a serious attempt to make OpenID Connect the replacement for SAML — even for large-scale federation situations. This has been a long runner, and it will be interesting to see where it lands.

Early Adoption

Most OAuth standards are in the early adoption stage of the funnel. This might be why Gartner put OAuth on the Slope of Enlightenment of their Hype Cycle. Although OAuth is an established framework, many of the standards built upon it are still in their early ages. But it's looking good for many of them, as OAuth maturity is sloping upward overall. For example, take the new issuer (iss) parameter, part of the OAuth 2.0 Security Best Current Practice (BCP), and FAPI 2.0 Baseline specifications. Similarly to the PKCE standard, this fixes certain security concerns for specific use cases. Given that it's so small and easy to implement, I believe the parameter will reach broad acceptance quickly. At Curity, we've added this as our product's default behavior in version 8.0.

The token exchange specification addresses an interesting but limited use case. There are many ways to exchange tokens and many scenarios where this is interesting to do. This specification proposes one way, but it's not the general solution for token exchange that one might have hoped for. It will continue to be a slow mover, but it could become more broadly adopted eventually.

JWT Secured Authorization Requests (JAR), JWT Secured Authorization Response Mode ( JARM), and Pushed Authorization Requests (PAR) are significant security additions to OAuth and OpenID Connect. They are primarily for high-security situations. These provide better mechanisms to ensure integrity and confidentiality in message exchanges. FAPI refers to these to deliver financial-grade security, and since FAPI is utilized in other sectors besides banking, JAR, JARM, and PAR will gain broader adoption. Of these three, PAR is likely to move through the funnel faster than the others because it is simpler for the client to implement and provides a very clean interaction pattern with the server.

FAPI also relies on Client Initiated Backchannel Authentication (CIBA). This is an out-of-band protocol where a client can request user authentication without a browser. There are many use cases where this can be applicable — for example, when a customer calls a helpline and must be authenticated. In this case, the customer service representative can initiate a CIBA flow that causes the customer's device to prompt them for authentication. 

That being said, there's a bit of a misconception about CIBA. Many people think it's useful for all non-browser flows, or, more precisely, flows where the organization wants to avoid redirects in the browser. This is not the case, and one should be careful not to bend the protocol for purposes it wasn't intended for. CIBA will likely reach broad adoption in the near term because it's being used in so many financial-grade deployments. But, it will never become the silver bullet for non-redirection use cases since it was never designed for that in the first place.

Like HTTP signing discussed above, DPoP is a mechanism to constrain tokens to the entity to which they were issued. This sender-constrained protocol implements a version of Proof of Possession (PoP). This is a useful mechanism for protecting refresh tokens in Single Page Applications (SPAs). DPoP is also helpful for safeguarding APIs, and Curity uses it in our Hypermedia Authentication API. However, it's not a generally useful mechanism for sender-constrained tokens because it introduces a burden on the server side to handle clock issues — which are non-trivial. Despite this, I believe there is a place for DPoP in the OAuth ecosystem and that it will reach a mature level of adoption for limited use cases.

Broad Acceptance

The sender-constrained tokens using mutual TLS (MTLS) specification is already the industry go-to for high-security scenarios. Mass adoption is only a matter of time. That said, it will remain a high-security technology since it requires a lot of challenging certificate management. Curity has done some interesting work to combine this spec with SPIFFIE to simplify the management burden. However, it is the only sender-constrained technique that exists for general use cases today. DPoP, as mentioned earlier, is useful too, but in fewer scenarios. There are discussions around using HTTP signatures as an alternative to MTLS for sender-constrained purposes. DPoP and HTTP signatures are intriguing but in their early stages — MTLS is the way to go for broadly accepted options.

The JWT Assertion grant type and JWT Client Assertions have reached broad acceptance. They should be considered to complement the original OAuth grant types and authentication mechanisms. These are mature, well-defined, and very close to mass adoption. So, what parts of the OAuth and OpenID Connect suite of specifications are broadly adopted?

Mass Adoption

Out of the funnel, we find the standards that are already deployed and used en masse. Almost all of the original grant types from the OAuth specification have reached this stage. The authorization code grant and the client credential grants are both widely used. Either or both are critical in most deployments. The companion specifications, introspection and revocation, are also already at this point. OAuth would not function without the JWT specification, so this spec too has exited the funnel.

When it comes to OpenID Connect, I disagree with Gartner's conclusion that it is in the Trough of Disillusionment stage. I say this because it caters to a wide set of uses, leading to mass adoption. It is not yet a fully-fledged replacement for SAML, but this should not be the measure of productivity. Even without the upcoming OpenID Connect Federation specification, the core of OpenID Connect is mature and extensively installed. I see very few deployments involving end users who do not utilize OpenID Connect. It just fits so well with OAuth and API security while providing extra value for identity management.

Lastly, the Dynamic Client Registration (DCR) and Dynamic Client Registration Management (DCRM) specifications for client creation and management are both well-established and frequently used building blocks in OAuth and OpenID Connect. They are here to stay.

Retired or Rejected

Some elements of OAuth were simply not meant to be. One example is the Resource Owner Password Credential (ROPC) grant type from the original OAuth specification. Even the original RFC says it was meant for legacy use cases. Today, there are better alternatives to provide native user experiences in mobile applications, such as the JWT Assertion grant or our Hypermedia Authentication API. So, consider the ROPC grant type rejected and avoid using it whenever possible.

Furthermore, the implicit grant type has gained a bad reputation despite its usefulness in some cases. It is no longer a recommended grant type and is reaching retirement.

Summary

Gartner's Hype Cycle provides valuable technology insights from a macro-level view. If you just consider API security, though, it's necessary to zoom in another level. The OAuth and OpenID Connect Adoption Funnel attempts to provide this magnifying glass, giving a better sense of where the industry and community are at in the development and adoption of core specifications and standards.

However, as with any technology map, things are not static — they move. Some specifications, like the token exchange grant type, are slowly making their way down the funnel, whereas others, like PAR, are pouring quickly through. It will be an exciting exercise to remap this a year from now. Check back then, and let me know in the meantime if you agree or disagree with my assessment.