 Hello and welcome This is what the heck is OAuth and open IDC we get the slides going here You might recognize this name at the bottom here photo by Trish McGinnity That's a good friend of mine. The first time I ever saw her. I never even saw anything but her hands I just returned from a trip in Ireland and all I saw was someone Switch from a martini to a Guinness and I said I need to talk to that girl Her story is way different But even that night we were talking about Security and she mentioned oh wasp and my heart went a flutter I was like, I know what that is and she was the one that got me into the whole security spectrum of things I work for octa now. I never expected to work for a security company I was an independent consultant for 20 years and I would basically get contracts with various companies I had a stint at LinkedIn. That was kind of fun. I worked for evite for a while I had lots of fun like developer programming gigs The only reason I'm full-time with octa now is because well I worked for a company before them called stormpath and stormpath was like we want to hire you full-time and I was like I really don't like full-time and I was like make me an offer. I can't refuse. They did so here I am full-time employee. It's working out pretty well so far So I get paid to travel around do stuff like this right blog posts pretty good time But I like to tell the story of my name is Matt Raible. I'm a hick from the sticks I grew up in the backwards of Montana with no electricity nor any water Had to walk a mile and a half to the bus stop every day and it felt like it was uphill both ways But the cool thing is in the winter we skied cross-country skied like that was cool, right? But as a typical kid I would in the winter wear my tennis shoes in a foot of snow as we're walking to the bus stop So I wasn't you know a great child But this is a cabin I was born in on the left is the cabin and then my dad started a sauna business and he produced one and sold it to himself and That's their bedroom on the right there and that's where we had the Commodore 64 And you actually had to go in and start the stove and get it running for a while before the monitor would even function And then you could play Donkey Kong My dad tried to teach me Pascal and he tried to teach me a lot about comp you serve and the internet and stuff I just wanted to play Donkey Kong But I spent a lot of time on that computer. You'll notice the best thing about this picture is the border collie My laser is not working, but that's Sagan. That's our border collie and it's the first time he's ever stood still for a picture So I do live in Denver with Trish and our two wonderful kids teenagers So they're only wonderful when they're not staring at their phones. I also have a middle child His name is Hefe. I bought him off eBay in 2004. It only took 12 years to finish him He is done now except the clutch one out last week. So it's a Volkswagen. What do you expect? Well, I put a Porsche engine in him. So that's what took so long But he gets up and goes he's fun to drive But not in the winter So I do work for octa. How many people would consider themselves developers? Okay, different audience Maybe I should put my suit coat back on so One of the questions I ask is who likes writing authentication Obviously none of you do because you don't even like writing code or maybe you do like writing code You just don't consider yourself a developer So we do user management in the cloud Also called, you know users as a software service the abbreviation for that is you ask not a very good abbreviation There's also authentication as a software service doesn't get much better there So how many people have heard of OAuth or OIDC? Most of the room, okay, we already asked about developers you probably haven't written authentication from scratch But maybe you've implemented in your company has anyone like used it as a provider So we got a few of you. Okay, is there anyone here for a particular reason? except there's beer after Like if you came here to learn one specific thing, let me know I used to pick on people and it would be awkward, right? Because it'd be like, I don't know. I'm just here. So I won't pick on anyone today No one for a specific reason. All right So How many of you have a basic understanding of OAuth? Half the room how many things or who thinks they're an expert? Okay, that's better crowd than my last crowd the last crowd is about Same size and most of the hands went up and I was like, I don't even consider myself an expert So this is gonna be interesting. They didn't call me out on anything luckily, but yeah I'm not an expert, but I do know a lot of terms and how it all works So that's what I hope to do tonight is to show you and tell you about it So it's not confusing and it doesn't you know confuse you so Let's start with a bit of history. I don't know if you recognize this dialogue But this is the way the web began way back in the day when we started protecting html pages with just basic authentication And it was awesome. The problem was is Customers started saying I really don't like that dialogue that looks different on different browsers I want to have my login look the same on each browser And so that led to form-based authentication and then once you got into form-based authentication It took it away from basic and you had to start doing things like keeping your users in databases And then you had to start worrying about passwords and password hashing and all that kind of stuff and then maintenance So it became a lot of maintenance to actually, you know implement this kind of system But the one thing I want you to notice is the authorization head of their authorization Basic and then a string after it because we're gonna come back to that So to create a better system for the web Federated identity was created for a single sign-on. So there's two main players in a federated identity system There's identity provider that might be like a Google or Facebook or someone like octa and then the service provider Which is actually the application that contains the data So here's an example just from some of our documentation how it works is for federated identity You'll be in a browser. You'll navigate to an app You'll click on a login button It'll respond with a client front end that maybe is in that app or somewhere else and then you request to sign in You successfully sign in comes back to your browser and then it redirects to there So if you've used Facebook login Google login and things like that There's lots of redirects going on in your browser that you see So federated identity was made famous by Samuel 2.0 and Oasis standard released in March 15th, 2005 It's a large spec, but the main two components are authentication request protocol and Samuel assertions So this is what Samuel assertion looks like lots of XML not a lot of information in there for all that XML Right, you can see in the blue. There's the issuer. There's you know, my name there There's some other stuff down here about it was password protected transport the audience and attribute name But very non developer friendly, right just machine-to-machine kind of stuff still very popular It's our most popular thing at octa. That's what most people used to add authentication to their apps But it's basically a session cookie in the browser that gives you access to web apps So it's limited in the kinds of devices it can work with and what you might want to do outside of a web browser And so a lot has changed since we built apps way back in 2005 people were doing WS star and web services and stuff like that and now We're into This thing isn't working. I'll quit using it It made sense, but a lot has changed since then so There's a lot of confusion online if you look up OAuth and try to figure it out If you use stack overflow a lot of developers use that you'll ask a question You'll have someone that answers that question and then you'll have a sub answer of that that says you're wrong Check out my blog post and then you go to blog posts and on there There's two comments that say you're wrong check out my blog post, right? It's an infinite mess So what we're trying to do today is just clarify the terms and show you how everything works And it's weird because like the HTTP spec isn't that confusing But OAuth is a spec and it confuses a lot of people and I think it's just because there's so many terms And there's so many different ways of doing things So back in 2006 We had simple login with just basic authentication. We had forums and we had cookies not much more than that a Single sign-on across sites you do sample. That's just what you do is mobile apps didn't exist the iPhone was released in June 29th 2007 and You know delegated authorization wasn't really a thing that people did So this gave rise to the delegate authorization problem. It's what happened was how do you give a website access to your information? Without giving them your password. So back in 2006 You didn't you gave me your password? So at the end of signing up for Yelp or signing up for LinkedIn They would prompt you and they would say which email service do you use? What's your email address and then your Gmail password? Right the password used to log into your Gmail and the idea was that they grab your login They go and get your contacts that send them an email and they throw away your password There's no guarantee that they throw away your password though, right? They could go and check for new contacts all the time So it's not really a great way to be secure. So How many people have seen one of these? Right login with Facebook. If you've seen something like this, you've used a lot. This is a lot Delegated authorization Inspired a lot the ability to basically say hey on your behalf. Can I get this information and You can think of it like hotel key cards So if you have a hotel key card, you can go get access to your room or to the gym Or to various services around the hotel But to get that hotel key card you have to go to the front desk Also known as an authorization server you Authenticate with the front desk you give them some form of identification and then you're good to go You get your key card and you can go around and you know access resources around the hotel So I like to show some diagrams and show you how this works So delegate authorization with a lot 2.0. You basically say I trust Gmail and I kind of trust Yelp I want Yelp to have access to my contacts, but only my contacts So you as a user will click in Yelp on connect with Google and You'll be greeted with a dialogue from Google that says hey log into Google and If you're already logged in maybe you don't see that maybe you see this screen instead that says hey I'm asking for consent can Yelp access your public profile and contacts And once you do that it comes back to Yelp and Then Yelp will basically go and get your contacts from Google So that's how the whole you know redirection works and what I'm going to do is I'm going to use this diagram throughout this talk To show you the different pieces of OAuth and how it fits in So there's a number of different terminologies or terms in OAuth and this is what makes it confusing There's actors. There's clients. There's an authorization server. There's resource server. There's redirect URIs There's access tokens. There's refresh tokens. There's all this stuff. So let's start with actors in This system you will have a person that's talking to a client a client in this sense is an application Right. It's the worst overloaded term in tech is client, right? It can be someone you work for it can be someone that I already do all that kind of stuff in this particular talk It's an application so a resource owner is you going to an application and then authorization server is basically So the resource owner first of all is the the one that owns the data in the resource server For instance, I'm the resource owner of my Facebook profile or my Google contacts The resource server is the API which stores the data that you want to access on the very right there And then the client is application wants to access your data and the authorization server very top is the main engine of OAuth So the resource owner is actually something that can change Depending on which flow you're using in this sense It's a person can also be a company can also be an app talking to another app and there's different things in OAuth that allow that to happen So just to put some more concrete examples in here. This is you know, someone using a browser Authorization server is Google resource servers like Gmail or your contacts So clients in the sense of OAuth can be trusted Confidential and public which is basically non-trusted. So there's a significant distinction between the two Confidential clients can be trusted to store a secret and you can't get to that secret So if you're running on a desktop or distribute through an app store like me people can probably get to it, right? But if you're running on a server people probably can't get to it So you can trust that with a client secret And you know, you're running in a protected area. So public clients or browsers phones IoT devices and then Confidential clients are like an API that you host or maybe you host in the cloud smart TV Right those can probably be hacked too, but in this sense, they're trusted and then servers on the end there so How it begins is you have a client you have an app you've built an app You have to go and register it at the DMV. So the DMV is OAuth is client registration and it's basically you getting a license plate for your application So in the previous example when I showed that Facebook pop-up It said do you want to give access to bike to workday because I was signing up for bike to workday I logged in with Facebook and it's basically saying they registered so it knew it was bike to workday, right? That's why it was in that dialogue. So when you register your client you specify. It's a web app It's a native app Android. It's Chrome app They even have PlayStation 4 here and then you give it a name and then you give it authorized JavaScript origin So that's where it came from right if you're talking with XHR or back channel in the browser And then authorized redirect your eyes is where can it go back to so you have to whitelist that information to be more secure so an authorization server is basically the tokens are retrieved from the authorization endpoint or what happens is your first redirected to authorize and then once you go to authorize you'll get back a code and once you get that code Use that code to go get an access token and then once you have that access token you can access your resources You can also introspect that access token to make sure that it's a valid JWT or string or whatever it is And then you can also revoke it So those are some lines to say hey give me a token and revoke it So there's two types of tokens in OAuth. There's access tokens and refresh tokens So access tokens are the token you give to the client to access the resource server and they're meant to be short-lipped so minutes Maybe hours, but certainly not days or weeks refresh tokens are for days or weeks and refresh tokens are just used to get a new access token So the best thing you can do is actually have your access tokens really short because you can't revoke them So even if you delete the person's account if they have a valid access token, you know as long as it hasn't expired They could still go and do stuff. So it's very important that those are short and Refresh tokens can be revoked so access tokens can be refresh tokens can be So their long-lived usually requires confidential clients with authentication Meaning that they actually use a back channel to get the client secret and send the client secret Oh, that was important. So at the end here it says hate these animations OAuth doesn't define the format of the token That's very important because a lot of people and even octa we use jots or JWT's for our tokens That is not a standard thing that we have to do It's just something we do because we think they're a little more secure So access token types the self-encoded tokens. Those are JWT's those contain all kinds of information in them about the identity of the user and Well, it doesn't contain identity just says hey, they can validate they can access this resource And here's the scopes that we gave permission to do that with the reference tokens are basically opaque tokens that are just Random characters in a string so they have absolutely no information in them But they're still valid access tokens in OAuth nomenclature And so I know there's a lot of words and I'm talking fast and there's a lot of stuff in here I will make the slides available up on Speaker deck after and if we're lucky we'll have a video So let's go through the flow again with some of these terms defined So we have a client right that's our app. That's yelp.com We have the resource owner clicks on that connect with Google You go to the authorization server with the redirect UI So when you send to the authorization server in the beginning you actually have a redirect URI as a parameter in that URL and Then you specify the response type as well It goes and gets consent from the user back to the redirect UI with authorization code Comes back to your callback that goes and exchanges that code for an access token to the token endpoint And then you can talk to your resource server with that access token Any questions so far? So the other three terms I want to discuss is scopes consent and grants because this is a real meat of a lot It's all about authorization has nothing to do with authentication People are like what that was rather occasion okay So scopes scopes are additive bundles of permission asked by the client when requesting a token So this is basically who owns the data who gets to specify the authorization policy So as a developer when you define an API and when you you know do things that require someone to log in or someone to Authorize you define those scopes and so you'll notice here the scopes are you know This application will be able to read tweets from your timeline. See who follow follow new people Update your profile and post tweets for you. At least they're telling you right And then the application will not be able to access your direct messages or see your Twitter password Like is that even a thing that Twitter allows like I wouldn't think so but you know this dialogue did come up I didn't get the screenshot someone else did but you know it gives the user Information about the scopes to allow and to deny You had a question So access tokens are always used because those are what say you have permission to do this The refresh tokens are only used to get new access tokens And so I'm going to go through there's various flows that you can use depending on the device or depending on the app You're building and and some of them don't allow refresh tokens Like they don't give you a refresh token so your access token expires well You got a prompt user to you know, authorize you again or whatnot So that's a security measure because they only really give out refresh tokens to the most secure way of doing it Which is sending a back-channel client ID and secret to get your tokens Mm-hmm. Did you want a book? Yeah, which one? API security or a lot to Security ready? No, I'm just kidding. You could come up and get it when you want, but we got one reserve for you No, so you have to capture this consent from the user, right? And this is probably one of the stickiest points of a lot and what makes it hardest is You have to basically trust or it's called trusting on first use and it's a very significant change in the web because People especially like our parents are used to just username and password you prompt them for the Gmail username password They're like, I know that I'll get in there, right? And they'll type it into anything but this is a whole different thing where you're actually saying hey do you authorize this to actually access your account and It's giving For one year for 30 days for one week or one day those are options that you can put in there You don't see this a lot, but it is part of a lot where you can say hey, this is only for a particular range of time and Then you'll notice the scopes over here, you know, it can do your network updates that can send invites and messages I would deny that one right if it can talk to your network Yes Well, there's an issue at and expires that there's no real duration Authorization server, yep. Yep. Yep They'll have an invalid JWT and it won't work Or the other thing that we do is we have a skew, right? We allow a certain variance like 30 seconds or 45 seconds or even as a developer if you're integrating one of our SDKs you can tweak it right you can change the skew to allow a little bit of drift so it doesn't have to be exact right, but you don't want to give too much right because You know someone's messing with our clock that could be insecure No, no So they have to actually Authenticate take that code send it to the token endpoint and then they'll get the two right access and refresh if someone steals access token They're probably not gonna steal both right. They're just gonna get one and not the other so I owe you guys books if you want them You want one API or a lot? Okay, well, which one so I can reserve it This one spin right you can read it on a plane And then down here you'll see you may revoke access at any time by going to your application It's in your account settings. So this Typically brings up a window that looks like this and it says hey you're on Facebook These are all the things that you've logged into so if you go in here and you revoke access or you you know Kill it what you're doing is you're just killing that refresh token because you can't kill access tokens are not stored But you know they might store your refresh token there so they can go and get a new access token So now we've talked about scopes and all that. Let's look at the diagram again. We have client resource owner Go to the authorization server that redirect your eye. The scope is what you're trying to do with that API So you want to get profile and you want to get contacts? So that's how you communicate with the API and what you're trying to do or what you're trying to authorize the person for and Then the authorization server will request consent from the resource owner, right? That's the thing that might be confusing for our parents and then you go back with the authorization code Everything else is pretty much the same from there But we've talked about the clients the token types and the endpoints of the authorization server And now I think it's important to talk about the two different flows The authorization and getting the tokens and they don't have to happen on the same channel. So there's two channels There's front channel and there's back channel Right Yep, so the front channels what goes over the browser plain and simple The browser redirects user authorization server user gives consent all happens on the browser The back channel is a direct HTTP call from the client application to the resource server to exchange Authorization code that it gets back in the URL for the tokens access token refresh token These channels are used for different flows depending on device capabilities you have So for example a front channel flow the resource owner starts the flow to delegate access to the protected resource Client sends authorization requests. This is basically the same thing that I showed with the boxes It's just a little different way of looking at it What I like to look at it because I'm a developer and I like code is to look at the HTTP requests So you're all familiar with URLs even though you're not developers You can be though don't ever say you're not a developer because you can be but you make a request To Google and so when you click on that login button what's underneath of that login button? It might just say like slash login But it's going to do a 302 redirect to this and it's going to have those scopes in there like gmail that insert gmail That send those are whatever you define in your app And then there's going to be a redirect ui response type client ID and state state is just a random number that you Made up, but you want to validate it when it comes back to make sure it's the same number The response is going to be a 302 found and it's going to redirect back to your call back And it's got that code in there and that state so you can choose to validate or not, but you probably should and Then the back channel flow what happens is the client exchanges that authorization code grant right for an access token refresh token Client access is protected resource with the access token So HTTP wise how that looks is you do a post to the token endpoint And it will always be this content type for form URL encoded They'll have that code that client ID client secret right because it's going on the back channel So it can do that has a redirect ui and the grant type of authorization code the response is your access token Right. It's got a token type of bearer expires in you know, 60 seconds refresh token is also in there and then You can access those resources. So in the beginning I said remember the authorization header Same thing here instead of basic. We're using bearer and we're passing in that access token and then we're hitting a secure You know API and it has information in there. Yes So the question is when do you ask user where do you ask a user for confirmation So chances are if they're already logged into the site you might not right it might just say hey redirect back Like you just see a flash in your browser Sometimes you can actually pass a parameter that says make sure and prompt them So they click a button even if they are logged in sometimes you have to log in and then you have to click a button So that's that's still something that happens like on Authorization server or the IDP or Google or Facebook or octa or wherever you're redirecting to is that make sense? Okay, and you had a question as well. Okay Did you want a book? You don't have to I mean if you're gonna burn it then I'm not gonna give it to you You want that one? Sure. All right There you are Yes So it depends on the flow and we'll get to those in a minute, but basically if you're doing Implicit flow, which is only on the browser Guess where you're storing it on the browser, right? probably in local storage and and That works awesome until you have third-party scripts and then third-party scripts might be able to access your local storage And if you're a developer you're developing an app You never have third-party scripts until marketing gets involved and then you got them all over the place, right? So that is not as secure as doing the authorization code flow where your tokens are stored on the server in a session or Whatever Redis or whatever you configured to store those Does that make sense? question Then Yes Well, so the question is a marketing gets involved like what do you do? How do you handle that? So I think it's one of the reasons that I kind of got into security because the first time I went to a conference with Trish as a Developer it was in Kansas City and you know, I meet a guy and he's in security and I'm like, hey I'm a developer. You know I work for companies. I do a lot of consulting and stuff. He's like you write apps I'm like, yeah, he's like I can hack your shit. I'm like We never even said hi right and that's kind of the developer or the the security community Right attitude against developers is like I can break your stuff, right? And so I've been trying to make it more of a cognizant thing in developers minds to be aware of security Right because most people like are kind of aware but developers I think have the ability to be hyper aware and like notify people right just like we write a lot of tests for our code We should be testing for security We should be you know running OOSP tests and stuff like that on our code to make sure that doesn't have vulnerabilities And if marketing wants to get involved be like first of all the worst part about Marketing and third-party scripts and stuff like that is how much it slows down your site I don't know if you saw but when GDPR came out Like there was some sites that had to strip a lot of the stuff off and man the web was fast again Right and so even our site developer dot octa.com like if I'm on a plane on a slow connection Like it slows down because we have so many like tracking scripts in there to see how where people came from or where they're going Right if we took the web back to where it was and we didn't have all these tracking scripts Like it would be fast again. Alright, so that's part of the problem And I think it does start with the developer to say hey You're really slowing down our website. You're making a bad user experience, right? This should load in three seconds on mobile takes 19 seconds like you're kind of you know Even though it works when you're in the office on a fast connection people on a mobile device It really stinks, you know, so I think it starts with the developer to kind of push back. I owe some books Oh, what's one? What about you? That's all we got left. So there you go. You two win All right, so now we have a front channel the back channel. We'll just go through this one more time This goes on the front channel right to get or log in or get consent You request the consent from the resource owner comes back on the front channel and then it goes back channel to get the tokens Right. So this is authorization code flow. It's a gold standard of OAuth It's the most secure way that you can implement OAuth, but there's many different flows that you can use So the first flow is called implicit flow. This is two-legged Optimized for browser only client So if you're actually developing an app that has no back end and it's just like an Angular app or React app Or it's a single-page application. It logs in it gets an access token It wants to talk to all kinds of other parties, right? They used to call them mashups I don't know what they call them now. They call them spas, right? So it doesn't have a server-side component You can do that with implicit flow So most OAuth providers will allow this and you know, it's just with the caveat that hey You're probably storing the token in local storage. So be aware of that and also be aware that you don't get a refresh token So you as a developer have to be aware that you have to wait and know that it's going to time out Maybe prompt a user to log in again and stuff. So that can be you know something But it's also not required that you don't support a refresh token So on octa for instance, we have an implicit flow that you can check the box And then you will get a refresh token as well And then we have SDKs for like Angular and react that will actually refresh it for you So they make it so it's not so bad There's also authorization code flow, which we went through for the most part Client credentials is a way of doing like server-to-server communication or maybe company-to-company And so there's no real user involved and you'll still use access tokens you'll use scopes a lot more and You can also do like, you know Asymmetric keys if you want symmetric or asymmetric There's also resource owner password. So if anyone ever talks about OAuth and Bashes it usually they talk about this and this gives you the ability to do the same thing That you did on Yelp you prompt someone for their username and password you send it directly to the Authorization server and you get back access tokens, right? So kind of the old way the reason they did it is to support like desktop apps that couldn't pop a browser and do a redirect and You know just legacy application So if you're implementing this it's because you're in a bind and you just need to get something working And you don't have the ability to pop a browser and do the refresh thing So even in desktop applications even in phones you still got a pop a browser, right to make all this kind of stuff happen There's also assertion. So this is the ability to actually integrate SAML with OAuth So you get in a SAML assertion you convert that to access tokens and That's a recent addition to OAuth. There's also device flow, which is not in the spec But you might have seen this with Netflix or something on your TV where you try to access Netflix And it gives you a code back and you actually have to go on a browser on your phone Type in that code and what it's doing in the background is it's polling to see if you've actually entered that code And once you are then it goes and gets access tokens and all that and it still operates like the same way So there's six different flows It's necessary because of all the consent from the client who's making consent and allowing server-to-server and allowing these Different devices to work as a lot of complexity, right? So when people ask you if you support OAuth at a company, you know clarify that hey We have you know three flows that we support not all six or whatnot. So this is a useful tool if you're actually a developer My buddy wrote it Nate Barbatini allows you to put in an authorization UI redirect UI client ID scopes all that and basically mimic it So if you registered an app on Google or Facebook or octa You could plug in the values that they give you back and you could get an access token So you can see how it works There's an even better one by my friend Aaron Perrecchi who wrote the OAuth 2 book we hired him in March So he helped write the spec It was a big win for us that we got him on board with us. He's a developer advocate like me He wrote this that actually allows you to do all the different flows and it dynamically creates an app a Client a user all that on octa, right? So you don't have to go and do anything you just basically click buttons and copy and paste So normally I go through and I show a demo of that But since I'm the only one standing here between you and beer, I'm not gonna do that So you can see this causes a lot of developer friction, right? Because one of the biggest pain points of the OAuth is having to manage the refresh tokens You know, do you do you track that time? It's gonna expire and then you know send it to get a new one developers really love API keys because you get an ID and you get a secret and you store those and you Don't have to worry about it, but it's terrible for security Right with OAuth with the ability to have rotating keys and all that that validate your job So like it's much more secure. So what's happened is this came out in like 2008 2009 The tools and SDKs are really good now when I first started at octa I had a really hard time because in the first couple weeks I was like at storm path We had all these SDKs and I could just show people how to use them and it was great And at octa like we have no SDKs like how am I going to show people how to write an app against us But then I realized we were OAuth 2.0 and OIDC compliant So I could use anything that supported OAuth 2.0 So I went out to spring security and I said hey you have an OAuth component Can I use it and I wrote one of our most popular blog posts? That's only like two pages long right to just say hey You can use a third-party library You don't have to use our stuff and now we have a lot SDKs to make it even easier for people But like our spring boot octa starter basically makes it so instead of putting five properties in you put two Right and we're just a very thin wrapper over a lot of things So that's really made it more popular and why a lot of people are using OAuth for their API So there's some security issues too many inputs that need validation right CSRF can be an issue So make sure and implement CSRF and that state parameter ensure flow integrity authorization codes can be leaked Always whitelist those redirect URIs and ensure proper URI validations That's why you can't use wildcards like you can't register, you know localhost 8080 star That's not in the spec some IDPs allow you to do it But you know don't do in production And then token hijacking by switching clients so buying the same client to authorization grants and token requests Leaking client secrets and unbound and bear token So one of the biggest complaints from the security community like yourselves is that this is Still like a session cookie right the access token is very much like a session cookie So there is a draft specification of a proof of possession token extension that kind of binds it more to the user that requested it It's not quite there yet, but it's being worked on enterprise use cases You know decouples authorization policy decisions from enforcement People really like it because you can use it to revoke a person's access to everything Right if they're using a lot that the company you can say hey They just got terminated We're taking them out right and you revoke all their tokens and as long as your access tokens are like a minute Then you know there's a 30 second window that they can maybe do stuff But you know maybe wait till their access tokens inspire and then go from there And you know it's it's federation with an IDP So it allows you to use the same users for all your apps, which is great for developers because now they don't have to write authorization So some facts it's not compatible with OAuth 1.0. You notice I didn't even mention it I took those slides out because I don't even want you to know about it It's not a protocol It's an authorization framework and it's not an authentication framework. It's actually in the spec So I highlighted in red, but you can see that they were determined to show you as well OAuth 2.0 is not an authentication protocol Absolutely nothing is known about the user all you know from an API perspective is they sent in these scopes and they have this access And in the token it just says hey, you know, here's a unique identifier, but not much other things out there So back in 2012 and this is all happening with simple login with OAuth 2.0 Even though it's more authorization, right? You could do sign-on across sites mobile app login delegated authorization It was widely adopted and it kind of became a victim of its own success People are like what it's not an authentication protocol. Well, there's no standard way to get the user's information So if you can't find out who just logged in like that's not authentication Every implementation is a little different just because the spec is kind of loose and there's no common set of scopes So when we're looking at HTTP requests, we had like gmail.insert gmail.read, right? Those are gmail scopes They aren't, you know, across different applications So what happened is Google and Facebook in like 2009 they used OAuth and they used it for authentication too So what they did is they established a slash me endpoint And if you hit that slash me endpoint with your authorization token or your access token, then you got user information So the access token just proved the client was authorized and intended to be consumed by the resource server So it didn't really tell who when or how right the person got in so Back to the drawing board open ID connect So open ID connect is a layer on top of OAuth 2.0 and at one point when I joined doctor We were like hey, oh IDC is what people really want to know about They don't even care about OAuth, but because it's just a simple layer on top of it You can't really say one without the other right so OAuth 2.0 is a more common term And then oh IDC is like here's how you get user information So OAuth 2.0 for authorization open ID for authentication So it extends OAuth 2.0 with a new signed ID token. So we're gonna look at the HTTP request It's gonna come back not only with an access token, but with an ID token and It's got a standard set of scopes. So I think there's like 10 total. Here's just a few profile email address phone It's also got built-in registration So you can do dynamic registration of new clients without actually going and clicking through a webpage also discovery So you as an end user instead of typing in the authorization endpoint the token endpoint You know the introspect endpoint the revoke endpoint like to configure your app You have to type in an issuer and then add a specific URL tacked onto that issuer is all those endpoints And all the different information all the scopes it supports and all this kind of stuff So it makes it very easy to bring your own identity Sports high-level assurance key-sample use cases good old enterprise stuff Google Microsoft octet. We're all Instrumental and founding it so authorization requests looks the same except for the scope is different, right? Open ID and email and you'll always use open ID if you're trying to get an ID token That's just one of the scopes you have to put in there Then you'll put like profile email or wherever else you're trying to get the response looks the same, right? Nothing changed there as far as a token request nothing changes either. You're still sending an ID and a secret But you get back an ID token and that ID token is a job. It's not just a random string like you can for an access token, right? So here's another way to look at it. The difference here is you'll see number one is that well-known open ID configuration URL That is standard. So if you have an issuer URL, whether that's Google Facebook octet, whoever You can type in that URL and get all the information all the scopes that API supports all the endpoints for the token validation Authorization all that there's also JW KS Which is the keys that are used to validate the tokens and you can rotate rotate those because they're at an endpoint, right? So that makes that a lot more secure and then the user info endpoint if you want to go get more information about the user Maybe you suspect that the ID token stale or something like that. You can go with access token and get that So just look at the flow again The only difference here is the scopes are standardized now Everything else is the same and You'll exchange the code for an access token and an ID token and Then you can also go to the user info endpoint and have the person's information so you can say hello, Matt So does anyone know the what is it the nickname for JWT's? job Right and so in Java land. There's this thing called GWT Google web toolkit. They called that GWT So when I first saw you know JWT has like is that jwit? No job So it's actually in the spec like in the second paragraph. They define it, you know jot It's a trustworthy or the standard for token authentication. It has basically a header that defines algorithm It's got some claims in there and this AMR claim is actually tells you how they logged in So it says PWD there. So, you know, they typed in a password if they happen to use MFA I would say PWD and MFA if they use face ID. That's also in there So there's all these biometric, you know values that can be in there as well And then there's a little more information about the user, right? And you can populate that with all kinds of stuff Json web token IO is a site that we wrote at storm path that allows you to basically paste in a Jot and then it'll decode it for you so you can kind of see some information there The grant types you might use we support authorization code implicit Authorization code for web apps or for native apps iOS and Android or client credentials for server to server So you won't see that with all IDPs, right? I don't know if Google let you do that The difference is it octa like we let you manage your users, right at Google You can't really manage users. You just let them log in. You can't put them in different groups and stuff So for native apps, I like to point out some of the best practices one is Never use an embedded web view in your app Because if it's embedded in your app, then you can access Information in there. So the best thing to do is pop a browser and you won't see anything going on from an app perspective But when it comes back in that callback, it'll have like an access token, right? And then you can do everything from there So you don't store client secrets and apps that are distributed in the app store you can use what's called pixie RFC 7636 to protect your authorization code from intercepting So it's a little more guarantee that it came from this device It does a little challenge response kind of thing and adds a few more codes to it There's also this guidelines for native apps But there's also a project called app off that has SDKs for JavaScript iOS and Android use those It'll make it much easier. You basically write like 10 lines of code and you have a lot of authentication in your apps So you guys probably aren't as interested in this, but we have a whole bunch of demos on our GitHub repository I think if you Google for example on there, we have over 90 samples for the different frameworks If you're into Java, there's a number of different Java libraries. You can use A lot.net has more code libraries and languages There's also all servers. So if you wanted to just have a server at your company and didn't want to pay someone You could use something like key cloak or apparel or Hydra to actually, you know, just manage it locally So in Jay hipster, which is a project that I work on that generates a Java back end and an angular front end We use key cloak in a docker container Because as a developer you can just run it right away and it pre-populates it with all the client Registrations and stuff like that and everything works out of the box You can switch the octa, but if you switch the octa you have to go and like register your app Right and create a client and stuff like that So additional resources a lot that net is where the spec is You'll notice down here supported by us zero and octa. So it's not, you know To one or the other but a lot calm Has our branding all over right first of all because we paid Aaron in the beginning be like hey Can you throw a logo on there like we'll finally use some money now that we hired him like, you know He's all over making that he's got to solve with octa button there now. So I Just want to make sure you know that if you're on dot net, you know, that's vendor neutral from calm Might be coming to our stuff, but the cool thing is calm is actually this book So you don't need to pay $40 for this book if you don't want you go to calm and it's got all the chapters You can read them through there and I guess you could print them off if you want, but it might be a weird book So developer doctor comm slash blog we do all kinds of tutorials on how to implement Authentication in your apps if you want to see when we publish them. We're on octa dev on Twitter anyone else on Twitter Anyone on email? If you want to you know register and sign up for an account developer doctor calm I also like to mention that my friend Nate Barbatini has one of the coolest videos That's similar to this he tries to break it down in plain English And I've done my best to kind of copy his because his is so good that it's got over 83,000 views on YouTube and 227 comments that are all nice Often does that happen right so I'm hoping by recording this we have some sort of inception thing going where I'm recommending a video during a video The other thing I want to mention is just local user groups So the Denver Java user group is really strong community over 3,000 developers We get about a hundred that show up to each meeting if you have developer friends We want to send them to that Denver microservices Denver open source. We sponsor a couple of those So if you want to sponsor maybe we could sponsor this one What we do at Denver Java user group if we have beer before during and after So we have sponsors for all three of them works out well So if you have any more questions you can get in touch with me on my website It used to be like a tech blog now It's kind of like where Trish and I went on vacation and every once in a while I'll post something technical But I do a lot of that on developer dot octa.com now. I'm on Twitter I'll post this to speaker deck probably tonight or tomorrow morning all the code I write these days is on octa developer there's me and the kids in hefe and May the off be with you What's that? You're only the second one to notice that So I've been around the world and I've had that in there for so many times and people are like But I promise we weren't there buying anything the story is that we had just picked half a up It was that day, right? I've been waiting for ten years to pick him up and you know, he was low on gas So we stopped to buy gas. I thought it was kind of funny that you know as the gas station and wheat store and And we leave here and we pull up to the next light and some guy runs up behind me to my window And he's like man, you're leaking oil like a son of a gun, right? And I'm like what and so we jump out and sure enough it's leaking oil all over right So we turn the engine off They're in a Volkswagen 2 and they helped me like push it off the road. We started up. We drive a little more We're like not smoking too much. There's a real problem, right? We just got it that day So I had to speak that night Trish was nice enough to actually take the bus wait for the tow truck Take it back to the shop and then like meet us after she missed my whole talk guess what the problem was Too much oil That was it like it took him a week to be like well, we took tomorrow out and it works fine But at that point you can imagine my frustration I was like super happy and then five minutes later I was like saddest guy ever so Made off be with you. Let's go have some drinks