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.
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
client_credentials grant types, we will send our initial request to a different end-point:
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:
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.
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.
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:
Passing in the
client_secret as before, a
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
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 :)
If you have found this video helpful, please consider sharing. I really appreciate it.
|1||Installing FOS User Bundle - That is not a typo!||07:52|
|2||4 Key OAuth2 Terms You Need To Know||06:46|
|3||Creating and Using Our First OAuth2 Client||05:41|
|4||How Our OAuth2 Tokens Are Created||06:58|
|5||Client Credentials and Password Grant Types||07:43|
|6||Authorization Code Grant Type||04:17|
|8||Scope and FOSOAuthServerBundle||08:12|