PAR, RAR, and JAR with Filip Skokan

Vittorio Bertocci: Buongiorno everybody and welcome. This is Identity Unlocked, and I'm your host, Vittorio Bertocci. Identity Unlocked is the podcast that discusses identity specifications and trends from a developer perspective. Identity Unlocked is powered by Auth0. This season is sponsored by the OpenID Foundation. In this episode, we focus on various three-letter extensions to OAuth, which would fit well in a pirate novel: PAR, RAR and JAR. Our esteemed guest today is Filip Skokan, senior engineer at Auth0 and author of a very popular Open Source identity SDKs, and contributor of course to the IETF and OpenID Foundation. Welcome Filip.

Filip Skokan: Hi Vittorio. Thank you very much for inviting me.

Vittorio Bertocci: And thank you for being here. Thank you for joining me today. Can we start with how you ended up working in Identity?

Filip Skokan: Absolutely. It started in 2013 with myself moving to Germany actually. This was for a position in a games publishing company called ProSiebenSat Games. This company was operating a very popular gaming portal called Alaplaya that used to host a number of game titles. These were either in browser or had their own dedicated desktop launchers and even thick game clients. They all shared the login system though. The same account was used to log into the portal, to the shop, to the support center, and of course the game launchers or the game clients. The company was using Central Authentication Service protocol version 2. 0. This is a single sign- on protocol developed on Yale university, I believe somewhere in the early 2000's. It was one of the systems I ended up maintaining for the company. The company was eventually acquired and moved to Berlin, but it was the work done on it's single sign- on, and maybe even partially my engineering skills who knows, that got the group's CTO convinced I could deliver a special project for her. The project was the central single sign-on for the rest of the group's digital business. Important stuff, right?. But it had a caveat, it had to be in place quickly for the next season of a very popular reality TV show, think, Germany's Next Top Model or something like that.

Vittorio Bertocci: Trial by fire.

Filip Skokan: Yes, absolutely. So I knew back then already that CAS was out of the question. It wouldn't support the already looming and blooming, exploding mobile application landscape. So this was early 2014, I barely knew what OAuth was, but I remember OpenID connect was fresh out the oven. So I made a POC using in-house built proprietary OpenID Connect interface. It wasn't used in the end, but it was quotes "ready". And as we were going around the demoing the work that we got, we managed to onboard more developers on the project and began making it really production ready because the CTO and the product officers and the group of the product officer, they picked it up and they liked it. So we went along with it. We were forced to make compromises though along the way. So protocol conformance went out the window, but I was so intrigued by what OpenID Connect had to offer that I started work on my own OpenID Connect libraries for NodeJS. One of those being authorization server and the other one being the relying party so that I can test my own server. Cool. As I was developing this, I stumbled upon the connect certification program which is ran by OpenID Foundation. And I immediately wanted my software to conform to it. I wanted that certification badge. I wanted it really, really, really, really bad. And I don't know if it was bugs in my software or the certification suite, but I used to be that proactive in the issue tracker to make it onto the team that managed that certification software. Now, the team composed of big names and established names in the industry, Mike Jones, Roland Hedberg, and Hans Zanbelt. I was contributing feedback automation CI to test the suite. And while I was doing all of that, I was getting pretty firm knowledge of the different specifications that it was dealing with, mainly OpenID Connect core built on top of OAuth2.0 and so on, you know drill. And from there on, it actually gets a bit blurry because it went really fast. I got introduced to Pamela Dingle as the guy who tests the tests and you know how big she is on protocols and standards. So the next thing I remember was giving a talk at Cloud Identity Summit in Chicago. It really went that fast. In there by the way, I recall meeting you for the first time. You surely don't remember.

Vittorio Bertocci: Chicago was fun. A lot of fun. That's mostly what I remember of that conference.

Filip Skokan: They were really those open source projects I wanted certified and up to date with the latest specifications, the hottest draft that put me on auth0's radar because Ayth0 reached out to me, they said," Hey, you're writing OpenID Connect open source. We do identity as a service. Would you mind coming on board?" So I joined Auth0, moved back home to Czech Republic, and that relationship is still going strong today. While I'm supported by Auth0. I continue to contribute to OpenID Foundation, to the connect and FAPI Working Groups, the certification program, and of course the IETF OAuth working group, in all of those I keep up- to- date on the developments in those groups and feed that knowledge back to Auth0.

Vittorio Bertocci: Very nice. That is a great trajectory. And I like the hands-on component of it. So you have both knowledge of the protocol itself, but you also do things in concrete. So what they like to call a warrior priest, you know both sides of the house. And in fact that's what I'm hoping to learn from you today. And so I wanted to get into the main topic, which is a positioning a bit, the three acronyms that I mentioned as in of this PAR, RAR and JAR, what are those things? What problems do they solve? How they came to be? Imagine I know nothing about them, which is also reasonably accurate and explain to me what they are and why they are.

