What's new with OAuth2.1 with Aaron Parecki

Buongiorno everybody and welcome. This is Identity, Unlocked and I'm your host, Vittorio Bertocci. Identity, Unlocked is the podcast that discusses identity specs and trends from a developer perspective. Identity, Unlocked is powered by Auth0. In this episode, we focus on OAuth 2.0 and our esteemed guest today is Aaron Parecki, Senior Security Architect at Okta and prolific IGF contributor. Welcome, Aaron.

Aaron Parecki: Thank you for having me.

Vittorio Bertocci: Thanks for joining me today. Can we start with how you ended up working in identity?

Aaron Parecki: Yeah, that's an excellent question. I kind of stumbled into it when I was building out an API a while ago for my startup and I needed to add OAuth to that API. It was very clear that that was the way forward. This was actually when OAuth was pretty new so it was clearly the way forward. I didn't know anything about it and I decided I just needed to learn about it. And I tried to read everything I could, there was not much online at the time because this was around 2010 and OAuth 2 was in the middle of its life cycle, was not yet in RFC and that's really how I got into it. I just had to struggle my way through the specs like everybody else.

Vittorio Bertocci: Very nice. How did you go from your startup to your current position and what do you do today?

Aaron Parecki: So I really got dropped into this when I took over the website OAuth. net from Eran Hammer. He quit as the editor in a bit of a fit of rage and with a lot of publicity and right before that he had given me the website and just suddenly I found a zip file full of PHP files in my email. So I set it back up in my own server and got that back up and running and was just about as surprised as everybody when he gave that talk. But at that point I was like, well, this is just my life now. This is my life now and I didn't realize that I was going to be in this for a while, but again, I really enjoyed working with it and I had been working on writing a book at that point already about helping people learn about OAuth because I was as frustrated as everybody else about how complicated it is to learn and how little information there was online. So I wanted to really help that out and I figured that writing about it and doing talks about it at conferences was a good way to help people learn about it.

Vittorio Bertocci: And how did you get your current position? We left you in a startup but now you are with Okta so what happened in the meanwhile?

Aaron Parecki: So in between the startup years and where I'm at now at Okta, the startup was acquired and I worked there for a while at the company that acquired the startup and still doing a lot of the work on OAuth and on the book and doing talks and things like that. I got connected to Okta because of the book I was working on and ended up actually finishing out that project by publishing the book through Okta and that was a sort of joint effort and they're listed as the publisher on the book, of course. And that kind of turned into a great working relationship. I started out as just a independent project with Okta and I was working with a few of the people there on that as well as some related projects around small tools or blog posts, and really enjoyed working with them. There's a lot of good people there and that turned into a job offer where I then got brought in to do more education around OAuth. So at Okta I do workshops where I teach developers about OAuth, about the specs and help them learn about how this all works and how to make it secure. I also still continue to do talks at conferences and continue working on the specs all while supported by Okta.

Vittorio Bertocci: Very nice, although with COVID we are not seeing a lot of conferences nowadays.

Aaron Parecki: Not a lot of In person conferences right now but I still have been doing a handful of virtual conferences and the workshops, of course, I've had to move entirely virtual. So I used to do these workshops where I would fly out to a company's office and give a presentation in front of a room of 30 or 50 developers and that's all happening on Zoom now. So it's been an interesting shift, but I've been enjoying it still.

Vittorio Bertocci: Definitely. And then the last conference that we ran into each other was just a few weeks ago. The off security workshop in Norway, air quote.

Aaron Parecki: Air quotes in Norway. I was very much looking forward to going to Norway but that was not in the cards this year but the event was still pretty fun. It was a good event.

Vittorio Bertocci: Okay, that was great ut the thing that I really, really didn't like was that it was in a European time. So I think I crosstalk didn't work that well with that but it was worth it to wake up very early in the morning few times.

Aaron Parecki: It was. We had the short end of that stick on that deal being on the West Coast of the US.

Vittorio Bertocci: Indeed. Talking about conferences, how you and I met actually? Help me remember.

