OAuth Happy Hour

welcome to both happy hour with Erin and Micah we are looking forward to chatting today with with you all so please say something in the chat let us know where you're drawing running from and say hi tell us where where where you're from and feel free to drop questions in the chat too and that's what we'll be talking about today we've got a handful of other topics to cover as well all things off and open e connect so we should have a good time hopefully we are where you want to start where you wanna start Micah when we talk about the meeting earlier this week my first one that I attended yes the IETF ongoing series of meetings that were postponed when the in-person event was cancelled it's now turned into a series of a series of meetings so that was on Monday and the topics that week were thoughts 2.1 and what was the other one jason web token introspection so that was that took up a whole hour there was lots to talk about there would you like me to describe what these two things are and then we can maybe talk about yeah yeah that'd be a good way to start I think so well three point one is a draft that I'm working all along with a couple others and the idea with that is to give people a new starting point for getting into OAuth so oaah 2.0 was made a long time ago and it's got a lot of baggage I guess of like it was made for it was made in an environment where where things work very differently so you know mobile apps were barely around at that time and a lot of things that have changed over time so in the last 10 years so auth has been extended improved made more secure and all of that has led to a lot of extensions so now a handful of extensions around doing things better for mobile apps doing things better in different situations and security requirements that make things more secure and if you look at if you just start reading I should have brought this book with me but if you just start reading the drafts at at the beginning and play them all forward you end up with something that looks very different from the course back and so the idea with OAuth 2.1 is to do that and then capture that back into the current snapshot of well this is now what we mean but when we say OAuth we don't actually mean all these things that we've sort of taken out of the spec over the years by writing extensions so that's the idea with olaf 2.1 and the meeting today was about some of the details or not today monday was about some of the details on how did how that should work what that should look like and getting some of the the details written down and documented so that was the first part of the meeting the second part of the meeting was all about a different draft which is called JSON web token response for OAuth token introspection that's a long list of words so let's break that down in OAuth there is a the idea of token introspection right so you would use that for a resource server wanting to know about an access token whether an access token is valid right the response from that is a JSON document with the details about the token so you've got things like the the user ID the the expiration time stamps and things like that that's all fine this is an extension that returns that response as a JSON web token so why might you want to do that any ideas cuz my first thought was well that seems redundant right but turns out the reason is because if you the you so this is MIT this request made by the API the resource server you're asking the authorization server is this token valid and then you're gonna act all that information and you're gonna process a request like return data you the idea with making this a JSON web token is so that as the API you can actually then later prove that the authorization server did in fact say the stoughton was valid and that you didn't misinterpret the response so that way the authorization server can't be like oh i never said this token was valid so your fault this data leaked right right and is is this is the idea of this is the JWT signed by the authorization server and verified by the resource server exactly or is it the other way around yeah no so the the authorization server creates the JWT signs it hands over to the resource server and it can then validate that signature so that I can prove that the authorization server did in fact return that response so right and I remember from the meeting that it's also what's one of the things I found interesting about it is that the the introspection data is not at the top level of the claims of the JWT it's embedded in a claim specifically for the introspection data yeah so I just realized I should share my screen so we can actually look at this because why not so let me do this screen share oh yeah cool so this is the draft and the idea with so so we look at latest version yeah so in that unit right now do I have to click play or something I see like a little play icon oh there it is okay I just had to click the I don't know if anybody else would have this same experience but I had to click like a little play icon in order to see that funny is on your side cuz we're just pushing a video out to YouTube here so the response you're talking about is I'll see if there's an example in here so this would be the response you get from introspecting the token right which is a complete JSON web token which includes the header as well as this and this is where the the response is a container JSON web token and then the token data itself is then inside that grate and that was actually a significant change from a previous version which was a lot of the discussion about this which was well what is this process then because this is actually pretty far along in the process so the question was then what is the process for dealing with this significant document change so layton that in the ITF process so that was I think that was kind of interesting go ahead I was just gonna say it was the motivation for having it embedded that way to be able to separate the the actual introspection response versus data metadata associated with the JWT itself yeah exactly because you have for example the time stamps wooden wouldn't make sense if like the expiration date of the token were in the expiration date of the JSON web token being returned it's kind of like mixing up that data so that doesn't really make sense so the JSON web token that's being returned is really just a container for the data that is big trying to be protected so it made sense to nest it then in order to be able to not confuse the the the properties of both of the both the JSON web tokens right because it's actually possible that your access tokens aren't even the JSON web token right because you can send a barrier of random string token to the introspection endpoint it'll return properties that look like what you would put in a JSON web token because that's what the introspection response defines but the token itself doesn't have to be a JSON web token sure so that would also that's also that confusion of well where's the token data versus where is this JSON web token container live got it so overall everybody was pretty much a fan of this change and in support of it which is good so now it's just a question of how do we make it happen and still within the normal normal IETF process yeah so that was those are the two main topics for for the meeting there's still a few more interim eating's coming up because because the again we had crammed a lot of topics into the week that was gonna be in person and now we're splitting out into a bunch of short one-hour meetings so oh we have a couple questions in chat um will this be available offline yeah I think so I think we'll leave this up on our YouTube so you can watch it again later um here's another question can you clarify why you wind up using JSON web token I think lots of people including myself have seen Randall's talk against Jason web tokens yeah Randall Randall does a good job of making a case against Jason web tokens for sure they're really quick it is important to point out that rant the core of Randall's talk is against using J WTS as for session identifiers as session tokens it ends up being broadened out to be like J WTS are bad for everything JW Gees definitely have some you know problems associated with them empirically but they're especially bad using to be used for for session identifiers which is like the core of Randall's talk but they do have their place yeah so the I guess there's a couple of like concrete criticisms of JSON web token jacob jasen web tokens and one of them has been pretty much solved at this point which is that that the header describes the signing algorithm so the there was a hack in 2015 which is what I do a talk on all the time which was that sometimes you could just change the header information and say that your signing algorithm was none and then make like modify a token and send it to any sent it to an API and it would then not validate the signature right which is bad but the fix is just don't accept that signature only accepted signature methods that you know either you understand and that's what like mostly a solved problem at this point I agree that it was maybe not the best design decision of in JSON web tokens at the beginning we shouldn't have probably given people that you know that way to get things wrong but it's not the end of the world right so yeah the other problems are more about how you then use them so this is actually what we'd both talked a lot about in the workshops that we do which is there are a lot of trade-offs when you use a JSON web token as an access token however those do not those are not unique to JSON web tokens those are about any self-contained token right they it's essentially a cache of it's a snapshot in time at the time the tokens issued about the system state it's a cache of the user ID it's a cache of the the timestamp of the scope or whatever right roles that are in there and that can go out of date and if it goes out of date then you know you might be acting on old information and that's not a problem that's unique to Jayson web token it's a problem with any self-contained token so yeah is that I guess help answer that any other thoughts on that Micah well just as a you know the business with Alden on and some of the other issues with JWT we kind of internally we talked about GWT the good parts it's a little bit like JavaScript there are some you know kind of dark caves with trolls in them in JavaScript if you're not careful it's just part of the language but if you avoid those parts then you get some really good stuff out of JavaScript it's kind of similar with JWT as long as you're working with a library that will just you know reject out none or you know you're ensuring that you're not going down those you know dark caves and JWT it has its its utility and you know when you're using like public key encryption and you're validating the signature all of that is good crypto you know the what we're starting to look at which is going to be you know probably way down the road for anything like the OAuth standards is passado where the idea is that you know the developer is saved from himself it's kind of like typescript in the world of javascript like you can't make certain mistakes because it's just not part of the language or in the case of Macedo it's just not part of the standard where you could fall have those same kind of pitfalls but we're probably a ways off from from that being incorporated into any standards yeah definitely that's I mean this kind of stuff moves tends to move very slowly in the standards world much less than also making it into products but yeah so there was oh my gosh where my screen go yeah so Lee says what are some alternatives to JSON web tokens so passado is one of them that's pas été oh is that right yeah platform agnostic security Randall has also a good talk on those it's essentially a alternative signing format and package around a self-contained token and yeah you can you can make the argument that there's you know benefits to to that method of doing it however you are not going to solve the trade-offs you get by using those as access tokens right so you still have all the problems of treating those as access tokens in that you're you're you're still acting on a cache of that data and that's not you know that that's not going away yeah so if you could wave a magic wand and have a service that use beset oh today you'd still have all the same issues that you have when you're verifying locally you know maybe the the system state changed the account was locked but your software wouldn't know that because it's only validating locally so you still have those same those same kinds of issues that you have with opaque versus you know encoded types of tokens yeah exactly so all right there oh go ahead yeah isn't there also an issue with JSON web token invalidation or do we typically just bring the expiration time way down yeah so that's kind of what we're hinting out here which is that that is the problem with any sort of self-contained token this is not unique to JSON web token so the idea is that the the tokens issued and it has a timestamp of when it expires baked into the token and then if someone's validating that locally they look at just the timestamp there's no way to then invalidate that because if they're only looking at the token string itself then it's gonna look valid until the timestamp passes so there's no way to revoke these regardless of what format you're using JSON web token or anything if you want to be able to revoke the tokens then you need to go look up somewhere else the information about the revocation list so that's what token introspection is for or you can go back and ask the authorization server touken still valid right it's kind of part of a larger class of problem with with cashing in general like any any cash system that you deal with you have these problems of stale cashes and you know system state changes but the cash represents something at a prior state you know it's it's kind of that same problem domain and you just have to strike a balance between the efficiency of your application and you know the kind of live feedback of the system state yep it's a lot of trade-offs really okay what oh another question in the authorization flow plus pixie why is the and this was corrected interception attack is considered what will happen when a malicious app that takes the authorization code they don't have client ID and secret how can they exchange it for a token so the there's two parts to this I guess because one in one case on one hand pixie is can be used with confidential clients with a client secret the in that case yeah if someone steals the authorization code they're not gonna be able to use it right because they don't want the secret in that case pixie is actually protecting against something different which is having an attacker swap in an authorization code to the real client but from somebody else so if you imagine you have a legitimate client running on a web server with the client secret the attacker gets the user to go log in and get an authorization code and then somehow steals the code from the user before the user is redirected back to the app and the attacker can take that code drop it into the app itself and then the app does have a client secret to use to go get the token right so what pixie does is it prevents that from happening because that the app has to actually maintain a session specific secret that pixie secret at you know I'm both the the original machine that started the flow and also then the attacker who would have tried to start the flow so then the pixie challenge would be wrong if the authorization could have swapped in that makes sense it's a bit of a tricky one but that's what it's that's what it's solving the you know the the traditional use of pixie I mean I think the answer to this question when you're using pixie like in a spa app is that there is no fixed client secret and if we just as good security professionals just assume that the authorization code always is intercepted where it gets foiled is that the malicious app or the malicious browser extension doesn't have the the code verifier that was generated at the beginning which is like the stand-in for the client secret you know that that dynamic value that gets generated every time as part of the pixie flow so where the attacker would get foiled in that case is that they have no way of knowing what that internal client code verifier and the derived code challenge would be yeah exactly so the I guess that's like the main use of pixie especially cuz it was made for mobile apps really at the beginning is protecting that case when there isn't a secret but there are benefits to using it even if there is a secret because it's just protecting a bunch of other different kinds of attacks as well I've kind of thought of it as like CSRF protection for OAuth is that is that a reasonable way of thinking it is yeah it absolutely is and that's actually one of the reasons that in the security best current practice the one of the things that says is that pixie is used for CSRF protection that also means that pixie then or that the state parameter does not need to be used for CSRF protection because originally the state state value protects against that so if you're doing pixie then you don't need the state parameter for CSRF protection which that means you can use the state parameter for whatever else you want yeah like just like application state or something yeah exactly of like which page do they come from originally before they're trying to login yeah whatever you want to do yeah is there something in the spec that that speaks to that where it would be a valid use like if you're using pixie in a confidential client then it's okay to use the state parameter for something else entirely or is it yeah just implied no it actually is literally written like that let me see if I can find that so on Oh off to the security best current practice make us bigger as you can see it this is the security best current practice spec we are on draft 15 right now published earlier this month somewhere in here it says these things are fun to read yeah I think it's here so this is mainly about that authorization code replay which is it attack I describe the beginning the nope okay no I don't see it I made search CSRF protecting redirect baseflows 2.1 clients must prevent CSRF in this context Bulova clients that have ensured the authorization server supports pixie may rely on the CSRF protection provided by pixie otherwise one time you see a surf token secured in the state parameter must be used and then somewhere later in here it says I go back up to the top search for state it says oh that last one where did it go back up no now I'm not finding it yes where it had that in there yeah I'm sure it's in there somewhere it's just useful because I think you know I know of projects and other developers that have wanted to use the state for application state and we always had to you know give them the bad news that that was exposing them to replay attacks because if the state is a fixed value or if the application will accept the state as a fixed value then you can then you lose that CSRF protection but now though it was me there is still one piece to that that's dangerous though and it's actually described in here mm-hmm if state is used for carrying applications state and if the integrity of the contents are concern then the clients have to protect State against tampering so you can imagine if you've got applications state in there that actually does is actually significant in terms of like carrying role information or anything like that you wanna make sure that somebody can't go and modify that state value and start a flow that would result in doing something else so if that is a concern if you are putting stuff in there that's like sensitive application state then you might you want to use a JSON web token as the state parameter but for simpler things like well we were coming from the dashboard so let's make sure we get redirected back to the dashboard after they log in state can just be the string dashboard right that would be fine because that's not sensitive information and it doesn't matter if somebody changes it because they would just end up somewhere else right but again a caveat on that is don't use full URLs in the state parameter because then you're building yourselves an open redirector right so you don't want to let people be able to craft a value of their own choosing and then get somebody else's browser to redirect the other location that's an open redirector yep GWT comes back into the picture again we can't get away from it away from it it's not slavery support it's fine whatever yeah okay here's another question from the chat from Demetri when implementing an OAuth 2 with authorization code pixee public lions react is the session stores right place to store the code verifier during the flow session storage meaning i'm assuming the browsers the browser api is called session storage so yeah I guess the anywhere that you can store that temporarily on the client is fine it's used it's it's only valid for such a short amount of time that like it there's not really a concern about long-term storage that you would have with for example like storing access tokens or especially refresh tokens so that's totally fine you have any other thoughts um that might go you've done worth react than I have yeah well the the code if we're talking about the authorization code there you don't need to store that anywhere because that's used once and never seen again the code verifier you're gonna need it you know you you created the beginning of the flow and you'll need again after a redirect so it's got to be stored somewhere but like Aaron saying it's so short live that you know it's it's pretty it's reasonably safe to to park it in local storage even if you live even if you were to leave it there if you were to forget to clear it out it can't be used again so it's pretty low risk yep yep here's another question is it safe for the authorization server to return the same JSON web token for a client in the client credentials flow use case multiple instances of a client deployed in a cloud environment so typically no typically you're gonna want to return you aren't gonna want to generate new JSON web tokens for each we're quest for an access token and that especially in the case of this kind of environment where you have multiple instances of a client because that lets you disable them independently so if you need to disable an access token for some reason like if one of the client machines was found that it was spewing log data some into some folder somewhere you won't be able to disable those access tokens not and not have it affect every every other instances access tokens right so the JSON web token that's generated it's gonna have a timestamp first of all of like when it was issued so that should just be different every time it one is issued right because you want to make sure you know when this dozen was created it'll probably also expire you probably do want them to expire also and again that means it's easier to just give a new token to each client and then if you are trying to be able to track these access tokens to be able to disable them you're gonna have a property in there called jti which is the identifier for that particular token so that you can then disable I have took that one token when you need to yeah I was also gonna say speaking of the jti and especially in you know like a high availability or cloud environment where you have a load balancer or something like that for debugging purposes you'll you'll be better off because you you'll be able to tie that jti to a specific instance that you know something goes wrong or if you need to shut it down or take it out of service you'll be able to tie it back more easily yep that's not a good use for sure cool and it's also something that's kind of natural to JWT like you have an issue that time and if you're dealing you know if you're load-balancing around multiple clients those those times are going to be slightly different for four different tokens or data beauties that are coming to them so it just kind of naturally fits with with the good parts of JWT like you want to know that this is a different one than than some other one yeah for sure well swells is going on in the world of OAuth what's the other topic on Monday's call you did a you did a review of the state of both 2.1 right aside from the JWT business yeah so 2.1 we talked about a couple of particular issues in that and the next step on that is going to be putting on the email to the list asking if people agree to be adopted because right now it's actually not an official official document it's just an individual contributors document which is myself and a few others has no official standing at all right now so the next step is to have that be adopted by the group which then gives it an official standing in the group and becomes a group working item that people have agreed to spend time on I'm trying to member what the particular issues were that we talked about during that meeting and I think I can't find a link to my slides but yeah so there was it was just a couple of a couple of things it was mostly just saying let's let's catch up and talk about like what what's the next step on on this draft and are people actually interested in moving this forward and there was a good feedback yep you were on the call did you or anything interesting yeah well you know it was the first call that I've attended so it was it was it was a good experience for me to just kind of get into the flow of how the calls work and you know there's even like a little lingo in the chat that you know like when somebody has a question you put in a Q plus I didn't know that before but now I do so you know it's typical of any organization you get involved where they they all have their own little ways of doing things that you have to get acclimated to so but it was you know it was it was good to see it was very respectful and and I like the the way that you know there's like an agenda and it keeps getting moved forward and it was very nicely time box which I thought I thought worked well you know was getting toward the end of the meeting and and whoever I forget who was leading it but it was kind of like alright we're gonna need to cut the mic on this topic because you know we only have a few minutes left we got to keep it moving and and especially with the frequency with which are having the meetings now I think it makes I think it makes sense to do it that way gives you a chance to digest everything that was talked about you can come back next week you know fresh and and I thought it move things along pretty pretty well I'm getting acclimated myself to the whole you know mailing list system which it's got to be you know ten plus years since I've used a mailing list of this type and I sent I sent my first thing off to the mailing list this week and I just realized you know before our happy hour today like I didn't see a response I don't know if it made it there it might just be my filter settings on my on my mail because at first it was like a fire hose and then I turned it to the daily digest but then I wasn't getting enough so you know there's a little tweaking of all that to do but you know you've been very vocal about like inviting people to getting involved in it and it can be a little daunting at first because you and other people have been involved in the process for so long but I you know for anybody that's connected I just want to let you know like if you just kind of jump in it does seem a little daunting at first but you get acclimated pretty quickly and and it's very open people are very willing to take input and and you know participation is encouraged yeah it's definitely a lot of a lot of inner knowledge about how the group works and lingo and weird mechanics wait till you come to the one of the in-person meetings and they do the voting by humming because that's an experience let me tell you how nice also does not work online absolutely not yeah I can do that too yeah but but yeah the other part of this is that like a lot of people are working a lot of does a lot people in the group and a lot people are working on it either because they personally want to or because it's part of their job and everybody's coming at it from different backgrounds and different like what they want different things of what they want out of it so it's not like everybody is paying attention to every thread all the time because there's just too much for that instead people like tend to focus on the particular aspects that they're interested in so and then everybody of course is like working on this whenever it's you know whenever their job lets them whenever they can fit it in between other projects or if it is their full-time thing it's different for everybody so the speed at which the discussions move varies wildly based on what the topic is and since you made a comment on my draft I owe you a response to that and I have not had time to do that yet so that's on me yeah no worries you know what what's that yeah it's definitely it's definitely a lot yeah what what I like is is you know we we have a slide that we use in our developer workshops where it shows like a maze of different rfcs that you go down a rabbit hole pretty quickly when you start to get into OAuth so what I'm what I'm excited about for OAuth 2.1 is kind of bringing all that under one umbrella and and consolidating it all like a one-stop shop for like this is ooofff 2.1 this is the specification and you know there's always to be callouts to other RFC's because you know there's JWT and other things that are involved but like the core of it is gonna be in one place whereas right now in about you know a minute digging through the the original one you start branching off to the extensions and various things that are just in popular use now because it's you know eight years later or whatever from from where we started or longer yep the I have the the maze graphic I just like this picture you know this this would be a great quiz errand for you know part of the reworking that we're doing with the developer workshop like who can name who can who can attach a label to each of those RFC numbers off the top of it yeah oh that's also something that's super funny to me is in the in person discussions once you start having talks with people about these like at the ITF meetings people will actually start referring to drafts by their number as a shorthand and like a couple of them I'm totally familiar with like sixty seven fifty is Barry took in 67 49 is OAuth 2.0 because that's where everything starts and yeah after that I started to get lost pretty quick on remembering the numbers but some people just throw out the numbers as if like you're supposed to remember the numbers for all of these right and forgetting that that's it's it takes a lot of experience to be able to do that and actually have some context for those yeah yeah I had that as an interview question ones in the context of HTTP like how many how many HTTP response codes did I know what they what they meant there wasn't like like this is gonna make or break you getting your job it was supposed to be like an icebreaker like a fun thing and apparently I I came in second place on their all-time leaderboard but I definitely could not do the same thing for RFC's that's great oh all RFC's that would be a challenge yeah a piece of a challenge let me take a look at chat again I think we got some more questions here yeah so from Dimitri how would you manage a token refresh with the public client JavaScript app if the Refresh token should not be stored on the client some approach that more user friendly do not make use of login every hour or less yeah this is a question that we get a lot because this is definitely a concern you've won about on security with usability right so the usability is you don't want people to have to login every hour or day or whatever your token lifetime is and on the flipside you want access tokens that last a short amount of time you don't want to issue forever access tokens so what's the balance there well refresh tokens were created for exactly that purpose refresh tokens were meant to be the way to get short access tokens but have the not happens at have not have the user log in every time there's definitely some concerns with storing refresh tokens in JavaScript Maps but before I get to that no I do want to talk about those so the concerns around storing them are that in a public line when there's no client secret the Refresh token becomes like the ultimate key to the account right so because as soon as somebody steals the Refresh token they can just keep getting new access tokens then and that's the main concern so in a confidential client there's a secret a stolen refresh token doesn't really matter because they can't do anything with it in a public line that could then use it for anything and this is again one of the things that that is being talked about in the security best current practice as well as OAuth 2.1 and one of the solutions is that you do use refresh tokens in single page apps so that you can use short token lifetimes but the Refresh tokens become one-time use so by doing that as soon as the app uses the Refresh token it doesn't matter if somebody steals it because it was used up and they get a new refresh token back in that response right and that gives you the benefits of refresh tokens and you then don't have the risks of of the Solon refresh tokens the wrists will the risk moves it becomes if someone can steal the refresh token out of the app and the app doesn't know about it then if both the attacker and the write the real app try to use it at the same time or alternating the authorization server can tell that something's wrong and just shut down the whole thing right so it can prevent that attack which is great [Music] so you have anything else on that mica because there's a couple of other answers to this too well you know I do want to speak a little bit to the octa specific case about how it addresses this currently because this is something you can take advantage of today but it is specific to octa and kind of outside of Olaf it's a little bit of a hybrid so I can I can wait on that if there's more to say about you know well what is Civic Toa the the other the other thing I wanted to mention was that if you if you can't rotate your refresh tokens every time which I'm hearing some people are saying that that is getting to be a challenge in some cases a challenge because it means that applications have to make sure that they're always parallelizing or not parallelizing requests and are always making these a sequential requests so if you can't rotate them then you probably shouldn't issue them to JavaScript apps so instead you can still avoid the user logging in but you would still have them do a redirect so just because they are redirected to the OAuth server they don't actually have to be prompted for their password right they can actually do a redirect be already logged in and then come and get bounced back and you see this all the time with apps in the real world like if you are on github you're logged into github and then you go to like Travis CI dot org and try to log in via github you're not gonna see a login prompt on github you're gonna basically end up back at Travis CI almost instantly because the redirect happens so quick so that's the same thing with your single page apps we're like yeah you do get redirected out and then you come back which reloads the app but then it's done the pixie flow by that point and it's got the access token and the new access token and like sure there's a usability concern there of well you have to go out and do a redirect and back so yeah make sure your app loads quickly don't have don't deliver people an eight megabyte single page job that's gonna take five seconds to boot up because that's ridiculous like stop doing that right make your app boot up quickly make it very responsive because like if you do a web server based app and just write server-side code it turns out those things are snappy snappy as heck right like those things load instantly and you can even be doing requests in the background on them to be getting the new access token whenever I do the demo about of doing of writing an OAuth client from scratch I'm writing it in in PHP because it's just like on my laptop and it's easy to do and there's no frameworks there's nothing to install and I have to always explain okay when I click this link you're not gonna see anything happen I'm just gonna get bounced right back to this page and you're gonna see the text on the page and I've explained that it is actually doing a redirect out to octa and back and we're getting the authorization code from octave it just happened so quick that nobody can see it I think that's like that's a good selling point there like it's not the redirect that's slow it's your stupid a megabyte app that's slow so fix that right anyway do you have something about octave specific yeah well just before that you know you just reminded me because it comes up a lot and and it at least in my experience working with other developers it's pretty rare these days that you have a pure spa app with no backing services at all now you do have a pure spot app then you have to deal with this issue but if you have a backing service a php.net Java nodejs some back-end service then the best security footing and the best user experience footing is to have all of the Oh stop happening in that middleware because then it can keep the tokens it can safely keep a client secret you can do regular old refresh tokens and then your react app your angular app is just using its native session mechanism to keep things in sync with the the middleware that you have and so the spa app never needs to have a token you get all the benefits of refresh tokens you know the benefit of balancing security and user experience so that's kind of like the best of all worlds if you can if you can do that if you are in a situation where it's a pure spa app the way the way that optimum it agates this issue and you may or may not have noticed this if you've used any of our JavaScript clients whether it's react view angular or just the raw off 2's because octave sets its session cookie when you go through any of the off flows when that access token expires the author yes library just leverages that session cookie this has nothing to do with OAuth but it leverages that session cookie it makes a connection to octa and optin just returns a new access token so it's kind of like the idea of a refresh token without it being a formal oo auth refresh token but it is specific to octa it's outside of OAuth but it's a way it's a way that a pure spa app that's using octa can have that balance you can still have very short-lived access tokens and the app can go and get new access tokens when they expire and it's completely transparent to the user but it's happening because of that octa session ID so it's almost like the session ID is the Refresh token right yeah I mean that's the way it's being used it just isn't oh of yeah yeah it's it's not in it's not described you know off but it seems like the same mechanism except that of course because it's a cookie the JavaScript doesn't actually need to get ahold of it because that's what HTTP only wishes the benefit and it is a chimp you owe me so you get a reasonable level of security and still have the ability to get fresh access tokens when they expire and you get all the other benefits of it having to hit octa in order for that to happen so if the user account has been locked or something else has happened in the interim then they won't get back the new access token and the the spy app will deal with that error in whatever way it's set up to do so but you know you get the benefit of the short-lived access token and still not having a refresh token that could possibly be leaked or intercepted or whatever yeah that makes sense here's another question it's a two-parter I can only show one part at a time so here's a scenario public client no user interaction the only requirement is to try to allow access to an API to just allowed clients does it make sense to try to add an authentication in this case the client is public I think there's no way to safely store a secret is there any alternative yeah that's a tricky one if this truly is a public client like a single page app or mobile app with no user then it depends I guess depends on how it's deployed so if we typically are concerned with the case of shipping client secrets in mobile apps or in a single page app because you can't do that right you can't put a secret into your JavaScript source or in a mobile app in the App Store because it would then get shipped down to users and everybody would have the same secret and so then it's not secret anymore if that's the cases but if that's actually the situation you're in if you're like trying to make an app store app and add some sort of authentication to it that's not going to help you that's not gonna do it and the best it's gonna do is its security by obscurity of your API so at least your API doesn't have to be a completely public endpoint but anybody who wanted to would be able to make that request fairly easily if they want to actually track down what your app is doing and reverse engineer it they can do it fine I just means that it wouldn't be necessarily on the public internet with no authentication if you have the ability to configure this single page app or mobile app with an API key after its deployed then you can treat it like a confidential client and again like it's it's treading the line there because depending on the single page app environment and like what else is on that device there may be other concerns there but at least it would have a specific secret for that one instance so that you're then only concerned about what happens if someone actually breaks into that instance and steals the secret out of it which is a very different threat than shipping a client secret in in a mobile app but it's very likely the case that the any sort of authentication you add in this situation is not actually adding authentication it's just adding obscurity that seemed like a fair assessment okay yeah yeah I think that makes sense yeah it's a tricky one for sure one of the workshops I did there was a there was someone who was describing their solution because they did want the assurance on a device that this was the real app and they actually had before it could like log into a system so they can't ship a client secret in the app when it's deployed they have to later enroll the device in order to add a secret into the device later that process involved this person with the app every person would have to go drive like two hours to the middle of wherever this office was and go to a desk show their ID enroll the device which I assume meant that they put some sort of certificate or key into the device which it would then use to authenticate all the OAuth calls and then a mobile app can be a confidential client because yeah that deploying that secret was then a very restricted one-time use one-time thing yeah no one's deal that you just reminded me of another facet of the the the way that refresh tokens are addressed in in 2.1 you talked about the rotation idea but there's another one that's part of it that involves it was like an either or either you have to rotate or you need to have this other thing which I didn't fully understand is that certificate-based some sort of way of client identification the the wording in the spec this is actually an interesting interesting point of contention my guess I would say uh-huh almost let me go back and show this it's so it's it's you know it's simply not one but it's also it's in the security background practice which is why it's in 2.1 do not want us not to find anything new it's just rolling up a bunch of specs so that's right in the security best current practice under I asked them to move this I don't think they have yet here it is so refresh token protection the requirement is that here the to yes or sender constraint so sender constraint refresh tokens is a general term for the concept of you need something other than the refresh token itself in order to use it so you need you add some other authentication there the easiest way is is I guess like using a client secret right because then the client secrets required in order to use the Refresh token right that obviously doesn't help you with public clients because public clients don't have a client secret so in that case you end up well there isn't really a good solution right now there are a couple of attempts at solutions and I would say none of them are really widely deployed or widely supported one of them is I think this is yeah mutual TLS so that the idea there is that it moves the authentication into the transport layer instead of in the application layer so instead of like a client secret which gets sent in in the wire of you know in the HTTP request this actually is before HTTP it's in the TLS layer so it's it's a bi-directional TLS connection so that the server authenticates the client just like the client authenticates the server that's one way to do it this that is consent that is useful in some cases and challenging in others and this a lot people who are saying that it's too much of a burden to deploy in certain situations so they're not doing it whatever there's another option here none RFC yet it's just a draft it's called token binding it's actually it needs an update since it there it hasn't been an update in a while in over a year so we'll see this is like again this is an attempt but this is not yet in our see it's hasn't update in a while so who knows how widely deployed this actually is there's another one which is called proof demonstration of proof of possession or deep hop which I apparently don't have on this list oops I need to add that Oh auth 2d pop this this is another attempt at doing proof of the possession or sender constrained tokens this time it is in the application layer yeah the theory with this spec was that mutual TLS is too cumbersome because it requires special server-side TLS stackin special client-side TLS stack in order to do the mutual TLS so instead let's put in the application layer where you actually can write code but again both have trade-offs neither of those are obviously the correct answer so that's the that's that's what the last of that means that's what sender constraint means is you need something other than the the Refresh token in order to use it and what that actually is is way up in the air right now like yeah not a good answer and there's no solid plan it seems like the more common approach is going to end up being rotation I would think so I would think so it feels easier to me the only concern really is that like I get parallel app I can see it yeah because mobile apps tend to have a lot of things going on in parallel so it just needs to make sure that it doesn't try to use a refresh token more than once because if it does it'll trigger the like the hack alarms right what what are words words work but it just means that like the app has to have some special you know a special pipe that all the requests for new access tokens go through that is able to serialize them so that it can't make accidently two requests in parallel for access tokens which is yeah it's some work but I think I think that's a lot simpler to me than dealing with mutual TLS or even depop but we'll see we'll see how it plays out yeah there's still a lot more work to do on that front obviously so did you take a note to yourself to add deep hop into the list of yeah connection points that everybody else wants to go ahead because that's like - open source let's go to OAuth oh yeah and there's a link at the bottom send a pull request well then you know what's sicker if you do that so I have Chinese auth stickers all right so we're at the top of the hour we should wrap up and get people some links of where to go for further further information I should plug my my book which you can read for free at both calm if you want a print version of the book it's available at oo auth - simplified com or as I like to use on slides oo WTF is redirects to there as well see we also have the OAuth playground at hakam slash playground and this is a fun walkthrough of all the different flows and you can try out try out the different flows that are in a auth and see what those look like lastly I want to mention in the octave developer accounts so developer dr. calm that's a that is a free developer account from octa and go there and try out try out our tutorials and trainings and stuff I use this in my in my workshops all the time for demoing stuff so there's no like time limit it's just like number of active users so anyway that's a good resource so yeah do you check out my book and it looks like we've lost Micah but thank you all for joining a stream and we'll do this again next week so same time same place start we didn't get to get to all the questions but we will again just join next week and we'll keep chatting so hopefully there will be some more more fun o auth news bye by the time next week rolls around so thank you for joining and have a great rest of the day

Channel: OktaDev

Views: 584

Keywords: oauth, oidc

Id: S7BnDwviDp8

Length: 60min 34sec (3634 seconds)

Published: Fri May 01 2020