Brian Campbell
Distinguished Engineer, Ping Identity

---

OAuth is Shooting for PAR

There’s a relatively new draft specification making its way through the Internet Engineering Task Force (IETF) process. OAuth 2.0 Pushed Authorization Requests, colloquially referred to as PAR, was adopted by the OAuth Working Group shortly after the fall IETF meeting last year in Singapore.

The 106th meeting of the IETF was held in Singapore in November 2019.

The PAR draft recently completed the working group last call process, which is an important step on the journey to becoming a Request for Comments (RFC). While nothing is truly fast in the IETF, PAR is believed to progress relatively quickly and with the expectation that it will remain stable enough with respect to the protocol definition to allow for interoperable implementations prior to becoming an RFC.

Now I realize that you might be thinking, “Wait a minute. With all the par talk, I was hoping this was going to be about golf, not Internet standards.” I get it and can commiserate. You can imagine my own dismay when I learned that my job at Ping wouldn’t involve early access to all of the latest golf equipment. But we’re in this together now, and it won’t take anywhere near as long as a round of 18, so let’s keep chipping away at it.

Not All Authorization Flows Are Up to PAR

If you’re familiar with the OAuth protocol, you know that initiating an authorization flow is fairly simple. The client just directs the user’s browser to the authorization server with the necessary protocol parameters in the query string of the URL. This simplicity has undoubtedly been a big part of the protocol’s success and is good enough for many situations.

The collective experience of the industry, however, has shed light on some drawbacks of this approach in certain circumstances, such as those driven by Open Banking requirements. In an Open Banking use case, the authorization request can contain sensitive information and become quite large and complicated. This makes the traditional means of sending the authorization request data in the query string problematic because:

• The request passes through the browser in the clear where it can be maliciously modified.
• The request risks running into browser URL length limitations.
• Query string data could inadvertently leak to web server logs and even to third-party sites via the referer [sic] header.

These problems were not entirely unanticipated, and some existing standardized solutions, such as signed and encrypted JWT based request objects, can help. But while they’ve seen some deployment and usage, these solutions have proven to be prohibitively cumbersome for many. I won’t go into the nitty-gritty details of why but let’s just say they weren’t quite up to par.

Staying Out of the Rough

PAR has codified a simple interoperable way for an OAuth client to push the payload of an authorization request directly to the authorization server. In response, the client receives an opaque value that it uses as a parameter when subsequently directing the user’s browser to the authorization server. The value serves as a reference to the authorization request data that was previously pushed.

Under the PAR specification, the authorization request still traverses through the browser but it’s length is fixed, and it doesn’t directly contain any data that can be seen or modified. The call to push the authorization request payload is authenticated the same way and has a similar format to the call to exchange the authorization code for tokens at the token endpoint

More than Simply PAR for the Course

Particularly astute readers—and those that have been around the block a few times with these identity standards—might be quick to point out that there’s nothing especially new in PAR. Indeed, nearly all our favorite identity protocols (as well as the not-so-favorites and even bespoke solutions) have had allowances for both pass-by-value and pass-by-reference style messaging. Examples of the former include a traditional OAuth authorization request, the from post response mode, and SAML POST and Redirect. While an OAuth authorization code, SAML artifact and now PAR are some examples of the latter.

While the direction of the messaging in PAR (i.e., a push rather than a pull) is somewhat less common, it’s not ultimately a revolutionary idea. But PAR’s value isn’t derived from its novelty of thought so much as its application. It applies proven concepts in a new and useful way.

Having said that—and to conclude by pushing just a couple more questionable golf references—PAR might best be compared to a good short game. It’s not as flashy as a long, powerful drive down the middle of the fairway, but it’s an important part of any serious player’s game. And you can experience PAR for yourself in the coming v10.2 release of PingFederate, our enterprise federation server that enables user authentication and single sign-on. Stay tuned for more details on that, and in the meantime, I hope to see you on the course!