Aaron Parecki: I believe we met at an Internet Identity workshop. I don't remember which one, but I do remember meeting you there and having a conversation about, I think you had recently joined Auth0. I think that was right after you had left Microsoft. Does that sound familiar?

Vittorio Bertocci: That's plausible. Although I suspect that we might have run into each other also earlier but my memory is getting worse with age. But yeah, IIW is very plausible. Then which IIW is anybody's guess. All right, perfect. Thank you for that intro. It was very interesting. It's always nice to see the tortoise trajectory that every identity that he follows to land on identity and the reason for which I invited you on the show and again, thanks for being here with us, is to talk about the one project that you took the lead on which is OAuth 2. 1. Can you tell me a bit more about what it is, why it's happening now?

Aaron Parecki: Yeah. Well OAuth 2.1 is a revision to the core OAuth 2 spec and the overall goal, the overarching goal of OAuth 2.1 is to really simplify what we're saying in the spec. It's to make it a lot more approachable and easier to understand. One of my main motivations for that is driven because of how much education and trainings I've been doing about OAuth and I see how people struggle with it. I see how many documents people have to read and how complicated it is. And once you actually get all caught up and have read all 400 pages of all the specs, there's actually a much simpler picture left. So one of the goals with OAuth 2.1 is really to reduce the amount of reading that's required to get up to the current speed of where we in the OAuth industry understand the best current practices are.

Vittorio Bertocci: So you mentioned 400 pages but they OAuth 2 core is massively less than that. So you're not referring just to OAuth 2 but to a larger number of documents, right?

Aaron Parecki: Exactly. So OAuth 2 was published in 2012. That was when it was finalized. And 2012 was a while ago now and a lot of things have changed. Mobile apps got a lot more popular, browser apps have changed and we have this very common pattern of building single page apps. There's a lot of things in the environment that have changed. Cryptography has changed. It's a lot easier to deploy HTTPS now and because of that, there's been a lot of updates to the spec already in the form of new RFCs. So there's things like the recommendations for native apps, there's PKCE which is a security feature for native apps and other public clients and now confidential clients as well as security research on OAuth has shown. And there's just a handful of these other documents. I think 400 pages is actually a pretty accurate representation. If I just flipped through my little book of my collection of RFCs, I've got them all printed out in a book here and it's eight or 12 RFCs stacked together because that's how many you actually have to read in order to get a picture of what OAuth is actually like today.

Vittorio Bertocci: Wow. Yeah. That is a large amount but it's interesting that you actually killed a few trees for having a 3D printed inaudible of the RFCs and it's a really good idea. I might do the same. Okay, so crosstalk. Thank you, that would be fantastic. So the idea is that off to that one is a digest like the best parts of these large collection of documents that accumulated to extend and better specify what was there OAuth 2 core?

Aaron Parecki: Yeah, so, well, if you look what happened at with OAuth, OAuth 2 defines a lot of things in its original RFC and then there's a handful of new RFCs that come in and add more features. Adding features like PKCE or adding the device grant or adding additional security properties in the security recommendations. But some of those also remove features from OAuth. So some of those later documents actually say that wasn't actually such a good idea in the original document let's say, let's not do those again. So that actually means that if you want to follow the best current recommendations of OAuth, you end up having to read all these different documents and then understand which things have been added and what should have been removed. So with OAuth 2.1, the idea is to roll those all up, play all the documents in order and then what you get at the end is the best current practice of OAuth 2 and that's OAuth 2. 1.

Vittorio Bertocci: Great. So it's a one stop shop for people that actually do read the specs because here, one thing that I like to remind us experts is that a lot of developers, they really don't need to actually go on the spec. As in, if they are adding sign in to their website and they're using inaudible and SDK and [inaudible 00: 10: 03 ], there might be specs but if someone do want to read the specs, understand the strategic value, that action implications, security practices and inaudible than with these, we do some of the work for them as in we already compile the most relevant stuff.

Aaron Parecki: Yeah, definitely. I mean, we don't expect that every developer who's interested in adding OAuth to their application is going to be reading the specs because that's not really who the specs are for. The specs are for the people who are building the tools that people use to add OAuth to their applications. People who are actually building OAuth servers or building libraries to do this stuff. That's who the specs are for.

