 Hello and welcome to another round of OAuth happy hour. Good to see everybody here. Thank you all for joining We are broadcasting today on both the YouTube and Twitch. So feel free to Leave comments on either platform. We should be able to see both of them here. If you have any questions, but today I am joined by Grant and we're gonna chat about OAuth and I think specifically stuff around scopes and claims Yeah, I have lots of questions about Scopes and claims not I mean not that I don't use them every day, but I kind of use them in a more Perfunctory way, and I know that they can do a lot more that I'm not taking advantage of I guess So first of all what are what are claims? Why why would I care about claims? Yeah, good question. So I guess the What claims are are it's a it's a funny word for things about information about a user or about, you know, who just logged in and usually it's it's things that you see specifically as properties within a JSON web token both ID tokens and access tokens and Because many many OAuth servers use JSON web tokens for access tokens that ends up being a pretty common Term used to refer to the the sort of property names you you get in those okay, so like the user ID and Their email address and things like that are all claims that I would get Yeah, so in an ID token, you know The whole idea is that that's how the app can learn about who the user is who just logged in and the way that it Does that is by reading claims from the ID token So that will be things specifically about the user. It'll be the unique user ID in the sub or subject claim There will be the you can get the user's email address or name or Other other things the server might throw in there as well. Okay, and is it Is it always all information about the user or can anything go in a claim? For ID tokens, it's usually about the user because that's really what the app is trying to learn about But it could be anything and once we start talking about access tokens It's a different story because access tokens are not read by the application It's read by the API or the resource server and the resource server might need to know a whole bunch of different kinds of things That sometimes aren't about the user okay interesting so We we talk a lot about Claims as user information But we also talk about octa has certain user information, but I know a lot of people out there Keep already have a lot of user information Or information about their user or even information that might be useful For an app that that person is signing into that may not be Stored in octa. So are there ways that I can get other stuff into the ID token? Yeah, totally. There's a couple of ways One option is to use Is to go into your octa dashboard and configure what properties you want to show up in your Tokens and you can pull fields out of the user Record so if your users are actually being pulled from like active directory or something You can actually pull out data from that into claims that show up in the access token and ID token That's one option If you are even more like sort of disconnected from octa where you really do have your own like database with stuff about your users then Then there's two ways to handle that you can use hooks which let Basically when a token is created octa will go call out to your system And then you can return stuff that gets included back in the token or You can just store like an ID to like your own database it adds one of the claims So your token could end up containing a claim that's like User 25 and then in your database is where you store all the other stuff about that user 25. I Got you. I got you. Okay. So you were talking about the access token the access token is That's the first step, right? You get the access choke token and then exchange it for an ID token No, I got so the the access token is the thing that the app is going to use to call an API Okay, and the ID token is just the one that's going to read about the user So it's going to get both at the same time ideally. I'm using the authorization code flow so the authorization code is a thing that is Temporary short-lived and that's the thing the app exchanges for these tokens Okay While we're talking about tokens Yes, sir from FES has a question Says according to the OAuth spec a refresh token is for unique usage or should be for multiple usage Yeah, it's good question. The spec actually doesn't require either one of those behaviors it leaves it up to the decision of the authorization server and There are reasons for both if you if your application has a client secret then There isn't really a need for it to be one-time use because there's not really much of a chance of a Refresh token being stolen if the app has a client secret Again, there's always exceptions to everything, but that's generally the case However, if the app does not have a client secret It's because it's a mobile app or maybe a JavaScript app and in that case especially with JavaScript as many more Opportunities for that refresh token to be stolen in which case it makes more sense to make the refresh tokens be one-time use So that way if something is stolen then it can only be used once and then everything will it'll be it'll be obvious That there was a problem and you can kind of block access after that point. Okay Cool. Thanks. Yes, sir for the question Back on the topic of claims and scopes In other words, we've talked about claims and we've talked about getting user information What is a scope when I'm going to get when I'm going to authenticate somebody Like the ones that we're all familiar with if we've used an open ID connect is open ID email and profile Those are the ones that you tend to throw in there almost all the time What what are the scopes and are those is that it? Is it just open ID email and profile or there are others? Yeah, open ID is a scope that is Defined in the open ID connect spec and that's how you like turn on open ID connect So if you don't include that scope, you're gonna only get an access token to refresh token So including that scope turns on open ID connect in the flow and Then the other ones that open ID connect defines our profile email I believe address which I don't see people use very often and Phone I think also is another one and those are going to determine which profile Fields are put into the eddy token Those are all recognized by those are all part of the open ID connect spec and those are recognized by the authorization server by default There's another convention which is not actually written down the standard yet although I think we're gonna be working on that soon which is the scope offline access and It's a convention that a lot of servers have supported but basically that's how an app can request a refresh token And that's again, something of the a lot server will recognize That scope so that's the only set of scopes that are standard and that are like That make the authorization server do something You can define any number of scopes that you want entirely up to you It is completely freeform beyond that the the difference is that If you define any custom scopes the O officer doesn't really know anything about them It just knows the name of the scope and it knows like what sentence to show to the user when that scope is requested if you're using the consent feature Beyond that what it's going all it's going to do is going to put it into the token into the access token and It's then up to your API is to enforce that scope So when your API gets a request with an access token It can look at the access token and see what scopes are in the token and then it can make a decision about what to do Okay, so if I had for instance address in this in my scope when I request a token when it comes back the tokens going to say here's the Tokens that they have access to or here's the tokens they requested or the scopes they requested sorry The tokens going to say here's the scopes they requested and then my application would be able to use those to make Authorization decisions, right? not for address so because the at the like all the open you connect scopes those are Telling the authorization server the OAuth server to return data and that will just happen Any of the other custom scopes on the other hand? yeah, and this is this is one of the confusing parts about the term application and That term doesn't exist in OAuth because it actually kind of means too many things. So you have to separate We have to talk about instead the roles that are defined in OAuth which are The client and the resource server. So the client is the one that People often refer to as applications because it might be like a mobile app or like a a single page app The client is the one that the user is using and it's the one that is getting the tokens So it's the one that's going to get the tokens from the OAuth server and and store them and use them That's the client the thing that the client is sending the tokens to The access token to that is the resource server. So it's gonna make an API request to something It's gonna make an API request to some server somewhere, which is also going to be running an application Which is why this term is a little bit confusing, but if you are building a server side API You know, that's the resource server and that's the thing that's going to be reading access to this So those are the two Pieces that you are building if you're using octa as an OAuth server, right where octa is kind of sitting in the middle Coordinating so if you're building the API out You'll be reading access tokens looking at scopes and deciding whether to respond to an API request based on the contents of the token Okay, so let me see if I've got this all right for instance. I go in to log in to through octa But the one of the scopes that I request is For contacts I want to get a hold of your contacts Doesn't matter if it's Google contacts or whatever But I'm logging in through octa or one of the authorization server is and it sends me back an access token and ID token The access or the ID tokens going to have all the information that I asked for open ID email profile Whatever and then the access token is going to have in it that I requested access to contacts and Then when I make a request to the resource server the thing that actually has my contacts in it I'm going to say hey I've requested access to contacts and then it's going to make a decision on that end if Lee Brandt should have access to that person's contacts. Is that right? Yeah, so I would say it's more like That application is just going to send the access token. It doesn't really know what's in the access token It just sends the access token up and then the resource server looks at the access token and determines Yes, it is allowed to access this person's contacts because it contains that scope. Okay We have another question from yes, sir What does open ID connect bring to OAuth? Yeah, that's a good question. So OAuth is the sort of foundation of open ID connect It's the thing that is describing these roles and describing how these flows work and how these tokens move around Open ID connect adds an ID token. So there's no ID token in OAuth. There is no user IDs in OAuth Open ID connect is where that stuff is added So open ID connect brings in the ID token which talks about users specifically and it adds in The idea that applications can actually learn things about the user from an OAuth flow or open ID connect flow interesting Cool, and we have even one more question from you asked here Do you agree that the OAuth 2 should be processed on the back end and neither client nor client ID or client secret should be exposed on the front? So not quite OAuth is Perfectly acceptable to use in in the front end which means like in a single page app or in a mobile app You can absolutely do an OAuth flow From a single page application in JavaScript in order to do an OAuth flow in JavaScript you will need a client ID And it is the client ID is considered public information. It's meant to be public It is okay that it is put into the source code of a JavaScript app and you know exposed to the user That is perfectly fine. That is how it's designed The client secret on the other hand Is called secret because it must not be exposed to anybody. So if your application is Running, you know as a front end application if it is a single page app or a mobile app anything that that Would not be possible to embed a secret in you cannot use a secret for those flows However, you can still do an OAuth flow because OAuth flows don't require a secret so Yeah, it is um It is perfectly fine to do an OAuth flow from a server side up as well as a front end single page app However, you just can't put secrets into single page apps or mobile apps Which is why you would use like in uh the off code flow with pixie, right? Yeah, so pixie proof key for code exchange or pkce That is an extension developed which is actually just going to become the normal OAuth flow for everything at this point but it was specifically created because mobile apps and single page apps can't use client secrets and It adds in it it fixes a couple of edge case bugs When you don't have a client secret actually fixes someone if even if you do have a client secret Which is why it's being recommended for everything at this point. Yeah, and I think it's important to mention to everyone that None of this stuff is 100 secure It's all about how much risk you're willing to take on, right? Yeah, nothing is 100 percent secure even like encryption, right because Commuters always get faster eventually everything will get will get cracked so all security on on the web and in general is just about How many roadblocks are you putting up so that it becomes less likely that you are hacked? It's actually true with physical security too, right? Like you can break into a safe It just takes a long time The whole goal with a safe is to put enough layers of stuff so that it would be it would take too long For someone to break in it becomes not practical for them to do so Yeah, which is why people always say don't leave expensive stuff on the seat of your car Because if they walk by and see, you know, there's nothing inside your car. There's no reason to break a window and try and take it Okay, so we were talking about scopes Um For custom scopes, um, we already we may have already covered this now. I can't remember But when we're talking about custom scopes, um, is there any other reason besides Like the contacts example that we were talking about is there any other reason to create custom scopes? Or would you normally just stick to regular scopes? Yeah, so think of it as a way to um, let Let you let you create access tokens that have a limited capability. So if you don't make any custom scopes at all then Whatever your your api is your back end api a resource server It will respond to every api request That has a valid token regardless of what the token looks like, right? So any user requesting anything like every token would just be able to do everything and That actually is fine for some apis. It's usually smaller scale apis where there aren't that many different kinds of things going on But as soon as you want to be able to say To to issue access tokens that are like read only for example Where they can only read data and you can't modify data. That's where you start getting into scopes so And again, this is not about user permissions like a user might be able to up to modify data But you want to issue specifically a read only access token so that only this one application that a user is using Can can only read data um That's a that's a simple example of just read and write so in order to do that you would just create a new scope called write or Update or whatever you want to call it and then if it didn't if it doesn't include that scope The method for updating the API call for updating data would just refuse to run um So it lets you do that and as soon as you start getting more complicated apis like if your apis can do a bunch of different things So we're talking about contacts if you also had The ability for someone to upload photos to their account now you've got two different resources being managed you've got your contacts and your photos and At that point you may then want to again say I actually want some apps to only be able to access contacts and not access the photos in order to do that You use scope and then you make a new scope for the new kind of data. Okay. Now does the authorization server Let's say I send a request to authenticate someone With a scope of contacts, but this application doesn't have Hasn't been granted access to the contacts resource Does the authorization server reject it or do I have to wait until it goes to the resource server to particularly ask for those resources? You have a couple of options there. Um, and this is so this is going to get slightly out of the realm of Pure oauth because as far as oauth goes Any logic that the authorization server does and any policies that it has Does not matter to the spec. That's not relevant to the spec as far as client to authorization server negotiation, but There are many times that a Uh an authorization server will have its own way of managing these kinds of policies and that Definitely then varies wildly Based on what particular product you're using So octa has a certain way of managing these things Some open source systems have a certain way of managing them Some some don't have any way of managing this stuff at all and you're kind of just on your own Like you're saying it's up to the resource server to to define it But that's not something that's defined in the spec that's Defined exactly how how you use the spec Exactly. Okay um, i'm gonna i'm trying to to log into my octa account to uh To uh, see if I can demo this Everything's different I might have to uh, I just got the new dashboard on this account. So everything is different now It might have to come back to this Okay um So basically it's up to the authorization server and how the authorization server is doing is using the oauth spec As to whether or not they're going to reject an authentication based on a scope Or whether they're just going to say okay, that is a valid user Here's the scopes And let the resource server define whether or not they'll be able to access those things Yeah, so if I'm I'm um, I believe that in octa there is no mapping between Clients applications and scopes Um, there is for octa api scopes. So that's a whole different whole different topic. Um, so like you can assign users to applications But when you go create scopes those are Just on the account as a whole Okay, here we go. Here's my authorization server So you can see all the scopes I've defined Um, I've got ones for like photos. I've got secret photos. I've got Uploading photos and I've also got my contact scopes but these Are not mapped to clients all another i'm saying that there is actually a way to do it in your policies which is um, you can actually say Because you can make policies that apply to certain somehow because in our Here in our world I can have Multiple clients multiple applications multiple clients that use the same authentication server Right. So yeah, I have different policies for different applications and different scopes Yeah, exactly. So it's like like I said like The tools that you get for managing the stuff start to go pretty quickly into product specific stuff As far as the as far as oauth is concerned Um, and as far as like your app developers are concerned who are using your oauth server They're just going to be like, okay. I'm trying to do this thing This api operation Which means I know I need to request a certain scope and then it's either going to work or it's not And there's not a lot they can do anyway because that's all policy on the server Well, and that's that's how it happens right now. Anyway, right? You go to make a request If you're not authorized you get the 401 unauthorized back That's the way the HTTP spec supposed to work. Yeah, right Okay, so we have a question here from uh, mr. Cross site request request forgery I shouldn't say that it could be mr. Ormiz I suppose Hey, I'm wondering why the id token is actually mandatory in oidc thereby altering the oauth flow And thus making it incompatible with the basic oauth servers Other which otherwise still could provide a standard set of data via the user info endpoint Yeah, that is a fair a fair Question, um, I'm double checking that it actually is mandatory because I think that um So the user info endpoint is another option for applications to request information about the user And the user info endpoint is an api endpoint defined by the By the open ed connect spec It's meant to be part of the authorization server and the idea is that you actually use an access token to fetch data from that endpoint So it's possible for your application to ignore id tokens entirely And just get an access token and then go fetch data about the user from the user info endpoint And that's kind of nice because it means that um, you don't have to worry about parsing Jason web tokens at all you can just make a request with a That access token in the header and then parse the jason response. And that's the one in uh oidc That has the dot well dash known in the url, right? Yeah, the dot well known is the um metadata endpoint for the for the server so, um Or it's my this one the the metadata link Is defined as the you know the dot well known um o authorization server and if you click that You end up with this jason document talking about The server this is all about my authorization server. So I've got like the authorization endpoint the token endpoint but also in here is Oh, no, it's not on the There's two of them There's the oauth one and there's the open id Endpoint and the open id endpoints one that has the user info endpoint on it because It's part of oid not oauth, which is confusing but Makes sense when you think about it. Yeah, um, I'm trying to remember where that one is We should be able to find it In the spec Open id metadata url Oops, that wasn't the one I wanted to click. Well, here it is open id configuration So because this is a standard I should be able to just visit this And there is the open id endpoint for my server and here it looks almost the same But this one should have the um Should have a user info endpoint Yeah, it's up at the top there it is so I can use an access token to fetch data from that url As for whether the Whether that's required Like whether the id token is required by open id connect. I actually don't remember if it is or not, but The the If you if it if you're oh off server does publish that open id connect metadata url Essentially your application can just pretend id tokens don't exist Yeah well, I mean and it's nice if If you just want your clients to be able to get some basic information like Your first name so that they can display highly when you log into your application That's Not really worth going and making another api call to user info endpoint Just so I can get a first name to display on a on a page, right? Yeah, and actually so my my preferred way to do it the easy way is If you you're going to need an access token to make api requests If you also just want the user's name Or like just their email address or something or maybe their unique id then Um, yeah, you probably don't want to go make an api request as soon as you got the access token to go Fetch that before you show the page to show they're logged in so I do actually like Um to You add in the scopes open id profile email all that But you still do the authorization code flow And then by the time that you get the access token you make that you know request the token endpoint You get back the access token, but the id token comes along with it. It'll be in the same response And because you get that from the officer directly in what we call the back channel That's a secure way to deliver that message You can actually forget that this is a jason web token So like completely ignore that it's a jason web token and don't worry about bringing in a jason web token library And all you have to do is take the string Split on the dots and grab the middle part and then base 64 decode it And then it's jason data and then you can just read the data out of it So basically you can just skip the whole jason web token validation. Don't verify the signature Don't worry about bringing in a library Just do a simple string split and basically port decode and then you can read the user data that way nice Well, I hope we answered your question xsrf So I noticed that When we were looking at the well known endpoint or even the the open id endpoint There was several scopes in there that were like one of them was code The other one was code space token or code space like the uh response types. Yeah So these are um, so we've We've got these as far as this is basically telling me about the authorization server, right? Yeah, this document is talking about Uh, what the authorization server supports. So it's talking about like here's the links to use here's Ways that it will behave Here's some other ways. They'll behave Here's the grand types that it supports How it can sign tokens. Here's scopes that it supports Okay, so that scopes supported Um, like the one up above it had code and then another line. It had code space id token These are response types a response types. Okay, so those are the It can send you a Authorization code and id token together or it can send you a code all by itself or it can send you an id token all by itself Okay, that's right. That's why it was It was interesting to me to see code and id token on separate lines and then code and id token together It's code and token together It's a it's a mess. So The ones with a space when there's multiple values that these are what are called hybrid response modes and it's something That opini connect made up So response type code is to find an oaf. That's plain oaf. And that means that you do The authorization code flow in the redirect you get just the authorization code It's just a short string in the url and you have to go exchange that for your access token That's traditional oaf oaf also defined One called token which is the implicit flow and that means in the redirect you get the access token in the url That's bad. Don't do that. It's bad for a bunch of reasons It was a hack. It was a workaround because browsers didn't support cross site scripting or cross site requests Long time ago cross origin requests. So We had we had the implicit flow as a workaround. It is not needed anymore In the meantime over any connect had extended oaf and added what are called hybrid response modes So if you if you say only response type id token You actually get an id token in the url in the redirect and you won't get an access token at all And that's if you just need to know who the user is right That is there are there are times when that is all you need That's fine. Just do that If you do get the id token in the url like in the redirect you have to verify it You have to do the json web token validation and a whole bunch more validation of that token In order to trust is is that because it's just base 64 encoded and it's not Actually signed or you can't guarantee that it hasn't been messed with It is signed So you have to actually check that it hasn't been messed with because if it's in a url Anybody can just make that request to your application right your application sitting on the public internet With a redirect url like I can show you my This is the one I use for for exercises Example app.com slash redirect imagine that this is like an actual Application that is live That url is just sitting there on the internet, which means anybody can go and visit that link and then put in Junk up here, right? And this looks like a valid redirect from the oop server Right, there's no way to tell that it's not and if you are getting the id token this way Uh, it'll actually be in the fragment, but it'll be id token is blah blah blah blah blah So what's to say that this is Real or not, right? You have no way to tell until you verify it So because anybody can make this request because it is a public endpoint You have to then actually go and do the json web token validation Check the signature check all the claims check to make sure it's not expired and blah blah a ton of work, right? You have to do that That's response type id token now the when there's multiple these are I think they just went and found every combination of how you can combine code id token and token and Some of them are just not useful in my opinion But basically what it's doing is it's saying for this one In the redirect you get both the authorization code and the id token So when you do that Because you get one in the redirect you have to validate it You have to validate the id token signature and blah blah blah But then you use the code to exchange it for an access token, which you get securely in the back channel Right, okay This one makes almost no sense You would I don't think there's ever a reason you would ever use this one Because this is saying you get both the access token in the redirect and you also get an authorization code Which you can then exchange for an access token I don't know why you I don't know why you need the token the access token twice Right completely useless. Also, you're getting the access token in the redirect Which is the implicit flow which has all the same problems as we've talked about. Yeah so Don't use any of the ones that contain token because you never want to get an access token in a url so Pretty much you can just ignore those those three This one I can see that there might be some Cases where this makes sense because basically what it lets you do Is immediately in the redirect you can Extract the id token from the url validate it But then you get the user's information immediately without making another request And then you make the request to go get the access token securely Which will be a little bit slower So you could you know, maybe speed up your application by some number of milliseconds by Not waiting for the authorization code call to be complete Before being able to show that the user is logged in it's Debatable as whether that's actually going to give you any real meaningful performance improvement Or not or if you use experience improvement But that's you know, you can if you if you try hard enough, you can convince me that you have a good use for that one nice okay, um I was looking. Oh, I thought we had another question down below, but it was just not my bug how asking what we were doing We're talking about oh, I don't pretty connect Yeah, if you have any questions make sure you submit them in the in the comment section um And we're streaming on twitch and on youtube so Um, if your twitch is acting up, you can try us on youtube if youtube's acting up You can try us on twitch um What are some other common questions that you get about scopes or some common anti patterns that you see people using scopes or claims incorrectly Yeah, so with scopes, um, I I see some people trying to use it to build out their permission system. So if you uh, whereas like instead of saying Internally that like this user is only allowed to do these things So imagine you have like your admin users and your regular users if you try to go and define a scope that's like an admin scope and Your apis are only looking at that. That's a huge flaw because Even if your normal like consumer apps aren't requesting the admin scope There's nothing stopping a user from modifying the request that that makes to add the admin scope into the request And at that point the access doesn't will contain the admin scope And then they could then do the admin operations Even though they're a normal user, right? so you can't Use scope to enforce that because scope is something that the application requests and the authorization server Unless your authorization server and you're sure has actual policies of preventing certain users from being issued certain scopes Unless that's true Then scopes aren't going to let you build out the permission system. You're going to need something else internally For which users are allowed to do what? So that kind of actually takes us into the custom claims part Right where you might like an octa you're going to have users be part of groups So you can actually make a group in octa to find an octa which are called admin like your admin users add a bunch of users to that You can then define a rule which adds the groups as a claim in your access token And that way it's something that the oauth server is managing your application has no ability to influence What groups a user is in because that's all managed at the oauth server? And that way your resource servers your apis can look at the group claim to see to say, okay Well, this is the admin operation I'm only going to run if the admin claim is in the access token because that's something that the user and the application can't influence And if you have lots of Because it seems like I see a lot of people doing kind of micro authorizations where they have Millions and millions of groups that they have In they're in their user database or whatever and it seems like it would make more sense to have lots of scopes Rather than having a group that says this is contacts writeable and contacts readable It would make more sense to have that as a scope than have that as a group It depends on what you're going for so Like groups are one way to actually do proper user Access control like, you know, that's one way to do it where you can you can define groups as You know certain API operations can let me run by people in certain groups You can assign users into those groups and then that actually will prevent users Depending on who the user is from being able to run certain API methods. That's one way to do it There's other ways to do it as well, but you know, that's one pattern. However scope Can't be used for that because scope is something that applications and users can change and influence what Appears in the access opens requested So scope is more about Even if a user can do all these admin things or upload photos scope let's Let's an application voluntarily request the ability to not do those things So it's a way to limit what an axis what an application can do It's a way for an application to limit what itself can do, right? It's more about like it's more about from It's more about the application trying to protect itself from accidentally Getting too much power, but it's something it has to voluntarily do right, okay, so scopes would be editable Is what you're saying, right? Well, yeah, so think about remember when you started an OAuth flow the application Puts into the url the list of scopes it's requesting it's requesting. Okay, and the other server just sends back These are the scopes that were requested Yeah, pretty much so again the OAuth server might have some internal policies around whether or not certain users or applications can request those scopes but The sort of default if you don't do anything is yeah, the OAuth server just Repeats them back in puts them into the token. No questions asked um That's what I would that's what I would assume your system is doing unless you've gone to extra lengths to make that not the case um, but that's sort of the the default um, but yeah, think of think of it as If if you imagine you're you have your api docs, we can just go look up actually github has a good list of of github scopes So here is the list of scopes on github Scopes for OAuth apps available scopes. Here's all the different things Uh scopes they've defined. It's a long list And if you look it's things like oh, okay There's a special scope for deleting packages Which means unless the application requests that scope the access to token it gets will not be able to do this thing right So when you start an OAuth flow using a github app, like if I just go to travis ci and log in It's going to ask for certain scopes, but there's nothing stopping me as a user from changing that list so I could go to travis ci and sign in sign in with github and Did it? Oh, I'm logged into github and I've already authorized the app. So it just um Didn't prompt me so If I uh, if I do that in gognola, I feel to see Now I'm not logged into github here So yeah, if you look up in the in the url somewhere in here, there's going to be some scopes here it is uh Read org user email repo deployment repo status writes repo hooks. Okay. Yeah, so that's all these are the scopes it's requesting Okay, so you can change those up there and end up with one of those other scopes in your active token Exactly like as a user I can just go be like oh, actually I want all these other scopes too right And github doesn't know that the application didn't request those because as far as it's concerned the application did request them because That's what the request is so as um, you know, I could Make a request for every single scope and then that access token can do everything on my account now That's why you can't use it for like, you know restricting you know in a permission sense um, so what it does is travis says okay, I actually only need Certain things I actually only need to do certain operations And I would actually rather not have the risk of being able to do other things So I'm only going to ask for the bare minimum scopes that I need so that I can't do accidental damage But it's the application Opting into that voluntarily right So it seems like if you were going to do something like Let's say one of your scopes was contact delete right um, if you wanted to keep somebody from being able to just add that In the scopes in the url You would need to put in your authorization server some sort of policy that would stop them from logging in With a policy that or with a scope that they don't have access to Yeah, and that's again where it gets into like if your authorization server has that ability You can do that but sometimes there isn't that ability To be able to define those rules. It totally depends on the on the server Okay, so then it would definitely become part of the resource servers the responsibility to Not only check the scopes but check the validity of the access token that it's being sent, right? Well, not just checking the ability of the access token But also check Does this user have this role of Or are they in the group that allows them to delete records? Right, okay, so yeah deleting deleting is a good example of like um You can imagine that there's uh, you know only the finance director can delete items from the transaction log Whereas every other user of the system can add records But only that person that one Person in that role of finance director can do the delete delete operation And even then you probably still want to define a special scope for that So that normal in normal usage that person The access tokens issued to that finance director also can't delete records Until they're using an app that does want to leave records and because They are in that role And the application requests that scope then all the rules line up and they can do that operation Okay So we have a question here from melvin g I can get it up on the screen. There we go For web app with both a web front end it and back end client server Is there a any preferred location for keeping the access token in web client versus session in client server? Yeah, this is a very common question and the um Is not a good answer and the answer is mainly It's up to you to decide how like your own risk tolerance so the Because again, nothing is perfectly secure. So If your front end Has is actually the one storing the tokens itself Then those tokens are at risk of being stolen If your application is vulnerable to cross-site scripting attacks Right, so if you have a cross-site scripting problem Then the result is that the attacker can now actually steal the access token and bringing this back to the scope's conversation Depending on what scopes that token might have will determine how much damage that could do So this is again y apps would why it's a good idea for applications to request as little scope as possible for everything They're doing because if a token is stolen Then damage is limited to only the things that were in that token the scopes in that token Whereas if you're always using yeah Yeah, so if you're always getting tokens that can do everything to any api Then you're just always at a higher risk everywhere, right? so So that's the risk of putting the tokens like pushing the tokens all the way into the front end the the less The way to have you know less risk there Is you make your back end client the oauth client and keep all the tokens there where they're in the server They never make it down to the to the browser never in javascript never accessible from javascript What you have to do in that case is your javascript can't make api requests your apis directly because it doesn't have a token Instead it has to tell your back end to go make an api request and then process the data so Now the risk has changed if you have a cross-site scripting attack Or vulnerability the attacker can't steal the access token But the attacker could tell your back end to make a request with the access token So it can still steal data, but it can't steal the token right and if your Tokens again, this is like if you don't have any scopes then The risk here changes dramatically because the risk of stealing an access token means they can go make requests to any of your apis Whereas being able to trick your back end into making a request is limited now to be able to only request things that the back end Is configured to be able to request so you kind of changed the The the the the result of what happens if a cross-site scripting attack is possible okay interesting Well, I hope that answered your question melvin Sorry for the sort of vague answer, but that is how it goes with a lot of the security stuff Well, I mean anybody that's a developer should probably already know that half of the answers to their question is it depends right Okay, so we were talking about um Scopes and and claims it's interesting because you I that melvin's question actually brings up an interesting point when you were talking about um So if I am able to steal your access token Then I can do anything that you can do right Um anything that access stuff you can do anything that access token can do But if I put the access token on the server side then It seems like there's a little bit more of a risk of bleed over between user to user because that Back end is then using that access token right It doesn't it knows less about hey this user requested that it just says hey your request Was made from the front end to make this request with that access token I'm I'm trying to think if that's what you were saying um I guess what I was saying is um let's say your Let's say you're building a think me that like a concrete example here. Um, so let's say you're building a um A banking you have a bank and you have an api for the entire bank And then you have your web front end for customers to view their To view their account and like do transfers Within their their own accounts. Okay, but this api is the whole bank. So it's also used by tellers at the bank to Do things like update customer data or move money between customers or open new accounts all that kind of stuff, right? So that api does a ton of stuff But specifically like the retail front end app that customers use Only can do certain things. I can only do the things that the customers are even able to do like view transactions Um deposit a check and that kind of stuff So if that application is split into a front end the back end the single page app in the front end That calls to its back end for specifically the customer facing part That back end has code In it for doing certain api requests, right? It's not a generic proxy for the entire api. It's going to be like Here's a method that returns You know it calls the it calls the real back end api and then returns data for the front end to consume so in that example The uh a customer is using that app and and let's say that the access token lands all the way down in the browser So a customer user Can actually take that access token or even an attacker can take that access token And now try it at the bank's real back end api and see what happens And again, depending on how you you've set up your Your system and how you're checking things It might be the case that that access token can actually do a lot of stuff at the back end api that maybe the the web Back end wasn't set up to be able to do Right, so if you move the access token at the the back end of that customer app Then the Possible damage is limited to Only being able to trick the back end into making requests that it all already is set up to be able to request so you kind of limited What what could possibly go wrong right that kind of makes sense Yeah, I'm just stretching a little bit with this example, but But it's difference between being able to Go ahead Oh, it makes it even harder when we're talking about these things to try and come up with an example because Like you were saying earlier, there's so many overloaded terms there If you say you've got client front end client back end a resource server, which is actually the bank's back end That's going to be another application, right? So basically we're talking about three different applications running So when you say when your application makes a request to the back end application, which then accidentally or which then actually makes An api call to the api back end application. So it's Yeah Overloaded terms next time we do this. I'm going to have to get a whiteboard Well, we just got to get I mean when you were talking about it. I started going okay That one he's talking about the client front end Then he's talking about the client back end having the access token And then you've got the resource server that's receiving the access token And it depends on whether it's receiving that access token Via the client front end or the client back end I have an idea so I always use this analogy when I talk about the stuff of a hotel where You um when you go check in at a hotel you go to the front desk and you get a key card And you use a key card to go open the doors that's Just like oh in that example the hotel key card is an access token And this is different from for example taking your id card and swiping it on the door That's not how these things work, right? You always have this sort of proxy that represents that you have access to this door so If we try to bring this to this this example That is a That hotel check-in experience is like the front end having the access open where you know you're walking around with this hotel key card You can swipe it on a door And if you drop it on the floor somebody else can pick it up and they can do the same thing They can also go to the door and open it up um That's very different from for example you get a You get you get a key card where like a wristband or something And then in order to get into any rooms in the hotel you have to go walk up to like a Like some person what are they what do they call them the oh my god Like they're not receptionist. Not a receptionist. Uh like a like a Bellman or bellhop. Okay, right. It's like someone who's actually Yeah, I like accounts the edge where where they're the only ones that can actually open the doors and They have the actual keys to the doors. All you have is Something that says I'm a guest of the hotel and I live in this room where You can go ask them to open a door for you. That's like The client front end talking to the client back end to go access the actual resources where that That doorman Is the one with the actual access token the actual key And it's handling requests from the front end that makes sense right that way if you Um, so there there is no access open to drop on the floor anymore You might drop your wristband or lose that but it would then be uh, all that can do You know if somebody picks it up all they can do is go to This person and say hey I'm you know I'm Aaron staying in this room Plays up in the door for me and they may or may not You know let them in because they may recognize that it's a different person So Trying to trying to bring that analogy back into the real world. See if that worked I think we have one more question or comment from xsrf The aspect aspect of revoking tokens sessions of a malicious user is also relevant You can usually easily revoke a classic user session in a web app But revoking tokens or id tokens is usually harder So keeping them in the back end is a good idea um, I don't I guess yeah, I guess that does I guess that does make sense the The revoking access tokens or id tokens It's only harder if you're using json web tokens for your access tokens because you basically have to Add back in state like one of the points of json web tokens was to be able to have stateless apis where your apis don't need to Call back to the server every time to check if an access token is valid And if yeah, if you're doing that like if your apis are looking at the json web token access token and saying This looks valid then yeah revoking tokens becomes well pretty much impossible because Once it's issued it's issued until it expires If you want to revoke a token you have to check if it's revoked which Kind of Defeat the purpose of using the json web tokens unless you're sort of splitting the difference in and and doing this only when needed um but Using a session in that case it doesn't totally solve that What it does do is it lets one application? like terminate a user easier, but that's not quite the same as like if you want to revoke that Users access everywhere That's still a challenge because you still have to actually revoke the tokens Or end all sessions everywhere across all your your applications. So I don't know. Yeah revoking stuff. That is always a challenge and um setting yourself up for for uh some some Tricks by you know, you're you're making things difficult if you're only ever doing json web token uh validation local validation And those tokens are all the way and down into the apps. That's like the hardest way to manage revocation But there is never a easy way unfortunately Well, and we talk about all the time um, if you want to If you want to make it, you know a little bit more secure if your risk tolerance isn't high enough then you can um physically validate those tokens by going back to the authentic The um authorization server and validating those tokens every time, but we talk all the time about um risk per Request, right? So if i'm going to let's say The app the client application is a photo app and the resources the photos Then maybe when on the api call where I go to get your photos I just do local validation of the token that gets sent because Generally everybody can see those photos anyway, right? But if we're talking about I want to delete a photo or I want to change a photo Then we might want to actually validate with the authorization server before we let that action go through Just because the risk is a little bit higher there Yeah, exactly Okay, so we are out of time for this oauth happy hour Um, I hope we got to everybody's questions if you have other questions feel free to where should they send questions offline They can they should they keep commenting on this? Show on youtube yeah commenting on this on youtube I think it'll disappear from twitch in a bit, but it'll be on youtube forever So feel free to comment down below if you do have more questions or join us again in the future um, if you go to events No octadev dot events That is where we have a list of upcoming happy hours. You can see we have a bunch scheduled Coming up and I'm actually doing some live workshops as well if you want to come join those those are free and we're doing it for every every week for um the next two months or so we're going to be doing some more q&a's Because there's a lot of work being done in the oauth group and we're going to recap some of those meetings that are coming up Yeah, we check out subscribe on twitch and subscribe on youtube channel Um, if you're on youtube hit that little bell so you get the notifications when the next if you're like me I'm like man. I'd really like to go to one of those, but I always forget You know it comes up on thursday and then I forget about it. Um If you hit the little reminder you'll get a reminder before it happens. So, um, then you'll you won't miss one Yep, great. Well, thank you all. Thanks for the great questions and thank you lee for the excellent discussion Yeah, thanks, man All right, see you all next week