Filip Skokan: So you mean what those are aside from being a pirate incantation, right?

Vittorio Bertocci: That is exactly right.

Filip Skokan: So these three, they all deal with different shortcomings in the core OAuth2.0 specification, they are really the outcome of the, I think over 10 years of OAuth2.0 being in use, the different applications OAuth was applied to over the years called for these extensions. Because when you think about it, when OAuth was conceived, the internet application landscape was rather simple, browsers were far from being secure. TLS, wasn't being adopted as much, cores wasn't the thing at all. And in general, the service providers were handling maybe one to two authentication servers at a time, a few web clients and maybe a single resource server, whereas today the landscape is completely different. So let's start with RAR then, RAR stands for the Rich Authorization Requests. It's a draft specification under the IETF OAuth Working Group. And it brings more expressive power to your authorization requests. The core OAuth2.0 authorization expressiveness is really simple, and it was designed to be simple, but in so it is also limiting, you have your scopes, maybe recently standardized resource indicators to be able to tell which resource server those scopes belong to, but that's it, you can't specify more than those two dimensions and sometimes not even that just scopes and what you're often left with is just those scopes. It's limiting there's no way to express complex authorization needs.

Vittorio Bertocci: And the funny thing is that people also like to misunderstand scopes, let's say that men with their hammer syndrome, given the scopes were the only things available, I think you have seen your portion of it, people are abusing the scopes for expressing all sorts of different concepts, which scopes weren't originally designed to support.

Filip Skokan: I have seen authorization requests with scopes overloaded to do whole bunch of stuff to a point where they didn't fit into the URL length that is permitted. So it is a framework for communicating those complex authorization structures in OAuth2.0. It originated in the FAPI Working Group since in there they needed the expressive power to transmit authorization requests, such as, " Hey, initiate the payment transaction of 125 euros to merchant A, and while you're doing that, give me access to an API so that I can query the results of said transaction." So I dare you to express that with scopes. It's not possible.

Vittorio Bertocci: That sounds pretty tough.

Filip Skokan: So what RAR does to address this is, it introduces a new authorization request parameter called authorization details, which is a JSON structure. And with JSON comes power, you have all that syntax available to you, you have your properties that can be erased, they can be nested objects and so on and so forth. And with that, you can express such a request that we have just mentioned. The specification itself does not prescribe the shapes of these requests, but it specifies how those are transmitted from the client to the authorization server, and then from the authorization server through an access token over to the resource server that I'm about to use.

Vittorio Bertocci: That's very handy. That's great. Fantastic. Thank you. Now I understand what that RAR does. What about JAR?

Filip Skokan: JAR another pirate acronym originally came from OpenID Connect and it allows the authorization request that's being transmitted via the browser to be integrity protected, to have its origin verifiable, to be nonreputable and also optionally to be confidential so that no one but the authorization server can tell what goes over the wire. And it does so by making the authorization request a JWT and you know JWTs can be either signed or encrypted or both.

Vittorio Bertocci: I see. So it defines a syntax for which you can embed the parameters that you would normally just place in your query string. And instead of their it's structured those so that they can live in a JWTs and then you can sign them, you can encrypt them, you can do all of the stuff?

Filip Skokan: That is correct. And it gives you two different means of being able to transmit that. You can either put the whole JWT in your request as a request parameter, or you can just refer to an object that you have stored somewhere on the internet, which when retrieved by the authorization server, by request URI yields, the same object.

Vittorio Bertocci: That's super handy as well. Okay, great. So now let's get into their main dish of dinner, which is PAR, and I say is the main one, because the PAR is the spec you are an author on. So I expect you know that thing in and out. So what is PAR about?

Filip Skokan: So PAR or otherwise Pushed Authorization Requests, and RAR actually go hand in hand, because that expressive power we talked about with RAR comes at a cost, and that cost is that the requests get large. They get large because regardless of how you express those authorization details, via proprietary parameters or overloading scopes as we talked about that we've seen sometimes, you still have JSON blob that you need to pass through the URL. And they do get large to a point where they cannot fit into a URL and the browser will just truncate them, and then the authorization server can't process. So PAR deals with this by pushing the whole authorization that usually goes via the URL in your browser to a server to serve a call.

Vittorio Bertocci: That is really helpful. So how does it do that? You already said that RAR defines the format, then what is in PAR that makes it possible for this thing to be a server- to-server flow?