Vittorio Bertocci: Fantastic. Thank you for saying that in such a nice, direct, classic browse stance. I love it. All right. So let's dig deeper in the meat of what we have in there. In particular, thinking about what's in the OAuth 2 core and doing a mental diff with the current form of [inaudible 00: 11:07]. What are the main things that we are adding in the core?

Aaron Parecki: Yeah. So the main things that we are adding to the core will be PKCE because that is essentially how everybody knows that we need to do OAuth for mobile apps. That's documented in RFC 7636. There's also the RFC 8252 which talks about other recommendations for mobile apps. So those are security features for mobile apps.

Vittorio Bertocci: For mere mortals, let's spend a few seconds to say what PKCE is.

Aaron Parecki: Sure. So before the world of mobile apps and public clients was this widespread, we have this idea of apps getting a client ID and a client secret and the client secret is essentially the app's password and it's assumed that the client secret is able to then protect the flow because nobody except the actual app developer can ever get that secret because it's treated like a password. That's not possible for mobile apps to do. It's not possible to deploy an app in the app store and give it a client secret because it just wouldn't be secret anymore cause you're giving a copy of it to everybody who downloads the app. So because of that, we need something else to protect the flow because without the client secret, we have this problem where someone could intercept an authorization code and use that without a client secret and that's kind of a big gaping hole. We want to do better than that so instead of a client secret that's registered, PKCE essentially creates a secret for every request, for every authorization request. Every time the app starts, the OAuth flow, it generates a new secret itself and then uses that to complete the flow. That's definitely a high level summary. That's not the step by step, but that's essentially what's going on.

Vittorio Bertocci: Of course. We then need to go into the low level but the high level thing is PKCE is a trick that we can use for making the redemption of authorization called less susceptible to abuse and what originally was introduced for mobile apps in particular. I remember that it was when there was a big push toward using the system browser because there's always actually communication between the app and the system browser and so more opportunities for the code to be stolen. And back in the day, it was meant only for public clients but now instead in the OAuth to that one that we suggest that it has to be used for every authorization code grant, right?

Aaron Parecki: Yeah. And this is something that's relatively recently recommended in the security best current practice. This attack that this is protecting is a pretty subtle one and probably too detailed to explain in audio form in this short podcast. But I do have some videos on the Okta developer YouTube channel that actually talk about and walk through this attack. The attack is the authorization code injection attack. And the idea is that even with the client secret, it's still possible that someone could sort of swap authorization codes with a victim and either trick them into logging into your account or log into somebody else's account. And it turns out PKCE prevents that attack, which is great. And it prevents it because it's a per request secret. So that's why it's actually useful for confidential clients as well.

Vittorio Bertocci: That's great. So first the big addition is we are adding PKCE everywhere. Great. What else? What else are we adding in to that one?

Aaron Parecki: Yeah. We are adding the still in progress draft about recommendations for browser- based apps. That's one of the other ones that I'm working on in the group and the idea there is that supposed to compliment the recommendations for mobile apps but in the browser environment. And it's actually not adding too many new features itself. It's mostly just sort of echoing things like use PKCE and follow the recommendations in the security best current practice. And then it goes and talks about browser specific environments a bit. But then one of the other things it's adding is some stricter requirements that are defined in the security best current practice document. So, that one is going to do things like adding a requirement that redirect URLs have to match exactly. And that's something that technically the OAuth core spec doesn't require. It gives some carve- outs for some exceptions to that, but since that's been written it's become very clear and everybody agrees that exact redirect URL matching is much more secure.

Vittorio Bertocci: Absolutely. So off to that one now in no uncertain terms, we require strict redirect URL match?

Aaron Parecki: Exactly.

Vittorio Bertocci: It's going to be interesting because I know that a lot of practical applications make use of things like wildcards or certain deployment platforms like Heroku and [inaudible 00: 15: 54 ]. They don't tell you the URL until the deployment is done. But I guess with those scenarios would be mostly for... Like there are developer scenarios in which it gets better. Things can be relaxed here and there instead there are some of the multitenant scenarios in which compliance with this particular ruler might end up being more complicated.

