In this video we are going to look at how we can exchange an existing Refresh Token for a new Access Token.
You may not always get a Refresh Token, but if you do, you will always receive it at the same time you are given your Access Token.
If you didn't receive a Refresh Token at the time your got your Access Token, then this work flow cannot be used.
Most frequently you will see the Refresh Token in conjunction with the Authorisation Code grant type.
Much like in the Authorisation Code grant type video, we can see the Refresh Token workflow in action more visually by checking out this link.
Whilst shortly you will see we specify a
refresh_token, the Refresh Token grant type cannot be used without first having received an Access Token, therefore it is not one of the four listed Grants in RFC 6749.
By default, FOS OAuth Server Bundle will issue Access Tokens with a lifetime of 3600 seconds (one hour). We can change this in the Bundle configuration, as we will see in a moment. After 3600 seconds, our Access Token will have expired, and we will need to either go back through the original workflow to generate a new Access Token, or we can skip that, and simply use the Refresh Token.
Interestingly, by default our Refresh Token lifetime is 1209600 seconds, or 14 days. This means we can use our Refresh Token for up to two weeks after our current Access Token expired.
To change either of these values - and many more settings - be sure to check out the FOSOAuthServerBundle Configuration Reference.
If any of that seems uncertain at this stage, this is demonstrated in the video from the 1:30 mark onwards.
To use the Refresh Token is very straightforward.
We need to POST our
refresh_token string, along with a few other parameters, to the Token end-point:
As in the Authorisation Code grant type we would pass in the
client_secret, a grant_type of
refresh_token, and somewhat confusingly, a
refresh_token which takes the value of our long Refresh Token string.
As soon as we submit that, assuming all our values are good, we will get a very similar output to the Authorisation Code grant type response.
We don't need to wait for our
access_token to expire before going back through this process.
When we go through the Refresh Token process, FOSOAuthServerBundle will helpfully remove our used
RefreshToken entities from our database.
However, FOSOAuthServerBundle won't go ahead and remove any
AccessToken entities directly, so you can end up with multiple entries in your
AccessToken entity database table. But don't worry, cleaning them up is easy enough as we will see later.
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|