Filip Skokan: So PAR introduces a new endpoint on the authorization server called the Pushed Authorization Endpoint, if I recall correctly that is, and the client communicates with that endpoint very similarly to how it would with the authorization endpoint uses the same encoding to send the request in the request body, but in addition to that, it also authenticates. So the client can send its client ID and client secret, and it can also use mutual TLS authentication or private key JWT, If it's so wishes.

Vittorio Bertocci: So, the advantage of adding this thing appears to be that- It's not just a matter of size in which you can have like larger requests, but it sounds like you can behave a bit like the token endpoint and the fact that I can send my authorization parameters with at the same time authenticating the identity of my client if my client is confidential is an extra property that makes things more secure. So there's also that it's pretty nice, right?

Filip Skokan: It is. And it was one of the design goals to make it more secure. But there's some other side effects as well, since it is a server- to- server call, it allows the authorization server to validate the full authorization request pretty early, which in the end improves developer experience because you're no longer waiting for those redirects, you're no longer trying to complete the actual authentication to get feedback to your relying party.

Vittorio Bertocci: Okay, great. That sounds great. That is indeed a server- to-server call when the client happens to be a web app, in which case it's the back end of a web app talking to the authorization server - so server- to- server. However, I guess that you could do these also from say a mobile client, in which case it would be the code running on the device and that reaches out for the pushed authorization request endpoint. So it could not be a server- to- server flowing in that case, correct?

Filip Skokan: That is correct. Yes. In that case though, the client would not authenticate as it is a public client. It may be a credentialed client in the sense of OAuth2.1 that you talked about with Aaron quite in the last season, however, the client still gets the benefit of not going over the size limit of the URL.

Vittorio Bertocci: Yeah, you're absolutely right. The main advantage there would be the size, because in term of credentials, the credentials aren't really there, but then what happens next? Let's say that the client hits the authorization server on the pushed authorization request endpoint and the authorization server decides that yeah, that it looks like a well formed request and similar, what happens next?

Filip Skokan: So what happens next is that the authorization server responds to the client with what's called the request URI, now to the spec savvy, they may recognize the request URI to be something defined by JAR, which we also talked about. And that's also intentional. So what the authorization server response with is a request URI that the client then turns to and sends over to the authorization endpoint as if it was using JAR. Now the authorization server will process its authorization endpoint pipeline and it will see request URI, it will denote a location that the server recognizes is something that it's stored itself internally in a database or somewhere. And then it will go on and process the rest of the request as usual, only it didn't have to pass the request again. It was already validated once.

Vittorio Bertocci: So to summarize, once the authorization server accepts the pushed authorization request, it saves all of those parameters somewhere in whatever format it wants and sends back this request URI and then it expects it to receive it. And once it receives it back from their authorization endpoint, it just uses it to look it up to whatever and then part of the work is already done, but from that moment on it's business as usual, like if I would have placed those requests parameter say in the authorization request to the authorization endpoint, is that a fair summary?

Filip Skokan: That is a fair summary, but in doing all of this, you didn't exceed any URL limits. So win- win.

Vittorio Bertocci: Very nice. That sounds super handy. All right. Great. So I can say at this point that we shed light on RAR, JAR, and PAR. We know what they are for. Now, in term of where they are in the standardization process, how close are we from calling those guys done.

Filip Skokan: Right. So at the moment they are all drafts. JAR is very, very long in the making, but since it originates from a stable OpenID Connect as a donor, it is pretty stable. And I believe Working Group Last Call has happened at least twice now. So yeah, pretty stable, at least from my point of view. PAR has a Working Group consensus. It has gone beyond the Working Group Last Call and is awaiting a number of write-ups. I don't want to get ahead of ourselves, but it is pretty stable as well.

Vittorio Bertocci: That's great. So we are close, in the identity standards terminology, which is not the fastest thing possible, but hey, we need to proceed with caution, but close to be done. So that's great.

Filip Skokan: And that leaves us with RAR, RAR is still with its authors, but I'm seeing the activity in their repository, they're hard at work. They are still collecting feedback and they will hopefully be starting a Working Group Last Call very soon.

Vittorio Bertocci: That's great. That's fantastic. I know that a lot of people are looking forward for that. All right. Well, that was awesome. I finaly understanding of what those AR extensions are for, that was really handy. So Filip, I want to thank you for your time and I guess I'll see you in Slack.

Filip Skokan: All right. Thank you for having me.

Vittorio Bertocci: And thanks everyone for tuning in until next time. Thanks everyone for listening. Subscribe to our podcast on your favorite app on an identityunlock. com, until next time I'm Vittorio Bertocci, and this is Identity Unlocked. Music for this podcast composed and performed by Marcelo Woloski. Identical Unlocked is powered by Auth0 copyright 2020 Auth0 Inc. All rights reserved.