Aaron Parecki: Yeah. We'll see how it goes. The problem is that it's not just an arbitrary rule. It's actually serving a very important purpose, which is to avoid opening up an open re- director within a system, which is actually not even an OAuth specific attack. So we just want to make sure that people aren't opening up themselves to other related attacks.

Vittorio Bertocci: Yeah, absolutely. The fact that it's a good thing to acquire this thing from a security perspective, it's not in doubt. Not in the slightest. It's more of some of the adoption practice might lag a bit but that doesn't mean that we shouldn't recommend that. All right, great. So that's another good addition. What else can we think of?

Aaron Parecki: There is also some new requirements around refresh tokens and this is something that's again, coming from the security best current practice which is where it was originally written up. The idea there is that refresh tokens themselves are very powerful because well, without a client secret, a refresh token is very powerful. If there's no client secret with the application, which is true for both mobile apps and browser based apps, then the refresh token is all you need in order to get new access tokens. So if someone were able to steal a refresh token, then they could then use it to get new access tokens and the problem is that you can't detect that that's happening. So it's possible to get new access tokens while the app continues to work normally. So the idea with this new requirement is that it says that refresh tokens should actually be single use. And what that does, it means that if a refresh token is stolen by somebody and it's used by the attacker, it will then also later be used by the real application at which point the OAuth server can say, okay, I can see something went wrong. I can see that this has been stolen because I see two different uses of the same one and in normal operations, this should only have been used once. And then it can actually shut down, not just that refresh token, but it can shut down all access tokens that have been issued to that refresh token.

Vittorio Bertocci: Great. So this one is the requirement of having these famous rotating refresh tokens in which whenever you use a refresh token, that particular instance stops working and when you use refresh token you get a new refresh token together with access token and then if you are not the correct recipient, then if you use the old one, you just invalidate you described. Great. So, that's one constraint. Then we also have a different constraint on top of that or an alternative to that, right?

Aaron Parecki: Yeah. So the idea is to prevent refresh tokens from being all powerful on their own and prevent this attack, right? So the other way to solve this problem is to do some form of sender constraining. And that's something that you can do in mobile apps with client certificates. There's several different options you have available and some that I'm sure we haven't thought of yet, but the idea is to make it so that again, the refresh token by itself isn't actually useful. You need something else in order to use the refresh token. The problem is that with browser- based apps, there aren't really any good tools available although you could kind of argue that you could use cookies to accomplish something similar. HTTP only cookies. So we'll see how that plays out because there's some, you could argue it. It's also worth mentioning this part of the spec, especially, well, the whole, whole OAuth 2. 1 or especially this part of the spec, it's all very much in progress and it is influx. None of this is by any means finalized right now. So these are things that are up for discussion in the group right now and this is a good time to chime in if you have opinions about this because we do want to make sure that we're addressing real feedback from people who are actually building this stuff.

Vittorio Bertocci: If that's indeed what's happening like we had a discussion about whether these particular requirements should be a must or a should and the latest at this point was that we were going to require a must for applications running in a browser given that there are many attack venues that can occur in the context of a user agent, but instead allow safety to be a should for mobile and desktop apps in which their threat model is not as serious. But as you mentioned that's in flux. Then also we had one episode of Identity, Unlocked with Brian Campbell in which we explore the sender constraints. So both MTLS and DPoP so potentially these can [ inaudible 00:20: 47 ] so that's great. So the last thing that I wanted to hear from you about these new client flavor which OAuth 2.1 is introducing.

