Authorization Code Grant Type

In this video we are going to look at the Authorization Code grant type.

This is likely the flow that you are most familiar with when thinking about OAuth2.

This flow is also the most visual of the core grant types. A really great way of seeing this grant type in action is to check out this link.

Let's pretend we have a mobile app. We want our mobile app to allow our users to sign in to our service, but if they don't want to go through the hastle of creating yet more username and password combos to remember, we would like to allow them in using their Facebook credentials.

Well, if you implement this grant type, you would become the Facebook in that situation.

Depending on your situation, this may likely be overkill. Useful if you want to open up your API to third parties, but the password grant type with proxy is likely a better fit if not.

Auth Code

Unlike the password or client_credentials grant types, as part of this flow we will initially end up with an AuthCode (Authorisation Code) which we will then need to exchange for an Access Token.

Also, unlike the password or client_credentials grant types, we will send our initial request to a different end-point:

http://rest_oauth2.dev/app_dev.php/oauth/v2/auth

Again, in the real world, this should be HTTPS.

We are going to do a GET request in this instance.

We will end up with the end-point and associated query string looking something like:

http://rest_oauth2.dev/app_dev.php/oauth/v2/auth?client_id=1_aaa&response_type=code&redirect_uri=http://your.site/whatever.php

If you're wondering why the response_type is set to code, then be sure to consult the RFC.

If you've been following along using Postman, at this stage, if your redirect_uri is like mine - not real - then you will get an error as Postman can't successfully redirect. At this stage, we must switch to a real browser if we want to see what would really happen. Note though, that even though Postman doesn't handle this particularly well, the AuthCode table will still be populated properly. In other words, it's Postman at 'fault' here, not our OAuth Server.

As such, we need to take the long URI that Postman has built for us and drop the entire string into a proper browser.

When we hit go on that, we should be subsequently redirected to our specified redirect_uri, and the generated AuthCode will have been appended to the URI.

site.local?code=XVXVZDsfsafaSDFas32987sfsdfSDAF23FGD (etc)

If we go and look in our database now, the AuthCode table should have two entries - the first one we did using Postman, and then this new one we carried out in the browser.

The slight problem is, the generated AuthCode will only last a very short amount of time before it expires and you will need to request a new one.

You have two options here, either be very quick with your copy/pasting, or the lazy way, simply change the expiry timestamp using a database tool like SequelPro or SQLYog.

For Sale: AuthCode, 1 Careful Owner, Will Swap For Access Token

Once we have successfully received an AuthCode we can then immediately exchange it for an Access Token.

We do this by making a POST request to the Token end-point:

http://rest_oauth2.dev/app_dev.php/oauth/v2/token

Passing in the client_id and client_secret as before, a grant_type of authorization_code, the redirect_uri which must match with one of the Redirect URI's we configured for our Client, and lastly the code which takes our recently received AuthCode as its value.

If all goes well, we receive back the access_token and refresh_token in a manner very similar to that which we saw in the client_credentials grant type.

However, if you are doing this manually / by hand, and you aren't quick enough, you will see a message saying that the AuthCode has expired. If so, generate a new one and if you're quick enough, all will be good :)