OAuth 2.0 - Refresh Token

This video explains the main use case for refresh_token. In also touches on user session management in the context of OAuth.
The video is too short to explain all aspects but the viewer should get a good idea how these token work and what effect different types of expirations have.

To find more information checkout these web sites and RFCs
- RFC 6749 (OAuth 2.0)
- RFC 7009 (Revocation)

You can also check my book "API Development - A Practical Guide for Business Implementation Success" which is available via Apress or Amazon for a broader picture on api development.

If this video was helpful to you, please consider buying me a coffee:

[prafulsinghvit]

Wow, such a nice and crisp explanation, please continue making such videos. I strongly believe everyone who watched it definitely liked it a lot.

[mohdt]

Amazing video Sascha! Very crisp explanation. Thank you!

[sachinrane]

you are gem. your description is awesome.really appreaciate

[thevipinchand]

Great explanation. I got a better understanding of auth from this content.

[TheAmeer]

Guys can we get a like on the video? He takes the time to make this clear video and we have over 1k views. Let's show some support . One love

[alex_chugaev]

Reeeeally helpful video, thank you and take care 👍

[mbssystems]

I would be interested in setting up a fixed RefreshToken. As in case we've a sliding window, it is a never ending case, as long as somebody frequently uses the RefreshToken. All the time the RefreshToken Expiry time will again start from scratch. So where can we configure the hard fixed expiration limits? Thx.

[AjayGupta-jssl]

If the user is using the client app and for some reason he keeps the laptop on sleep mode keeping the tab open on the browser so now when the user is back online does the user needs to authorize again by logging in or the user can continue accessing it smoothly without any hassle of logging in again into the application

[enriquesierragutierrez]

thanks Sascha, very clearly explained!

[yotubecreators]

thanks for the video.
I would like to share my understanding of your video and many online resources of why we can't just use access token as refresh token ?
There is scalability reason and there is a security reason.
Scalability reason: access token can be verified by resource server without DB lookup or central server (just need place to get the public key) usually good for 1 hour, can be used with any resource server, highlight third party resource server could have log leaks, weak security etc.. this not the authorization-server

The security reason: refresh_token is only ever exchanged with authorization server which is one issuing authorization and more secure, refresh-token can live forever but access token canno't that's why we must have 2.

This mitigates the risk of a long-lived access_token leaking, making access token good-til-revoked without refresh token

[TheVincent]

What is the use of fixed lifetime? Why not using the original access token instead, or do I misunderstand the principle of the access (and refresh) token?

[rizadwiandhika]

why do we need refresh token? if basically refresh token can be exchanged for access token, why don't we just make the access token to lives longer?

some people say that longer lives of access token is not recommended because when the token is stolen and it is still active, the attacker can use the token (and therefore we shortened the access token lifetime).

but refresh token can also be stolen right 🤷‍♂?

[AjayGupta-kkef]

Is kong entirely responsible to take care of refreshing the access token when the refresh token has not expired if yes then how? or do we need to hit some apis from our end to ask for new access token from the Kong

[upatthefarm]

Thank you very much for this informative video! -

[newbieuserguy]

I'm confused by the word "may". For example, at 12:22, the words "refresh_token may be one time use only" are on the screen. In that context, does the word "may" indicate certainty or possibility? Perhaps the word "might" would be clearer. We commonly use "may not" to indicate certainty. We use "might not" to indicate uncertainty. The English language is imprecise here. I guess that you are saying "might be", as in "sometimes, it will be 'X' and sometimes 'not X'." But I'm just guessing.

[vipulgoriya]

Suppose expire time of refresh token is 1 month and someone can close the app and open the app after 2 month so in that case both token expired so what are the way to handle that situations?

[prashanthbp]

In the sliding window implementation of refresh tokens, is it necessary to "authenticate" every time before generating the refresh token ? How can this be automated to generate the refresh token as that the end user experience is seamless?

[daniyartursunov]

I have a message "Expired token" when trying to clear the cart and when I try to add items to the cart. After I redeploy the website it works fine for couple of days, and then crashes with that message. What's the solution? Do I need to add JWT to my project?

[jonathanlevin]

I dont understand the point of refresh tokens from a security standpoint though.

If the original exchange is intercepted (say via a MitM)- the attacker has both tokens.

If the access token is intercepted by a MitM later, cant the attacker return an 'expired' response, forcing the user to send the refresh token, so its moot anyway?

In what situation does a refresh token enhance security against a skilled attacker?

[jasonbuenaventura]

Also, when you were discussing refresh token revocation for self-encoded jwt, at around 9:57, you mentioned about the access token being sent to the token store for validation. But I thought the token store only contains (a blacklist of) refresh tokens