Understanding How OAuth2 Works

what's going on engineers and it's may already be looking at the oauth2 authorization framework and specifically why it exists and how it works in the big picture the whole purpose of oauth2 is to allow you as a user of say website a to allow access to website B to access your data on website a bow off to is often confused with something like a standard API key and the reasons confusion is made is because they're almost used in the same way but with one small distinction if you're already a user of say website a and you want to access your data programmatically then it's common to use something like an API key however if another service wants to access your information then that service would use OAuth 2 to get your authorization to do so from a user standpoint implementation of OAuth 2 can be seen on the engineer man knowledge center for instance in this case as the operator B MKC I'm offering the ability for users to log in via discord so me as a user I'm saying I would like to log into e MKC via discord and I do so by clicking log in with discord one important thing about OAuth 2 is the service that wants my information in this case engineer main knowledge center must say upfront exactly the scope of the data they'd like to request and the users flowing control the user can see right here this will allow engineer main knowledge center to access your user name and avatar and access your email address a little bit later in the video I'll show you exactly what I did to make it access that exact information once the user is satisfied they can click authorize in which case they've told engineer main knowledge center that they are now authorized to request from discord that information name user name and email address we can see now that the login button has been replaced with my profile picture which shows that I am now logged into the site it's not you've seen at a high level how it works let's look into the actual technical specifics of how it works and I've actually written some code that does know OAuth 2 flow and will definitely look at that as well for context I'll be using engineer main Knowledge Center for all these examples so in this chart client is going to be a MKC and then the resource owner authorization server and resource server are all going to be discord keep in mind the auth to flow is usually between website a and website be the only role the user plays is just to say yes that's okay I authorized them to do that the first step is the authorization request this is when I actually click log in and it sends me over to discord this authorization request code Y is nothing more than just sending a user to especially crafted URL besides the base URL which is of course discord it's going to contain a couple other pieces of information that tell discord what it should do the client ID is supplied to tell discord what application is actually try and request the information the redirect URI exists because once discord is done doing the authorization it needs to know where it should send the information back to response type is saying I would like a code back and then the scope is saying what actual data the service would like to access in this case it's identify and email now there's no standard list of scopes any service that offers up Oh off to protocol can specify what scopes they want to offer and then what data is associated with those scopes the second step is the user will either click authorize or the click cancel if they click cancel then a message will be sent back to that callback saying hey there's an error for whatever reason either the user cancel or there's a problem with the server but if they grant it then a code is sent back to that callback so step two is going to be redirecting the user back to this URL at the completion of either the authorization or if they cancel the third step is going to be taking that authorization grant which in this case is a code and sending it to the authorization server weep in mind that the code that comes back from the grant is not enough to access the user data the code is only good to trade up for an access token which can then be used to access the users data the code will come back in the query string and then that can be used to make a call a simple HTTP request to disk or its authorization server to get an access token there's six piece of information that gets sent over and three of them were in the original thing we already sent the client ID we sent the redirect URI and we sent the scope already the three new things is the actual code the client secret and the grant type the code of course is the code that's whatever came back from the authorization step the client secret is going to be a secret string of characters that relates that client ID that's within the application that way they know that you are authorized to actually make this access token request then the grant type is going to be the type of code you're providing in this case it's an authorization code the fourth step here is the authorization server gives you an access token back and there's no real reason why this wouldn't succeed unless the code is revoked or it's just old the fifth step is to use our newly acquired access token and make authenticated API calls to a resource server in this case we're making a call to slash user slash meet and we're supplying the access token that we got from the previous step now keep in mind that discard is going to check that access token to see what it's allowed to access so if I try to use it to access data that the user did not authorize me to have then this Court's going to reject that request furthermore the access token is a temporary thing it doesn't last forever I can't use it a month from now in the case of discord I think it's good for seven days but it's configurable per service now if your service whatever reason requires prolong access to user data you will get back what's called a refresh token at the same time you get the access token refresh tokens typically never expire but you are required to store it somewhere that way you can use it and that will let you get a fresh access token the reason access tokens have to expire and refresh tokens don't is because access tokens alone are enough to access user data refresh tokens aren't able to access user data directly you would still need to pass your client ID your and your client secret which of course is secret and so you know people wouldn't have your client secret and therefore couldn't exchange through fresh token for an access token even if they had it and then step six of course is the user data comes back to your service and you're able to do what you like with it in the case of emk C it matches the discard unique ID back with the unique discard idea it's an e MKC and it logs that person in there's tons of libraries out there in various languages that will do the oauth2 flow for you but it's sort of pointless given that you can accomplish the entire thing in roughly 60 lines of code and just to review of the steps again the user will authorize access to their data which in return you'll get a code you can take that code and you can exchange it up for an access token then you can use that access token to make authenticated requests for the users data it really is that simple and that's it for the video you definitely want to get familiar with - because it is the standard way to authorize third-party services to access your data on another side if you have any questions or comments about anything you saw in this video please feel free to leave them below in the comments or and that hope to see you in the next video take care

Channel: Engineer Man

Views: 41,168

Keywords:

Id: j-bHvqQ378s

Length: 6min 51sec (411 seconds)

Published: Sun Dec 08 2019