Refresh Tokens

This video is available to view for members only.

Click here to Join!

Already a member?


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 grant_type of 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.

A Lifetime Of Fun

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.

Using Our Refresh Token

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_id and 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.

Clean Up

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.

Code For This Course

Get the code for this course.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.

Episodes in this series

# Title Duration
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
7 Refresh Tokens 03:07
8 Scope and FOSOAuthServerBundle 08:12