Understanding Google OAuth 2.0 with curl

this is linda again and welcome back to my channel you may have seen this image previously this is the standard oauth image that google's documentation normally displays when i first started working with google's oauth servers i had a lot of issues with understanding exactly how oauth worked and actually what this image stood for what i thought we'd do today is go over how oauth works well specifically how google's oauth works some of the oauth calls are actually http posts which means that to show you how to do it we actually have to make post calls so i thought the easiest way to go about that would be to use curl using curl we can make all of the authorization calls that we need and i can show you how it all works because curl in this case is intended to be run on a server then what we will need to do is to create a client up on google cloud console for an installed application i'm not going to walk you through how to do that because i've done it in several of my other videos but i'll link one here and you can go and see how to do it i will be enabling the google analytics api because i wanted to run this with the google analytics api so just remember to enable whichever api you intend to use it for and to substitute the proper scopes but we'll get to all that shortly i went ahead and color coded google's standard oauth image here just to make things a little easier so that we can step through the image so i can explain to you how the image works and where each call comes into play with the image oauth is actually split up into three different calls well technically four calls if you want to include refreshing the access token so as a bonus i'm going to show you how to refresh the access token at the end of this so if we look at the image you'll notice that your application is in this yellow color and google servers are in green the first thing that happens is that the user will log into your application or arrive at your application in some way then your application needs to access google's data so it will display a consent screen over on google server assuming that the user grants your application consent then the authorization server will display an authorization code in the browser window itself your application is then responsible for grabbing that from the response so that was step one of the oauth dance present a consent screen to the user the user authorizes it and an authorization code is returned to your application that's it that's step one so let's start let's look at how do we get the authorization server to display this consent screen because like i said the consent screen is displayed on the authorization server this is not something that you have any control over so if you want to change the color on it you can't and yes i've seen people ask how to change the color on the consent screen the consent screen is actually a http get call which means that you can place this link in any browser window which is actually what it's intended to be for and if you watch me run it now you'll see that it prompts me to consent to authorize it and it returns back the authorization code which i mentioned so let's look at how this call is actually built up the endpoints that are used by the authorization server can be found in what's called the disco dock or the discovery dock all authorization servers have one of these it's a standard document that they have in order to give us all of the endpoints that we need to access them if you're interested i'll put a link to google's discovery doc in the documentation section below so the very first parameter which i'm going to be sending is called client id this client id came from the client credentials which i downloaded off of google cloud console the second parameter that i'm sending is the redirect uri you'll notice that the redirect uri isn't a standard uri this uri is actually kind of special it tells the authorization server to return the authorization code directly in the browser window and the title bar of the browser if you had a web application it would return it to the redirect uri that was configured for your web application but in our case we're using installed one so we just want it to return in the window the next parameter that i'm sending is the scope scopes are used to define the level of authorization that your application needs to request of the user in order for it to run in our case i want to be able to access my google analytics data so i am going to request the analytics read-only scope because technically this api that i'm accessing only has read-only endpoint it doesn't have a right endpoint the final parameter in this call is called response type this is a required parameter to tell the authorization server what i am expecting as a response in our case we are expecting it to return us an authorization code so for response type i am just sending code so that the server will return an authorization code to me well that's it that was step one pretty painless isn't it it's just an http get request so you can put it in any browser and all you need to do is pass it your client id redirect uri scope and remember the response type needs to be code and that's it you've got a consent screen to display to your user well that's it time to move on let's have a look at step two why don't we back to the image again shall we so we've covered the part where the user is displayed a consent screen and the authorization code is now returned to us but the authorization code can't actually be used for anything and what you should know is that authorization codes are very limited time frame i'm talking between two and five minutes if you don't use it it's going to expire very quickly and another thing you should know about the authorization code is not only does it expire within two to five minutes you can only use it once so there is no reason to be storing this in your database anywhere so what are we going to do now well step two is actually exchanging the authorization code for an access token and a refresh token so now things are getting really interesting the call to exchange the authorization code is actually a http post which means for this call i'm going to use curl so let's have a look at this call the first thing i'm going to do is call curl and i'm going to tell it that this request is a post once that is done i'm going to tell it that i have a lot of post data for it the post data you will notice is not in json it is actually in the format of an http request string so each of the parameters is separated by the and sign the post data is actually five separate variables the first one is code this is the actual authorization code which we got from step one the next two are client id and client secret these come from the project on google developer console which we created earlier you can consider the client id and client secret are basically the login and password for your project access tokens and refresh tokens are created based upon the client id and client secret which means when you try and refresh them they won't work unless you use them with the same client id in client secret now we have the redirect uri again in this case the special redirect uri is going to tell the authorization server just to return the response back exactly where it came from so curl is going to send a request and it's going to get the response right back like it normally would now this time instead of a response type we are actually sending a grant type and we're sending it the grant type of authorization code because we have been granted an authorization code and then finally we are sending all of this to the token endpoint and the token endpoint i got again out of the discovery document so let's have a look at that image again we got an authorization code back from the server we send the authorization code back to google server and now google server should be returning to us an access token and a refresh token so let's have a look at the response that the server is returning so the authorization server is returning us a json object which contains an axis token the access token is the token that we can use to make all calls to the api then it returns also expires in this is because access tokens are only valid for one hour it also returns to us a refresh token we can use a refresh token to refresh the access token this is technically not part of the normal three-legged oauth dance it's an extra step it also tells us what scopes this authorization token was granted and it tells us that it is a bearer token a bearer token means that the bearer of the token is granted access that means that anybody that has access to this access token has access to the data there's no further authorization with an a bearer token they are considered secure because of the fact that they are valid for a limited time if somebody got a hold of an access token and could use it they would only be able to use it for about an hour before it would expire that's why bearer tokens are assumed to be secure but that doesn't mean that you should be going and handing out your access tokens all over the place you should be keeping them as secure as possible okay let's have a look at that image again so user logs into our application we display them the consent screen on the oauth server the user grants our access and the or server gives us an authorization code we then take that authorization code and we exchange it with the client id and client secret on the server for an access token and a refresh token so that's pretty much it we have an access token a refresh token now we technically have access so what do we do with that access well let's have a look at how to use that access token so now we have an access token well what are we going to do with it in my case i'm going to try and make a call against the google analytics api so when i call the google analytics api i need to pass it the access token but how do we pass it well you actually pass it as an authorization header of type bearer so if we look at this call i'm telling curl that i'm making an http post call that my content type is jason and that i will be accepting jason and i'm also sending it an authorization header of type bearer with the access token that i got back from our previous call i'm also sending the post data that the call needs and i'm sending the call to the google analytics data api endpoint like i said it doesn't matter which api you're accessing here as long as you know the endpoint for the api you're passing it the proper parameters that it requires all you have to do is add an authorization header with your access token and that will grant you access to the endpoint so remember what i said your access token is only good for an hour so your access token is expired what are you going to do now well now you're going to use your refresh token to request a new one the call to refresh an access token is also an http post call similar to the previous http post the first parameter i am going to send as part of the post data is the refresh token this is the refresh token that we got back from the call where we exchange our authorization code for the most part refresh tokens should not expire there are some cases which will cause them to expire but for the most part you should be safe for storing your refresh token and you'll be able to use it at a later date then i'm going to send the client id and client secret again remember that i mentioned that these are technically the login in password pair for your project on google cloud console you need to send the client id and client secret in order to refresh the access token and they must be the pair that was used to create the refresh token originally this time we are going to be sending a grant type of refresh token because the grant we are sending to the authorization server is the refresh token and that's it we send that to the server and the server will return to us a new access token you might want to note that we did not get a new refresh token back we just got a new access token well i think that's it for now i hope this video helped you understand how the authorization flow actually works and the fact that there's really no magic behind it it's just three steps that you need to follow and you will be able to get an access token back doing this with curl can be quite useful if you want to for example have a cron job set up to i don't know upload files to google drive you could do that i've also seen it done where it would check email systems and reapply labels to emails so there's quite a few uses for curl with the google apis well that's it for now i hope you enjoyed this video and i hope you consider giving it a like and sharing it and subscribing it really helps me to know that you've enjoyed the content that i am putting so much time into

Channel: DAIMTO Developer Tips

Views: 2,363

Rating: 4.8048782 out of 5

Keywords: Daimto, oauth 2.0 explained, oauth 2.0 grant types, oauth 2.0 google api, google oauth 2.0 tutorial, google oauth 2.0 tutorial curl, google oauth 2.0 curl, oauth2 google api, oauth, oauth curl, bearer token, what is a bearer token, google api tutorial, google oauth2, google api, google oauth setup, oauth2 jwt, how to use google oauth2, google oauth, google oauth curl

Id: hBC_tVJIx5w

Length: 17min 2sec (1022 seconds)

Published: Thu May 06 2021