OAuth Happy Hour - Authorization Code Injection Demo and Live Q&A

good morning thank you for joining we are yeah we were trying out something a bit different today and did a whole bunch of audio checks and then didn't actually test out how we were going to start the stream so now we know that for next time cool well glad you're all here now that's how we learn thank you all for joining um I would love to actually know who is here in the chat so why don't you go ahead and say it's something tell me where you're joining from we've got a bunch of people in the chat here so go ahead and tell me what city you're in what country you're in and we'll see who we've got nice Seattle I'm in Portland Virginia Beach I don't have my own chat my own chat window here I'm chatting as chatting it's octave dev nice look at that people from all over yes awesome Mexico Roberto from Mexico Austin oh hey Matt's here too and that's a co-worker of ours Matt Denver filling in the map pretty nicely here this is great um andreas good to see you again from Germany I believe you were here last week Morocco wonderful this is fantastic cool well that's an excellent crowd so today we're going to cover we're gonna talking about a couple things we're talk about a little bit about what happened this week in in the world of ooofff going to do a demo of Micah's got a pretty cool demo cooked up actually demonstrating one of the attacks that's been being talked a lot about right now in the OAuth group demoing that and demoing how to fix it and how to solve how to you know patch it up when you're building your own OAuth implemented and of course we're here to answer your questions as well so if you do have questions feel free to drop them in the chat at any point and we will make sure we get to them may not get to them immediately but we will definitely be keeping an eye on the chat so um going yeah go ahead and whenever you feel like it let us know if you have any questions um so mica buddy want to start with why don't we have a recap of this week in OAuth and then I can transition into my demo yeah so this week in Roth was the last of the scheduled virtual interim meetings and this was actually the session that got tacked on at the end because we ran out of time during one of the other sessions to talk about one of the current proposals so this session was there to to make up for the time we didn't get to talk how Boise ago the topic was topic was deep hop demonstration of proof of possession and that is one of the one of the mechanisms when I proposed mechanisms which is for avoiding the sort of less secure bearer tokens which means that if you know bearer token digit means if you have the token you can use it so if you steal it then the attacker can use it just as well as the legitimate app so the concept of proof of possession means that you attach some other information to that token that requires the client actually sends that other information as well it's usually some sort of signature and there's a couple different ways to do it one of them is called mutual TLS which is not really practical in browsers or doing that in in other kinds of clients where you can't like control the TLS client so or the HTTP client sody pop it is a way to attach a signature that's sent in the HTTP payload itself so that you can actually use it from JavaScript and that is yeah it's it's a proposal it's still being iterated on a bunch this was another meaning to talk about sort of get more feedback on that and the session went well enough I think um I actually I forgot to bring up the minutes I don't know where the minutes of the meeting went but um overall I mean people are pretty like interested in in getting something like this out there but there's still a lot of work to be done on the details of course so what's next for the working group now that you've cycled through these meetings and I attended two of the of the eight what you know ordinarily there'd be as an in-person scheduled meetings I forgot the cadence is it every six months or so that the three times a year three times a year so so are they already planning for a virtue another virtual set or is it unclear right now yeah so the next one's the next one was gonna be in July because this was supposed to happen in April or I think March even so next one was in July and that now is going completely virtual as well um that's that was gonna be in Madrid so unfortunately I don't get to go to Madrid this year that one's totally virtual so it'll be probably similar I don't think they've actually announced what the actual format is so we'll see how that pans out then when after that's in November in Bangkok which again would be super fun awesome to be able to go to but probably chances are it's not gonna happen in person either but no nothing's confirmed with that yet right were there any kind of meta learnings from this first round of doing it virtually I know I think it was two weeks ago we had the discussion about what was working and what wasn't working and maybe changing it up maybe having it be one topic were there any kind of definitive learnings from that yeah there was a big poll put out on the on the list and during the last meeting about how people thought it went and general there's nothing's official yet that the meetings haven't been scheduled to next one but it seems like everybody was pretty much on board with the idea of one topic per session that seemed to work better and trying to cram two topics into this usually didn't work and usually one of them got cut short such as the D pop one that got its own session afterwards right yeah all right cool yeah so other than the meetings the work is now continuing on the list so the discussions are happening there there's still a big discussion around ooofff 2.1 and security best current practice about how and whether and when and under what circumstances pixie is required versus a suggestion and how open any connect sort of wants to play along with that world so that's still an active discussion and I think that was actually kind of what what got us thinking about this particular attack we're gonna we're going to show yeah that's a good tie in so for people that don't know there's been an ongoing and lively conversation about the role of pixie and 2.1 and the the security best current practice that came out last year speaks to the idea of using pixie with the authorization code flow always even for confidential clients and that it was a little surprising to me when I first heard of it I was kind of like why we have a client secret but digging into it it makes a lot of sense and and the conversation that's been going on triggered this idea for a practical application of an an authorization code injection attack that is foiled by pixie so that's the way I learn I like to see things tactically and and to see something that works on a confidential client without pixie and then is foiled when pixie is present I think is pretty compelling so yeah sweet the interesting thing about this is that pixie was originally meant to protect mobile apps which don't get a client secret and it's very clear to demonstrate why you need it in that case because without a client secret there's really no guarantee that the right app is getting the code and you're you can imagine that there are many ways especially in a mobile app environment for an attackers app to steal an authorization code to steal that redirect so a fixie protects against that for sure which is great but what's interesting is that with confidential clients it's also it's also useful and also for different reasons right so with let me share my screen here and so last last week I presented a diagram that looks similar to this if you were here but it was a little bit different last week I was talking about tricking a user into ending up in a logged in state for an attackers account and the utility there is maybe maybe you a user could be tricked into entering a new credit card thinking it was their account but now it's bound to my account as the attacker and now I can go buy a bunch of stuff with that credit card this diagram is very similar except it's going the other way which is probably even more useful from the perspective of an attack and that is the attacker is going to end up in a logged in state as the target user so just to follow this through kind of step by step here we have these four actors in the corner we have the target user on the upper left we have the attacker on the lower right we have Google's authorization server on the upper right we have the legitimate web site on the lower left this is just a confidential client that's doing everything right with OAuth and then in the middle here we have this centralized attack server which kind of makes us all hang together so the key here is that the target user has been tricked into installing a malicious browser extension and while that may be a not insignificant hum you might be surprised how easy it is to get a web extension a browser extension with broad authority listed on the various sites of mozilla add-on and google extension Chrome extension turns out it's not that hard to get browser extensions listed and and browser extensions can have really broad Authority and there is a review process but you take take a look at the permissions that the browser extension is requesting the next time you install one and you may be surprised so that's our starting point the target users been tricked into installing this malicious browser extension so the target user begins this login as normal so they're interacting with a website and what happens is the browser extension intercepts the authorization code that's returned and publishes it to this attack server then on the other side the attacker begins at a login with the same client as normal now that's an important part of the process and we'll see why that is but the attacker has to start a session essentially with the client and then the browser extension retrieves this authorization code that was published by the target user and then it substitutes in that authorization code into their own session and then follows that redirect so what's happening with the legitimate website and Google seems to be completely aboveboard it's a it's a good authorization code we have a good session we have a good state value and so this confidential client will happily go and exchange that authorization code with Google and when it's all said and done the attacker is now going to be logged in as that target user so let's take a look at that action that's literally that's a really sneaky thing here is that normally you would think oh well you can't just steal an authorization code and go use it because you don't have the client secret and that's the reason this attack works is because you're not stealing the authorization code and going and getting an access token you're actually stealing the auth code and giving it to the real client where it that it then goes and gets an access token so you're not you're not stealing access as part of this attack you're just getting logged in as that other user which is right probably worse right so by way of example here on this first screen I have this user called a Rube a Rube dude and here is the browser extension now on the surface this browser extension called pretty cats nothing to see here just shows you random pictures of random gifts of kitty cats we know something else now I also want to take a step back and say I'm using pay per call as an example here if you're not familiar with pay per call it's a it's a place where people that speak at conferences can list their talks and submit those talks to conferences pay per call isn't doing anything wrong here but it turns out it's a good way to show this off using a real world confidential client all right so we have our rube dude and then on this other screen we have our hacks or dude now the hacks are dude also has a browser extension and its job is going to be to pull off that those authorization codes from the attack server that are going to be published by our our rube dude over here so let's just kick off the process as normal I'm going to log in to pay per call I'm going to choose Google and I'm gonna log in as a real user that I have I need to go and get that real users password and by the way I forgot to mention the the consoles that were looking at in both cases these are the consoles of the browser extensions not the normal developer tools console and we can see here that this authorization code was intercepted and from a user experience perspective our hroub user was dumped back to the front door of paper call and they're not authenticated now as a normal user a busy user just going through your day you might say well that's kind of weird I just tried to login what happened and the nice thing about this particular attack from you know the perspective of evildoers is that if I go and try again this time whoops all right I miss something got messed up here this time it should have logged me in interesting yeah there we go so this time it logged me in and and that's because a new authorization code was created and and and so Google recognized that I was authenticated it sent back a new authorization code and the browser extension is set up in a way that it that it that that it'll it'll let that proceed now so from a user except as good luck in this room did the browser extension keeps track of the fact that it already shipped off an off code and then it just stops doing that again so it knows so that it lets the user through yeah that's right so like kind of switches state it recognizes that it's already published a code and so the second time through its gonna let the user in and now if we were to repeat the whole process it would then intercept the next code and then let them in on the next code so you know the you might just think oh there was some weird network hiccup I'm here I'm logged in now because of that error we might have got a little out of out of whack here but let's see what happens so now this code should be published now if I switch over to our hacker I'm gonna log in also now you might say well you already I already have an authorization code what I just construct a redirect URL with that code I know what the redirect URI is I have the code and the reason that we need to start a real interaction here with Google is because of the state parameter so we need to need to establish a session with Google in a normal kind of way but because the Google keeps track of that state parameter and binds it to a session and if we just try to use the code in the with the absence of a session then the then the state wouldn't be right so let me so I'm gonna log in as the hacks or okay it still worked good so what happened was when I when I started the session with Google a redirect with an authorization code came back and the original state and what this browser extension did was just swap out that authorization code with the one that it had from the attack server and so now here I am and and by the way I forgot to mention this is Chrome for our hacker this is Firefox for our rube so I just wanted to show like nothing up my sleeve no previously established sessions or anything like that and now the the hacker is now logged in as the root dude and can now go do whatever change profile go buy some stuff maybe send stuff to a PA box whatever you might do with that and again I want to stress here that in this context paper call isn't doing anything wrong I haven't discovered some you know exploit that's particular to pay per call it's an exploit that is particular to any client that's that's a confidential client that where you've tricked a user into installing this browser extension so let me pause there for a second see if there are any questions and then we can show how pixie defeats this yeah I think that's a pretty powerful demonstration and yeah it's pointing out that there is it turns out a pretty gaping hole in in oweth to itself until you add on a fix for it so the the state parameter was sort of the thing that was supposed to prevent this kind of thing because like you might like you were mentioning the state parameter you you you need a real state parameter from the client the client generates it so you can't just sort of trick it into accepting a state parameter but that's turns out not enough because there is no connection between the state parameter and the authorization code so it's not actually preventing this attack it's preventing you from just dropping into the redirect URL but that's not enough to actually stop this kind of attack yeah and if I were to sum it up in a sense it would be like we're using a valid state parameter we're using a valid code they're just from two different sessions and Roth doesn't know that because there's no connection between them yeah any question showing up there in the queue don't see any questions about this in in the chat okay cool so to reset all of this I'm gonna I'm gonna log out not only from pay per call but also from Google and then we're gonna kind of repeat this with a client that that uses pixie so let me do that in both places I'm gonna log out and one thing to notice here I logged out of pay per call as the root dude when I go to Google as far as Google is concerned I'm logged in as the as the hacker so we we switched for the purposes of pay per call because of that auth code injection but I did actually authenticate as Google with Google as a real account all right so let me just clear out everything here and now one one side note I'll make is that this browser extension pair that I wrote also does the other mode of the attack that I was talking about last week where you trick the the Rube into being logged in as the hacker but it's the fault mode is is what we're demonstrating here which i think is the more interesting one anyway alright so back in so this time we're gonna we're now going to go to this client that Aaron said in about ten minutes which is pretty amazing I must say here this is not very pretty this is a very bare-bones oweth client yes it's not intended to be pretty but it is intended to to demonstrate so from here I can log in with Google and this kicks off the same flow that that we were looking at with pay per call only this time it is using pixie so we're kind of doing the same thing here we still have that same browser extension installed and I'm going to log in as the rube and so oh that's interesting it wasn't doesn't look like it was intercepted hold the fort I'm gonna make this a little easier on myself oh I know why I think I think there were already some codes sitting there from the last run so I am going to first of all and be the codes cue and then I'm just gonna restart these browser extensions to make it a little easier on myself here make sure we're starting with a clean slate there with me one sec while you do that let me to answer this question here yeah sure so the questions registering the redirect URL with Google is not going to help in this case that's correct because this is not actually an attack on Google it's not it's not has nothing to do with with Google's OAuth server and it doesn't even have anything to do with tricking the redirect like a redirect hack because we aren't actually redirecting to the real client so what we're doing here is we're attacking the OAuth client that wasn't protecting itself enough and so that's so the redirect URL does match and we are sending the user both the real user and the attacker to the real redirect URL yeah that's important sky 451 says is the code available on github and no the dakotas not available on github I'm buzz not it is not that much code I will say um but you know obviously don't have a special on a real you know real on a real person this is just for demonstration purposes it is a very good point all right wonder what's going on I have a few things going on all right so let me just get back to where we were here Firefox and and Chrome each do inspecting browser extensions a little differently so I've had a get used to that so I'm going to do the same thing here just get to the point where we can see the console or the extension and not the regular developer console okay back in action okay all right so we're gonna go to a pixie oops our pixie client this is my client that is like it's really just a few lines of code it's just doing the OAuth exchange um so it's just doing it with pixie included all right Owen I'm sure here's our here's our browser extension array alright so similar to what we saw before as an end user I get dumped back into the front door but in the meantime the code has been intercepted and I can't demonstrate this on paper call because the whole point here is that paper call isn't using authorization code with pixee on a confidential client and pretty much nobody that I know of is yet but we want them to be for this very reason are all going to be after the oh right so now this code has been intercepted it's been published to the attack server now I'm going to go over here to the same thing and just like before I'm going to log in with a real account okay now it attempted to do the same thing that it did before it intercepted the code from hacks or it replaced it with the code from our room but it ended up failing here it ended up failing here because of invalid code verifier so in the case of goal that message is coming from Google from the token end point so it sent the stolen authorization code to Google trying to use it to get the access token but because of pixie pixie means the client is also sending the code verifier along with that and there's no way for my browser extension or anything to to know that write the code verifier lives on this applications sent in to and because it's on the server it can't be extracted it can't be intercepted or anything and it's associated with the session of this browser so there's no way to sort of like trick it into using the other session so that is why it solves this attack because their Google is keeping track of the pixie code challenge when it issues that code and it knows what code verifier to expect when that authorization code is used and now we trick the client into sending the wrong authorization code but the client was sending the pixie code verifier for the the other the other authorization flow that was going on right so the the TLDR here is that a confidential client using the authorization code flow is not protected from this authorization code injection attack but a confidential client using the authorization code with pixie flow is protected from this authorization code attack and so this speaks to kind of the conversation that's been going on in the OAuth working group the conversation has been well if I'm using OID C I can just rely on the nonce but yeah so let's talk about that lyric yeah sure so the conversation the conversation here the in the group is whether or not pixie should just become a default part of OAuth always because it clearly protects competence of clients as well as native apps and browser-based apps the the reason that that some people are suggesting that it should not be included as just a default part of OAuth is that open D Connect also technically solves this problem if you do a bunch of things in overly connect so open any connect has this idea of a nonce and the nonce parameter gets included back in the ID token and if the client is checking the nonce then if you tricked into using a different authorization code what you still can do with opening Connect like you can still trick it into using the attackers authorization code and it will go and get an ID token from the attackers user or the other they use other you go to user so you're still rolling the role to like leaking user information for example but when the client receives that ID token and it checks the nonce then it recognizes the nonce doesn't match and then it would sort of abort it would just drop everything on the floor and it wouldn't actually consider you to be logged in so you won't be able to get logged in as the user if the client is checking the nonce in the response however it would still get the ID token and the access token from the attacker it just wouldn't then do anything with it so the open-ended conduct method of protecting it is sort of like after the fact and it's relying on the client to do the work of realizing that it's being tricked so it's up with the client to say oh I recognize that that nonce is wrong from this you know it's not the one that I started with so I'm going to voluntarily drop these tokens on the floor however with OAuth I would argue it's a much stronger protection with pixee rather it's much stronger protection because it's the authorization server that never actually issues the token in the first place so in with pixie you're not relying on the client to voluntarily recognize that it's being attacked and do that properly instead it's the oauth server that is able to prevent it from ever being attacked in the first place so that's the debate it's you know which which of these is is a better one to recommend and the argument on the open UConnect side is that well technically it's safe if you've implemented open you connect properly you are technically safe if your clients are doing this verification and because of that we shouldn't make those implementations change to add pixie because they don't really need to because doesn't really add any additional protection and however like it's you can see how long it just took me just now to explain this and chances are you didn't get it in that first explanation and I'm gonna have to try again to explain it so that actually makes sense of the specific conditions under which open e Connect clients are actually safe by not using pixie and you know I just think it's a lot simpler to say let's just build pixie into OAuth 2.1 so that an OAuth 2 because clearly there's a problem there - and that is just the way it works and if you are doing open to connect as well fine you can also check the nonce parameter if you need to but you know pixie is gonna sort of help the problem earlier in the flow and you know I want to add Erin that in in our research and working on this authorization code flow attack and looking at various clients right now it's the it's the clients responsibility to check that the state parameter matches and Erin and I found more than one case where you know well-respected websites and an OAuth clients we're not checking the state parameter and that's a whole other problem so you know we have examples out in the field real life examples where clients aren't doing what they're supposed to be doing and I would much rather leave it up to the authorization server like we saw Google doing the right thing with the pixie flow and I'm I'm a developer and I have been for a long time I would much rather offload that responsibility to the authorization server and let let them deal with the you know the proper security checking there then make sure that every you know application I write or every library that I'm using is is gonna do the right thing it absolutely should it should be checking the state if it's open ID connect it should be checking the nods but like Aaron said that's kind of after the horses have left the barn already you're saying you know you're trying to pull them back in you know when when in this case tokens have already been issued yeah and I think in general it's it's I'd like I trust Google's OAuth implemented to do the right thing a lot more than I trust every application that uses sign-in with Google and I would much rather put that trust there at the OAuth server to actually protect this the stuff properly because yeah they have a big team you know usually OAuth servers are built by either very large teams very large companies or they're like pretty well respected open-source projects that have gone through a lot of peer review and vetting and there's a lot more implementations of clients and it's a lot easier to get that wrong because there's more people building them so so andreas says pixie does not make opening Connect worse even if the client checks the nonce so why not use it by default that will totally confuse developers and often clients do not check your knots andreas if you do have examples of clients that are not checking the nonce parameter please let me know I would love to see those because that is the exact point we're trying to make here is that trusting client developers is a lot in Brisky or then trusting the OAuth server and the more demonstration of that the better here so yeah like honestly it seems like it's it's better to go with so so I guess the real source of this sort of debate right now is that if you are doing things right with open to connect then you technically are safe and there's you know this set of implementations don't know how many it is but there is a set of them that are properly written and are doing things fine and they don't want to then be considered non-compliant anymore because they don't have pixi at built-in right so that's really the the actual argument here is that existing OAuth or existing opening Connect systems don't want to be sort of told to change and add something in order to become compliant again which is it's an interesting it's an interesting argument but I am curious to hear but also it's and you all hear about whether you think that's a valid argument yeah and I would I would say you know of course I'm on the side here of just makes total sense to me or pixie but also we're I don't see you as taking anything away from existing implementations they are open ID in that compliant they're off 2.0 compliant and they will continue to be as long as they exist if they want to become a a 2.1 compliant I think there's a strong argument to be made well you know introduced pixie yeah well and this this is whatever the outcome of this discussion will also become part of a lot too if you follow the security best current practice and again like you can just decide not to you don't have to do anything right you can just decide to ignore the security best current practice it just means that you're not the most secure and if you've done your own research and decided that you are secure even if you're not following that but that's fine and so yeah that's sort of the weird thing here um there's this question from from the sky so back to the the demonstration of pixie and why and we were trying to to show that how it solves it the question is can you somehow intercept the code verifier within the token request with the browser API and sent it to the attacker server and that's why this so here's this is the sort of crux of the issue here this is a we've demonstrated that confidential clients are need to have need to use pixie otherwise they have this problem confidential clients are where the code is running on the server so so mica is writing code was running on his computer and he's got you know the victim user and the attacker user on his own laptop and then the OAuth client however was actually on my web server so the client is the one that's getting the access open and sort of calling the user logged in that clients on my web server up in the cloud somewhere the the request that my web server makes to Google to get an access token never touches Micah's browser on either the attacker or the victim so there is no way for his browser extension to intercept that request because the request is from my cloud server to Google's cloud server not down to the browser and that's so that's the situation with the confidential client which is you know an app running up on a web server somewhere and that's why it that's why it's this is sort of like a dangerous situation is because normally you think of that as a pretty safe scenario where you're like oh well you know random browser extensions and the attackers can't just like fiddle with the code or like intercept requests but you don't need to because you just need to trick my web server into using a code from from somebody else and then once you got pixie it solves it now the conversation is completely different if we're talking about a browser-based go auth client or a mobile app go auth client and that's a completely different situation and we should not go into it now because it'll just confuse everything but in those cases one there's no client secret and to the OAuth client itself is running in the browser with a JavaScript app and that is a whole different scenario with a whole bunch of different kinds of attacks and different kinds of threats so we're not gonna get into that now because that's not actually the scenario scenario here so yeah single page apps have a whole host of problems and attacks that you can pull off against them and they need to be protected differently and one of the ways to protect them is actually to not do OAuth in the browser and bump it up to a sort of helper server so that you're back in this confidential client situation but yeah we comes we come back oh go ahead no I'm just gonna poke another question but go ahead I'm just gonna add to what you just said that we come back to this a lot and if your mobile app your browser spa app doesn't have a requirement for tokens directly and you already have middleware or it's something that you could bring in then that's still the safest put footing to be on so we might imagine when we when we talk to pay per call and let them know about this particular situation they might say well we're gonna we're gonna add pixie to our client well that has absolutely no impact on anybody using their browser app nothing to change there no you know they don't have to release a new version of their their browser app or anything like that and and so there's a pretty strong argument to be made for having OAuth done in in a confidential client wherever possible now it's not always possible it always does doesn't always make sense for the use case especially on mobile but where you can that the best security putting two beyond because when you when you do need to make a change it's going to be easier to do it in that central location anyway yeah so um Fabrice says is it possible to do this attack with the spring security client um I don't actually know about I don't know much about spring security itself but the attack works against any confidential client that is doing plain o auth without pixie if it's doing open any connect properly this is not a problem if it's using pixie this is not a problem but any OAuth client that is not that is just doing regular play no off by itself is has this problem oh and yeah that's right so errands errands client happens to be PHP but it doesn't matter this would work perfectly well if I whipped up a client it would probably take me more than ten minutes but if I whipped up a client with spring security this attack would work just as well with that so actually andreas chimed in um spring security recently added pixie as an option for spring MVC as a confidence for client to make it more secure for this exact reason because and not not to brag but that was partly our our influence me and Brian dimers and matt regal were kind of on the spring security team to to do that because of the conversations that we have regularly yeah and I should also mention that like you're watching this right now and we're not like this is not news we're not like breaking breaking news here right we're not saying like oh there's just like brand-new problem that we've discovered with OAuth no this is like a well documented problem that is written up in many documents now in the OAuth group itself and it's part of the security Western practice spec this is all like public knowledge everything you know the community understands this problem that's why these discussions are happening so yeah don't take this as like this is something this is like a new thing it's just that my kids happened to actually throw together a actual working demo of it which I hadn't actually seen before you know I just sort of you you you walk through the steps mentally and you can sort of understand that it could be possible then actually seeing it in practice is something very different yeah yeah I think that's a really good point like with this conversation that's been happening in the in the mail thread nobody's saying like this problem doesn't exist the only conversation is about you know how to how to best deal with it and and the concern about you know having to change existing open ID Connect implementations potentially to to be compliant with the security BCP in and OS 2.1 but the nobody saying like oh this isn't an issue yeah but yeah that's so honestly the more feedback that the group gets from people who are actually building this stuff the better so if you do have an opinion one way or the other on whether or not pics you should be required as I off 2.1 and according to the security best current practice or if you think that it's fine to sort of allow this exception for clients that are using open any connect properly and i've gone through some sort of verification of that your opinion does actually count and that does matter a lot right now let me actually pull up a link so I can show you where to go to actually try me on this discussion I should make this a little bit easier to navigate to but the OAuth 2 dot Lois net that that is the website and if you go to this about page there's just community tab and that's where you can find the link to the mailing list so join the mailing list here this is the archives and this will show you the discussions that are happening right now which is for example that's an email I sent yesterday um on this exact thread so this is happening right now and your opinion does actually matter so feel free to just chime in it doesn't take much time to send an email there and there's no like signup or a fee or anything like it's just you know go ahead and just join um here's a question related will this attack be possible using OAuth to jar that is a good question so there's a couple of additional extensions going on in OS right now to make sort of make everything more secure and we've got they all in an AR jar par and rar jar is a John secured authorization response if I remember the acronym correctly um would that help here would that help here I believe I have to actually look at the details because um it might help because the idea with the the problem with the authorization code is that the client can't tell where it came from not Java in this context thanks Mecca the problem with the plain authorization codes the client can't tell where it came from and it just sort of sends it blindly um as soon as you turned the response from just a plain Toth code into a JSON web token then there is a lot more context in there available to for the client to know whether like it initiated that request and things like so it probably does solve it cuz I'm pretty sure they wrote they wrote it that way but it would need to basically like include the the the state value or know something yeah the state value would do it right if the state value was included in that JSON web token that would solve it because then you couldn't then swap it out with with a different one because then the state value in the actual URL in the state in the JSON web token wouldn't match um okay similar to what nonce does with oh I II see very yeah it's very similar to nonce in that point however that is again putting the burden on the client to protect it and not then using that that response so even if so if yeah it solves it would solve it the same way that nonce solves it which is putting the burden on the client to solve it which is still in my opinion not the ideal place to put that burden as a side note some of these namings are a little unfortunate jar and rar both already have meanings in different context so every time I see jar in the context of oh awesome like if somebody talking about a specific Java thing and then I remember it's not Java yeah yeah um so yeah that's that's the sort of hot topics you know auth right now um any other questions on that otherwise we can go through a couple of the questions that you dropped in the chat earlier um actually yeah why we talked about the this this question about passwords so I here's here's a 3-part so building an online banking middleware server and a spa and mobile client app so we're not in the confidential client world which means all the attacks we talked about don't apply it is instead that there's a whole different set of attacks we are implementing identity on Oh Ethel opening okay Connect great since this is considered a first party app why should we not use the password grant our OPC resource owner password credentials or password grant or however you want to say it has like five name's why should we not use passwords instead use pixie so let's talk about that for a minute this is a really this is a really tough one so break down the question first so the first party is the important part here so the idea with first party means that the app that you're building is branded the same as the API it's accessing so examples of first party it's gonna be like you download a Twitter app you log into Twitter you download Google Calendar you log into your Google account you download YouTube you log into your YouTube account which happens to be Google but that's a different story um third-party apps is what sort of Oahu was originally targeted for which would be like you download you go to you go to the buffer website to schedule a tweet for later it then asks you login with Twitter to get access to your Twitter account two different companies two different brands so in a first party scenario you don't really have the sort of like trust issues right where where the user it doesn't have doesn't have to be sort of skeptical of the of the app whereas if you get dumped on a page and it says like hey this app is trying to post your Twitter account you are probably going to think twice about just clicking through because you want to make sure that you trust that up to have access to your Twitter data and with the first party up there isn't that issue like you download the bank's app from the App Store and you're like cool I mean as long as you verify that it was the real banks app and not like a fake app you're fine and there's no worry about giving that app power over your account right the problem with the password grant is that and this is true for this is truth password grant for any type of client whether that's mobile apps single page apps confidential clients anything problem with a password grant is the password does in fact you do in fact give your password to the application so first that's like never a good idea for third party clients but for first party clients you're not breaking the users trust by doing that so okay however you have a bunch of other problems so one you're again relying on the client to do things properly relying on the client to never accidentally log that to a file somewhere you're counting on the client to not store it you're counting on the client to use it properly and again if you've you know audited all your code that's fine and you trust that sure so then the next problems are well you're a bank so you probably want some sort of multi-factor authentication because of course you do there is no way to insert that into the password grant the password grant in OAuth is just take the users password get back an access token if you want to start doing two-factor off you're on your own and you have to just make it up and figure out how to do it which is not a good place to be and the app developer has to actually build it it's built it into that app itself so the advantage of using OAuth and in this case would be the authorization code flow with pixee because that's sort of the default now the advantage there is that you move all of that work up to the OAuth server and none of your apps have to worry about it so if you've got the web server the web app where people are going in a desktop browser and you've got a mobile app logging into it in both cases the apps will just send the user up to the OAuth server which is then responsible for collecting their password dealing with multi-factor off and doing all that work on the server so the apps don't even see the user until they're done and they're there they've got the tokens so it's a lot safer that way there's less chance there's less places that passwords are flying around so there's less places that attackers can start stealing passwords out of it's putting it's consolidating and where all of that logic happens and where all the the auditing has to be done so you know you only have to worry about protecting your OAuth server in that case and not also making sure that an update to the apt in cause passwords to somehow leak out of it my favorite example this is Google because they are a obviously very large company they also have hundreds if not thousands of apps that access first party apps that access Google accounts right you've got YouTube you've got Google com you've got Gmail Google Calendar whatever their chat app of the week as it's changing again right and all of those are built by completely different teams in Google but they're all first party apps they're all googles apps but what they've done is they've actually said no app developers ever can can touch passwords at all under no circumstances are we ever going to let our own apps ask the user for their password instead we're always going to use OAuth so every app you download when you log in you'll see the OAuth pop up screen that's doing the auth code flow with fixie and it just simplifies so much because now they don't have to go around to all their app development teams talking about like to make sure that they're handling passwords properly they just have to protect everything on the OAuth server which is another reason that pixie is a good idea to use because that you know prevents that that attack on the server side on the auth server side and now they can be a lot more sure that all of their implementations are actually safe so that's the that's the real that's the story there um and this is another you know topic of discussion right now although the the debates pretty much settled at this point the security best current practice is also saying don't use the password flow anymore it's being taken out of OAuth so if you read just a auth to dotto core you'll still see it but then if you keep reading all the specs in order you'll get to the security BCP and it says don't use the password grant so that's one of the things that one is doing which is never not putting into there to begin with because that's it just shouldn't be so there's a question here from Andreas it's a good question I why why was the pastor grant added to OAuth when I auth was never targeted for first party apps it the password grants often you love this answer yeah the password grants often used by developers just because the redirect flows are more complex and this is let me just yeah it's a fantastic question because if of' was originally the conversation right yeah you have a conversation yeah tell the people this this is great let me actually pull up I have I can go find because it's on the mailing list so we were having this conversation about about 2.1 and and the password grant and here's this whole discussion about password grant one of these I one of these from dick actually explained it and it may be wow it may have been so long ago that that I might be able to find it but I just want to pull out this quote because it's it was a very excellent very excellent summary of the situation and it answered this exactly so dick Hart is one of the original authors of the OAuth 2 spec he's actually the only one left on the document because everybody else dropped their names from it but he explained on this mailing list not gonna find it I scrolled past it um he explained the reason that it's in there at all and the reason is because if you think about like you have to go back in time you have to go back in time to 2008 era when api's were just being built and a very very often people were using HTTP basic auth for their API and the way it would work is the application would get the user to enter the password the outputs store the password and then include it in the API request so it would actually be you know HTTP basic auth just sent up to the API every request so they have had to store it in order to do that which is obviously bad which we understand now which is why we have these token based methods which sort of avoid the need to store passwords but that's just how things worked both came along and the idea was that they wanted to give applications a way to upgrade to OAuth seamlessly so the theory was instead of asking the user to log in again since the app the user was already logged into an app when the app would launch this update to to use OAuth the application could use the password grant to convert the password into an access token so that they didn't have to bother the user because these are already logged in why do they want to log in again that was the reason so it was there as a migration strategy to upgrade to OAuth it's just that it kind of got written into the spec as a top-level option so later developers looking at it were like oh well while I just do this because it's simpler but that was never really the intent it was meant as upgrade for legacy apps so that's why it's not being included as my recommended it hasn't been recommended for a long time and that's why it's not gonna be part of a wall 2.1 so hopefully that answers the question there is if I could I was just gonna say to summarize one of the original authors basically said it was never intended to be used the way it's been used said is that an accurate summary of the conversation yep and I wish I could have found that email but it is on the mailing list so you can go find it um yeah so this has been fun we're at the top of the hour um thanks everybody for joining I guess we will leave it at that um come back next week do take a look at the mailing list join join the mailing list you can find it from net and I yeah I hope to see you all again next week and we will be sure to continue these conversations thanks everybody have a good one everybody

Channel: OktaDev

Views: 592

Rating: 4.75 out of 5

Keywords: oauth, openid, happyhour

Id: moQidjdV5cw

Length: 60min 0sec (3600 seconds)

Published: Fri May 22 2020