Aaron Parecki: Yes. So OAuth 2.1 is also defining a new term and before I talk about this, I do want to mention that one of the explicit goals of OAuth 2.1 is to actually not define any new behavior that doesn't already exist in the OAuth 2 world and in the OAuth 2 collection of specs that are being rolled up. It's really meant to be a consolidation, not actually defining new stuff. So we're trying to not make up new things. That said, we are defining a new term. The new term we're defining is called a credentialed client. So today we've got confidential clients which are applications that can be deployed with a client secret. We also have public clients, which are applications that can't be deployed with a client secret. However, if you actually read the spec, you will notice that there are several places that use the term confidential client and then also have a following sentence that sort of qualifies some additional types of clients that might need the behavior that's then being described, but they're not public clients. So that happens in a few places in the spec. And essentially what that means is we noticed that there is actually a third type of client that's being talked about but doesn't have a name yet. So the third type of client is a credentialed client. That's just our current name for it. It is a client that has credentials but whose identity has not been confirmed. So I can talk about this for a second. Confidential clients both have credentials and their identity has been confirmed. The identity confirmation of the client is usually done through the process of actually registering the client. So you can imagine within a closed system like a company's own deployment of OAuth, the administrators of that OAuth server are the only ones who can issue client credentials. So they're only going to give client credentials to applications who they know are real applications. So those applications both have credentials and their identity has been confirmed. Now that's not the case with public clients. Public clients first of all, can't have credentials, can't have a client secret. They can get a client ID, but that client ID gets included in deployments of the app. Like you put it in your single page app source code. Everybody can see it. It's not a secret which means anybody can use it and impersonate that application using that client ID. So it's not a credential and any use of it does not confirm that app's identity. So there's something in the middle though which is a application that does have credentials but whose identity is still not confirmed. And probably the most often places going to surface is using dynamic client registration. So you can imagine a mobile app has deployed with no client's secret in the app store because it wouldn't be secret. But the first thing it does when it turns on is it goes and registers itself at the dynamic client registration endpoint. And one of the things it gets in response to that is a client secret. So that client secret identifies that particular install of that app, but it doesn't actually prove that apps identity because that request to get the client secret was unauthenticated. Anybody can impersonate that request. So after the client secret is issued, then all of those calls are authenticated and confirmed to be as part of that instance of that app but the identity of that app is not confirmed.

Vittorio Bertocci: Fantastic. So summarizing, basically this is a public client that at early use is issued a credential and so now you can use that credential to prove that in subsequent transaction, this is the same client, but you still don't know exactly who that client is. It's just like you maintain some kind of continuity and some proof, but you still don't have a strong application identity associated to it.

Aaron Parecki: Exactly.

Vittorio Bertocci: Wonderful. Great. So there's more stuff, especially in the advice parts like the security, privacy considerations. But before we run out of time, I'd like to hear about even more important grants of the things that we are omitting in the study we had in core. What do we have there?

Aaron Parecki: Yeah. So probably the most significant things you'll see that have been taken out are the implicit grant and the password grant and this is for a couple of reasons. If you look at the security best current practice, it actually already effectively takes out these two things from OAuth 2. The security best current practice says you must not use the password grant. It also says you can't use the implicit flow. So what we're doing with 2.1, we're not repeating the text from the security best current practice, we're actually just leaving them out completely which essentially shortens the spec quite a lot and it means that you don't have to even learn about them because they're just not relevant anymore. So we're taking out the password grant and taking out the implicit grant.

Vittorio Bertocci: That's great. It was again, excellent security decisions. Just to make a couple of practical considerations, these probably will not mean that people will stop using username and password in their API codes. It just means that they will no longer be compliant with OAuth doing so. And that's okay, right?

Aaron Parecki: Yeah. So there are lots of deployments that do accept a password from an application and then go to exchange it for tokens. Now that's a lot better than what we used to have before anything like OAuth where applications were sending passwords to APIs using HTTP basic auth. That's an improvement. It's token based authentication and that's all great. However, that wasn't really ever the goal of Oauth. The point of OAuth was to avoid applications touching passwords because there's always this problem that you can't really trust the application and what it's doing with that password. Now, really that started because the original goals of OAuth were to support third party applications built into APIs. And it's very obvious that you don't want third party app developers handling passwords from users. Once you start bringing out into the world of first party applications, it gets a little fuzzier because if you actually can audit your applications and you are more comfortable with what they're doing and who's building them, you can be much more confident that they're not accidentally mishandling passwords. That said there are still a lot of good reasons to avoid handling passwords in applications even today. Probably the biggest driving factor is the addition of multifactor authentication support. It's not really possible to extend the password grant to support multifactor authentication unless you just start making stuff up and making stuff up is going to be fraught with, you know, that's a whole can of worms or dragon's layer and you're just totally left on your own to add that. So instead, by using a proper redirect flow in OAuth, you actually just make it the OAuth server's job to handle multifactor authentication and the app developers don't need to worry about it. And this becomes really appealing once you start imagining that you have actually lots of different app developer teams working on this altogether and they may not be trained in security, may not be security experts, so you actually would rather focus your work on protecting the OAuth server or outsourcing that to a company whose job that is their specialty. Making it so your app developers don't have to do any work around handling passwords.

Vittorio Bertocci: Yeah, I'm sure that we both had the experience through the years of having to give the speech to our customers who were dead set on wanting to use the username password and I like that you brought up the first party part because the scenario in which someone owns everything, including their own authorization side of it., we might say wait a minute, I'm already sending passwords to myself because that's the page that I'm running and I understand all the thing about Consent, MFA, Home Realm Discovery, all the good things that you can get when you have a page in the middle but ultimately when someone owns absolutely everything hand to hand, sometimes we are dead set into doing a username password from a native UI, for example. And the message we've offered that one is if you really want to do that, that's the scenario. Let's not contemplate it by off. Again, as you mentioned, it was third parties. So if you are a first party, a lot of the laws of physics no longer apply for [inaudible 00:29: 26 ].

Aaron Parecki: Sure, sure. Well, I think one of the ways you can read into this is that, OAuth 2. 1 isn't actually saying, don't use the password grant. It's just not defining it. So basically it's just not in scope of OAuth anymore. That's what we're saying. So if you do want to send passwords from your applications to your APIs, you can do it, you're just on your own when you do it. Like you can do whatever you want, right? You don't have to use Oauth. if you don't use OAuth you're then on your own in terms of figuring out if you're building something that's secure or not. Whereas if you do use OAuth, you get the benefit of all of these companies and all of these people spending a lot of collective effort thinking about the security of OAuth. You know, we were just at the OAuth security workshop where that's a lot of people and a lot of thinking going on there about and analyzing the protocols and making sure that people are building things securely. So if you're just sort of going off on your own, well, it's up to you to validate it, right? So what we're doing with the password grant is we're taking it out saying this is not something that's been vetted and known to be secure by the OAuth community so you're on your own.

Vittorio Bertocci: And that makes complete sense. As in standards are there, they have benefits. People can choose to take advantage of those benefits or they can choose to carve their own path and they take full responsibility. Okay. We are rapidly running out of time. There is one particular thing that I want to make sure that we cover which is you mentioned that we no longer include the implicit grant. I had the good discussion on the show with Daniel Fett about the values implications of implicit grant and why it's a good idea to drop it. The one thing that I wanted to clarify is this doesn't necessarily affect things that are being built on top of implicit ground, for example, by OpenID Connect when they introduced the form post, right? One thing that I'm finding myself very often doing is hearing people saying," We can no longer use the form post with OpenID Connect if we're doing web sign on because implicit is being deprecated." Every time I have to tell them no, it's not exactly that way. So can you expand a bit on what's happening in there?

Aaron Parecki: Yeah, it's pretty subtle again. So again, OAuth 2.1 is not defining the implicit grant which means the only response type you'll see in OAuth 2.1 is response type authorization code. So essentially a response type token is just missing from 2.1. So what that does is, again, it means that what we're saying as the OAuth group, is that using the implicit grant as defined in the OAuth core spec, we no longer believe is secure. We actually never believed it was secure. Everybody knew it was not secure. It's just, there weren't a lot of alternatives at the time but things have gotten a lot better and there are alternatives. Namely, browsers can use PKCE now but what we're doing is we're just leaving it out. So again, if someone wants to come along and define a new response type called token and use the rest of the OAuth framework as well, as long as you're doing that securely, it's fine. You're building an extension to OAuth 2.1. So you could think of OpenID Connect as that because Open ID Connect can be secure for the most part, with the response type that looks like the implicit flow. However, there's a bunch of features in OpenID Connect that make it that way. So one of the biggest problems with the implicit flow is the access token injection possibility where it can't be detected by clients or a server. So OpenID Connect prevents access token injection by adding a bunch of extra properties into the ID token that's issued where the client can then validate that the access token is legitimate and is actually from the OAuth server. That's it, that's not my favorite option because that relies on your clients enforcing that and doing that validation. So the OAuth server is never really actually sure that the client's doing it whereas PKCE presents that same attack but from the OAuth server's point of view. And again, if your end to end building everything from scratch, it's basically equivalent, but if you don't necessarily trust all your client developers to do the right thing and you want to make sure they are, then you use PKCE instead.

Vittorio Bertocci: Right but here, the thing that I'm looking at is like even ignoring the access token to begin with and only trading in ID tokens. If you do form a post and you just send an ID token, a lot of the reasons for which implicit was dropped are actually not in play. Like when we say implicit, we say, basically we are only saying we are getting tokens directly from the inaudible endpoint instead of going from a token endpoint. And a lot of the problems here were that the talking was in the query string, for example. Or in general, in the URL. In the past, it never appears in the thing. So you'll never get it in the referral headers. You'll never get it in the browser history. So in general, you are like a lot of reasons for which we no longer want to do this for access tokens don't really directly apply to the ID token using the form post. So again, I think that what we've established is that when you say you are on your own, you are completely right. People will be doing something very risky. It's their choice. But in this particular case, a lot of the security reasons for which in places are no longer included, just don't apply to a form post with just the ID token,

Aaron Parecki: I think more importantly than that, it's actually that ID tokens and access tokens have very different security properties. So if someone can steal an access token, they can go use APIs, they can modify data, read lots of data, right? That's definitely bad. We all understand that. So we want to go to great lengths to make sure that the risk of access tokens being stolen is low and the implicit flow, or rather response type token, any flow involving response type token has a risk where the access token may be stolen as part of that redirect. Now the risk goes down a little bit by using form post instead of response mode of fragment but the risk is still there. However, it's now reduced with form post. However, if you're never returning an access token, if you're only returning ID tokens, the threat is completely different'cause what can happen if someone steals an ID token? Well, they can read the ID token, right? It's a statement about a user. It says their user ID. It may also include their email address depending on the server or their name. If that is leaked, that is the extent of the damage done. That the attacker now knows that information. You can't actually do anything with it because clients aren't going to let you arbitrarily drop ID tokens into other clients. You can't send it to an API to make an API request. So the risk of an elite ID token is much, much lower, which is why using response mode or form post or even fragment where you're only getting an ID token has a very, very different risk level.

Vittorio Bertocci: Fantastic. That would be all beautifully true in theory. Then as soon as you go through Kubernetes cloud in which they use ID tokens like access tokens. This suddenly is [crosstalk 00:36: 45 ].

Aaron Parecki: Well, that's probably a good thing that crosstalk access tokes.

Vittorio Bertocci: Exactly. And I think we had helping them because the main reason for which they do that is that they want a token that they can validate. They want a token which carry info and by introducing a profile for JWT for access tokens, we are basically giving them the functionality that they need in access tokens and so hopefully we'll manage to convince them to stop doing that. But anyway, that's for another time. I think we are over time and this is going to be a bit longer than the classical episode of the show, but I'm perfectly fine with it because I think this was super interesting and it was illuminating'cause a lot of the things that we said are not immediately clear unless you actually participated in some of the discussions. So I'm sure that people will really appreciate the wisdom you shared today. So I wanted to thank you for your time and I hope that we'll have a chance to have you again on the show soon.

Aaron Parecki: Absolutely. Yeah. Thank you.

Vittorio Bertocci: Great. Thanks again and thanks everyone for tuning in, until next time. Thanks everyone for listening. Subscribe to our podcast on your favorite app or at Identityunlocked. com. Until next time, I'm Vittoria Bertocci and this Identity, Unlocked. Music for this podcast composed and performed by Marcelo Woloski. Identity, Unlocked is powered by Auth0.