What is a Refresh Token and why your REST API needs it?

[@jimbo-dev]

Thanks for explaining the concept without need for specific environment! I'm going to implement this using golang, but it was surprisingly difficult to find this kind of explanation

[@Ken-xr2xp]

The best explanation of this architecture hands-down. Thank you!

[@coding-with-cody]

i agree

[@mtvmango5172]

Why wouldn't a men in the middle attack get both token and can impersonate for 12 months?

[@thomasthaler7669]

Because the refresh token is only sent on one specific call whereas the access token is sent on every call ☺️ the attack surface is very small. Of course, if an attacker manages to get a refresh token the only way to block him out is invalidating the refresh token in the database

[@gamemusicmeltingpot2192]

@@thomasthaler7669 but if your network is unsecure anyway, then the men in the middle would just be stealing your new access token so whats the point?

[@emloq]

@@gamemusicmeltingpot2192 So dont use authentication then?, whats YOUR point? That's user's responsability to not use unsecure networks

[@gamemusicmeltingpot2192]

@@emloq like I said what's the point of using another token if the network itself is compromised. But never mind, since I have done the research after I posted that comment I have figured out the answers I needed

[@amwolfox]

@@gamemusicmeltingpot2192 hi can u explain the soln u found pl

[@yotubecreators47]

"There is a scalability reason, in that the access_token could be verifiable on the resource server without DB lookup or a call out to a central server, then the refresh token serves as the means for revoking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked." There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc) in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token." From Kris

[@imyounick]

1.If your Refresh token and access token both are stolen, then attacker can access your resources by getting new access token every time it get expires til that same Refresh token is not deleted/expired from database. 2.Refresh token does not make your api secure, it helps to get a new access token when a old one expires thats it. 3.Refresh token, just need to make sure it doesn't get stolen from app (Use Http secure cookie only). 4. Implementing Auth without Refresh tokens will lead to change of credentials for Users once access token is stolen. (This wont work because you cannot tell ur users "Oh your token is stolen please change password")

[@gto433]

The question is what if refresh tokens get stolen?

[@coding-with-cody]

you can add a flag in your token to make sure your user revalidates their token via email before doing anything sensitive like making a purchase.... the original token issued is set to 1. once the token is refreshed you will set the flag to 0. if the user tries to buy something with a token that has a 0 flag, you will make them revalidate with a fresh token from email.

[@YarivGilad]

Hi nick, thank you for this video. it helps a lot, though one point keeps bothering me - How can you prevent someone from grabbing the refresh-token? If someone can grab the 'regular' token, which let's say expires every 5 minutes, he can just as easily grab the refresh token when the client asks to renew it, no?

[@nickchapsas]

Not quite. You see, the call itself to the endpoint should be encrypted through https anyway. The risk of the man in the middle is is small but of-course possible. The thing you have to be careful with refresh token is how you store them locally. As long as you are diligent on that, the chances of someone getting access to the refresh token are small. For example the JWT could be stored in a cookie. The refresh token should never be there. In this case cookie attack is what could steal the token and the refresh token if they are both stored in cookies.

[@chineduekeneokpala3407]

@@nickchapsas where then should it be stored?

[@mojekonto9287]

@@chineduekeneokpala3407 in LocalStorage or in the SessionStorage depending on the needs

[@enonz761]

@@mojekonto9287 Local storage is inherently no more secure than using cookies.

[@mojekonto9287]

@@enonz761 when you store the refresh token in the cookie then it will fly in every request.. you don't want that of course. Another thing is that whatever you keep in local or session storage will only be sent in the request when your application explicitly adds it to the request. No other app in another tab will have access to your app's storage. What you stated, therefore, in this regard, is not true to me. If i am mistaken, let me know ;)

[@minhthangngo4431]

very thanks for your explanation

[@WonderBoyPreethvi]

If hacker can get access token he also can get refresh token, and by using refresh token he can get new access token, so whats the point

[@berkanbilgin2287]

In the 2:20 you say “MITM will only have an access to token for 5 mins” but then on 3:25 you were mentioning that valid but expired token will be used to get a refresh token.. so doesnt this make the tokens never expire? Because it lets you to get a refreshed token even though it is expired, so the MITM can continue to making requests, not just for 5 minutes. Can’t he?

[@mojekonto9287]

The MITM would have to intercept both the jwt token and the refresh token and then be faster than the legitimate user in providing the combination of the then expired jwt token and the refresh token to get a new a pair.

[@yomer355]

@@mojekonto9287 what if he did that?

[@torrvic1156]

Thank you Nick! That was a pretty clear explanation.

[@kalideb-y3y]

refresh token is a false sense of security

[@torrvic1156]

@@kalideb-y3y not arguing but it’s better than nothing.

[@MaheshKumar-bg5re]

If you have an expired access token, it can be renewed with refresh token.. What is the use in it? Why can't you just give an access token with long life? You are simply refreshing it without any conditions with refresh tokens... I am confused and i really don't know how to implement this concept..

[@lula4148]

If you give an access token with a long life, then if that token is compromised, whoever has it will have access to your API for a very long time.

[@rabiisissi2911]

tHAT wAS sO HELPFUL , tHANKS

[@naveedalirehmani4135]

why are we assuming that a hacker can have access to access_token and not refresh_token?

[@kalideb-y3y]

that's also what I'm thinking the guy on the video assume that a refresh token will not a target for a hacker 😂 refresh token is pointless

[@mrlqchen]

I think its more accurate to call "JWT" from your diagram as "Access token". JWT is just the format of the token, its not a token type.

[@nickchapsas]

I don’t really agree with that. JWT is a specific type of token following the JWT standard. If it was just a format then and 3 Base64 strings separated by dots would be a JWT but that’s not really the case.

[@mrlqchen]

Nick Chapsas The purpose of the token is for access and hence the name access token. In this case the access token is in JWT standard. No?

[@nickchapsas]

I never disagreed with that you just said. I said that it's totally fine to call it a token type and also an access token following the JWT standard. They are both correct in my opinion. That's not necessarily correct is that in the diagram I specifically use JWT as my token type but instead of JWT i should simply write, "Access Token".

[@mrlqchen]

Nick Chapsas JWT is a token standard. It can be used for Access token as well as other types of tokens such as ID token. In your example, the token is specifically an access token, hence my view that calling it an Access token is more appropriate.

[@et4493]

Very well explained, thanks

[@kapilchauhan7954]

You deserves a suscribe👍

[@PreparingGeneeskunde]

Where is the next video? There is no link in the description. By the way, thank you for your great explanation sir.

[@HoleyMoleyAlex]

I think this is it: kzbin.info/www/bejne/d4aThXyFj816p9U

[@sam_patrik]

Please can anyone tell me here 2:15 . what if the refresh token is also stolen along with jwt, then attackers will be able to generate new tokens very easily, please explain me then how refresh token will help me? Maybe I am missing something that I don't understand, but here refresh token as serious flow , please someone explain me

[@nickchapsas]

Since the token is stored in the local storage of the browser it is not prone to some sort of attack that can retrieve it. Also, if you’re using https, a man in the middle shouldn’t be able to access the request contents.

[@sam_patrik]

@@nickchapsas just for sake of simplicity,let say we are not using https for some reason Then what's the point for refresh token? If it will grant me longer access anyways It's whether http or https, If hacker/attacker somehow manage to obtain the refresh token, then he will go home, will set token manually in his browser, and walah Here I'm not trying to say that what you are trying to teach is wrong or spreading misleading information, I also learnt same thing when in my training But there is security concern, and I know that security is hard I may not experienced Developer as you are, but in my work experience I tried to improve the security by adding more information like device name and operating system name, etc But I'm still not satisfied, I hope there must be a way to ensure that stored informations in the browser is not hampered by users at client side or by the attackers

[@ishanmahajan2004]

Nice explanation, thanks

[@nickwoodward819]

How does this stop a compromised JWT from being refreshed?

[@nickchapsas]

By requiring a refresh token as well to refresh it

[@nickwoodward819]

@@nickchapsas But if I've access to your JWT why wouldn't I have access to your refresh token?

[@nickchapsas]

Well they would both be stored in the local storage of your browser. The danger is around man in the middle attacks when you have your jwt in the cookie or the header to authenticate/authorize yourself. The only scenario where you are fully exposed is if you have a man in the middle in a non SSL request when you are refreshing the token.

[@nickwoodward819]

​@@nickchapsas Was more concerned about an XSS attack? Surely you should be pretty good with a JWT and HTTPS?

[@nickchapsas]

Sure but that means you would need a long lived JWT. How would you have a short lived (5-10 minutes) JWT and also be able to refresh that without a login screen or a refresh token?

[@tula1308]

how can I handle when my user JWT refresh token is hacked

[@TheAmeer3881]

Amazing content great work

[@Hicham_SaAh]

thank you again and again

[@sagar140]

how to manage refresh_tokens for multiple devices of same user ?

[@Immerz]

Nice, I can see how this would work for changing passwords, but it's likely an attacker can also access the refresh token if he manages to get the jwt right?

[@fabscs-wy3hp]

The Hacker can steal your token and only be able to use it for 5 to 10 minutes. But what if the same hacker uses the Auth API again and again. If he can get a new token every time he hits the AUTH API How is it secure ?

[@kaushlendrakumarkaushal5807]

Super explanation in small video ......Thanks

[@ly4998]

best explanation!

[@coding-with-cody]

for anyone concerned about man in the middle, a common technique is to put a flag in your token that is set to 0 any time the token is refreshed. it is only set to 1 after the user has pulled it from their email. if a user does anything sensitive (like try to make a purchase) you can make then retrieve a fresh token from their email before proceeding.

[@codedusting]

???

[@coding-with-cody]

@codedusting u gonna have to ask a more specific question that this ... I'd recommend posting what I typed into chat gpt and let it explain to you as well

[@testtest-c4z]

Hello, how about a query, when you have a token and refresh token where, for example, I have an app that sends or queries orders to another system, the token and refresh is always stored in the client, when this can be more than one client or is stored in the server in a database and query on that? taking into account that my app always has a single user to make the requests regardless of which user is requesting the data. thank you

[@wahyunurarizky3860]

thankyou Nick

[@kalideb-y3y]

I have been searching for what the point of refresh token and I have read a lot of articles and answers but I still can't understand what's the point of it , I still have questions🙂. The refresh token is still stored on the client's same as access token so how is that safer from attack?

[@linerunner88]

How often does the refresh token expire?

[@quangnvn]

So we have to store refresh token in both server side and client side, when client making a request we check the jwt, if it expire, than we check refresh token, if it not expire, than we use the refresh token to call /refresh api get new jwt, than we use the new jwt to recall a request, is that correct, and this the best solution? Thanks

[@nickchapsas]

Not exactly. On login you get a jwt and a refresh token. The refresh token is stored by both server and client and it’s put on the side for now. The jwt is only stored by the client and it’s sent as the auth header for any other requests. At this point there are two things you can do. 1: before you send any request check the expiration token on the jwt you’re about to send. If it’s in the past then use the stored refresh token and the jwt against the /refresh endpoint to get a new pair 2: don’t check if the jwt has expired and if the server replies with unauthorised then take your stored refresh token and try to refresh your jwt. If it succeed make the same call again. If not then fail the request

[@jackofalltrades8212]

@@nickchapsas I would suggest 2 is the only way to go. Also, if the refresh token auth fails, generally you would ask the user to log in again at that point. That would generate the new refresh and access token. This also allows a bad user who somehow has the refresh token.. if it were invalidated on the server side.. to be forced to log in and likely fail the username/password login and not be able to make more API calls.

[@mazonnozam]

@@nickchapsas when the client needs to use the /refresh endpoint, why does the client need to send the refresh token AND the access token? Isn't it enough to send just the refresh token? What additional security or authentication does sending the expired access token provide?

[@ivoriankoua3916]

@@mazonnozam They are stored on the server as a Map (Key/Value) so this way the server would check if the combination you send is a valid one and then change the access JWT , if the pair isn't valid , you would get an Unauthorized response and have to login with user/password to get a new pair.

[@biliyonnet]

Expiration is not a big deal with JWT. They can contains expiration date. So the endpoints can easily check the JWT is expired or not without any db request. The main problem with JWT is invalidating them suddenly (before they're expired). In my experiences there is only one efficient way to do that which is using a blacklist guard to filter JWT's. If it passes that guard then its good to go. We can keep that blacklist on memory storage like memcached, redis etc. its better than hit to sql databases or disk (cookies). JWT => expiration guard | blacklist guard => api end point

[@OverG88]

And what did you achive by implementing blacklisting? Because, on each verification you will have to check against a data store whether the token is blacklisted. Where’s the difference between that approach and sessions? The whole point is missed in your case. Just make them shortlived.

[@biliyonnet]

@@OverG88 Yes but on big sites you can't keep all the session data in memory but you can keep a blacklist on memory easily.

[@OverG88]

@@biliyonnet And upon each request, you will have to check against an authentication server whether the token is blacklisted. If your auth. server goes down, everything goes down. The second thing, you can have a massive session storage in memory. If that's not enough, idle sessions can be stored on a disc. There's a ton of solutions for that.

[@leanprogrammer]

great answer. Thanks!

[@thomasellingsen1755]

Hi Nick! Did you ever make video 2 of this?

[@anstapol]

what about man in the middle on auth API ?

[@carlosjosejimenezbermudez9255]

As far as I know HTTPS will solve your man in the middle concerns. If you want extra protection, using a https proxy and an SSL certificate on your servers will give you a double layer against a man in the middle attack. Enforcing HTTPS traffic is the way to go these days.

[@YarivGilad]

How do you best handle expiration of the refresh token?

[@jackofalltrades8212]

When access token is expired.. client sends refresh token to get new access token. If refresh token is expired (or invalidated/removed by server), 401 response to THAT API request means client needs to put up login page again and require user to log in again. That will then generate new refresh token AND access token like any login does. On a Web/mobile UI, the refresh token can be associated with the "stay logged in" feature many apps/sites have. That is telling the app "this user wants to stay in.. so if access token is expired, use refresh token to get another access token without user knowing.. keeping them logged in". When you chose NOT to use a stay logged in feature, it is possible the login step returns a longer lived access token.. maybe 1 hour instead of 15 minutes for example, to better the user experience.

[@blakeneal7205]

If the refresh token has expired (which would be after a long while) the best course is to have them log in again. That will return a new access and refresh token as a result of the password grant type

[@techalbal]

@@jackofalltrades8212 one of the best explanations i have read so far. 👍

[@jackofalltrades8212]

@@techalbal Thank, you. Took me a while to learn all this, but I think I have it figured out. :)

[@torrvic1156]

@@jackofalltrades8212excellent explanation sir! Just brilliant!

[@hassanOnYoutube]

Love !!

[@XMLMaestro]

Why refresh token is not returned when you use client_credentials grant type?

[@tripadadash4430]

Hi Nick - You mentioned when JWT expires, user need to re-login to get a new JWT. --- lets say this is case 1 Now, case 2 - JWT expires, refresh token is active. So, both tokens are sent to server and new JWT as well as new refresh token is obtained. So basically, even if the refresh token has not expired, a fresh one is received? So, does this mean the server maintains a pair of JWT and its corresponding refresh token?

[@neonlight1203]

I have the same question. I think only a fresh access token is received.

[@OverG88]

You don’t want to have such a thing as “pair of access and refresh token”. Also, you don’t want to store refresh token on server. You want to store a part of it (id) or its hash. When the access token expires, you send the refresh token. Refresh token can also be JWT. Then you validate refresh token against the secret key and check whether it’s id is present in servers database. If so, you issue a new access and refresh token, and replace an id of an old refresh token with the new id. Rinse and repeat. Refresh token exists only to issue a new access token. Issuing new refresh token too, limits attacking capabilities. Imagine that someone steals your access token. They will be able to access protected resources for some time. It’s important to keep JWT access token short lived since it cannot be invalidated immediately unless you implement blacklisting (but that kills the purpose of JWT) or change your private key. After some time (like 5 mins) they will have to obtain a new access token by sending a refresh token. If they neglect servers response which contains new refresh token.. boom! They are fucked! Their current access and refresh token are unusable.

[@John-mj1kk]

@@OverG88 But that means that a new refresh token has to be issued every time a new access token is needed, right? If the user's access token is expired (or doesn't exist), they will use the refresh token to renew the tokens. So every time the access token expires, it won't be the only one to be renewed. The only way to avoid this would be to check the expiration date on the backend, and if it's nearly expiring, then issue a new one, else don't modify it. But that may seem like a security risk.

[@thomasthaler7669]

@@John-mj1kk you are absolutely right. I think this is called token rotation. Every time you call the refresh endpoint it serves you a new access and a new refresh token (invalidating the current one)

[@kephas-media]

We are all from the future lololol

[@rezznov98]

Thanks.

[@doctorcode]

well you said that its easy to implement the check of exp of access token in frontend , and thats right 2 lines of code in a middleware can catch that , the thing you forgot to connect in your diagram is that the api endpoint of the micro service or just regular monolith app , will have to go again to auth service and check if that access_token is still valid or else its very easy to hack this diagram .

[@nickchapsas]

This is actually wrong. You don't need to go to the auth service to validate the token. The signature can be validated on the client side using a symmetric key or a certificate so there is no need for an auth service call at all.

[@SeshachalamMalisetti]

How are jwt tokens and oauth2 differ

[@khasim4u4u]

can you show the refresh token implementation please

[@DuyTran-ss4lu]

Great

[@mr.RAND5584]

Refresh token is the same as back up token like a bullet need to reload. I am trying to understand.

[@royalindia7845]

Hi Nick please share the implementation

[@saeeduchiha5537]

To understand it well, I had to slow down the video speed to 0.75 and enable CC (English) and get up my focus to 100% ... Thanks Though :)

[@heathen838]

hear hear

[@TheGlitchOfTheGame]

My wep-page crashes when the jwt token expires and I have to manually delete my expired token from the localStorage for the page to work again, why is that happening and how i can solve it ? Note: I’m not using a refresh token .

[@moamenzakaria4771]

you should refer to the next video, so we can find it

[@uclocnguyenvo422]

...or if you are from the future :))

[@sorinlupu2639]

I only need to refresh the expired jwt token if the user is currently using my SPA. Is it okay if I store user email & password in ReactJS global state (in memory) and simulate a login if the token expires? What is your opinion/advice about this?

[@PEJ27]

In OAuth, that's called ROPC or Resource Owner Password Credential and it's strongly recommended this is not used. This is the purpose of refresh tokens and access tokens, i.e. to securely sign a new access token without having to store (if even in memory) user credentials. I'm sure there are other opinions, so this is just my .02

[@OverG88]

Hell no! In case of XSS vulnerability, say goodbye to user credentials.

[@RobertWard-f6f]

Schamberger Mount

[@VoppsaZonesa-b3b]

Schiller Prairie

[@NapoleonPatera-l3m]

Jones Cliffs

[@dffdfdfdf-p4z]

Gibson Springs

[@BlancaMoore-r2x]

Brakus Shores

[@JohnnieSimmons-c1q]

Monahan Forge

[@JeffreyHall-s9i]

Parisian Mission

[@CarolineLouise-i2o]

Cleo Brooks

[@RichardsChad-z1v]

Susanna Underpass

[@HaroldCharles-o3g]

Taya Throughway

[@AndresDahl-k1g]

Ziemann Cliffs

[@TateAurora-k6p]

Rigoberto Road

[@AnnConrad-i8x]

Welch Fields

[@KatharineAbbott-j6e]

Mollie Valley

[@LukeEvan-s3k]

Wuckert Summit

[@CookSidney-n2c]

Dahlia Canyon

[@FatihGezer-y3q]

Effertz Roads

[@LouiseSheffer-r2p]

Gardner Branch

[@JamesBurns-p1r]

Dibbert Curve

[@CeciliaGist-y3r]

Robbie Lake

[@LeticiaMart-u7z]

Treutel Parkway

[@ClementEdward-c6w]

Trevor Fork

[@themichael8767]

Thank You very much 🤍

[@carlosjosejimenezbermudez9255]

Recommending the use of refresh tokens in a SPA (or some mobile apps) is a terrible idea when it comes to security. Refresh tokens should ONLY be used on secure clients. If you need the UX advantage of a refresh token, you should look into Identity Server 4 and OpenId Connect, using a Code with PKCE flow and silent refresh in the front end you can achieve the same results of not requiring constant login. If Facebook or Google used refresh tokens in their SPAs, they would be subject to many many many more security issues than they already have to handle. They use OpenId Connect or OAuth 2, NOT refresh tokens by themselves.

[@nickchapsas]

I don’t think I’m recommending the usage of refresh tokens at any point. I am only using SPAs as an example of to explain the flow.

[@BarbPereira-x6x]

Madyson Pike

[@AttleeGerald-e2f]

Hettinger Drive

[@AgnesVivien-g5h]

Quitzon Shoals

[@HermanCarlone-z4h]

Abshire Ferry

[@IrmaMedlin-y4o]

Murray Streets

[@KimSmith-z6e]

Glover Place

[@KattieIglesias-v7j]

Jadyn Isle

[@EddieDuncan-k3v]

Kris Locks

[@HelenClark-e6v]

Lubowitz Ports

[@ElizabethBernard-m8o]

Lilliana Mission

[@AlanThomas-b2q]

Braun Summit

[@GeoffreyLetchworth-b5q]

Jakubowski Oval

[@GrahamSandra-y5w]

Klein Plains

[@NorahYarbough-g1t]

Hane Flat

[@LowellMichaelia-h6r]

Klein Glen

[@GarciaBblythe-c6e]

Ivah Drive

[@KiplingPaddy-f4s]

Trantow Rue

[@HaggaiReginald-i7k]

Pouros Oval

[@CharlottOlarte-h7d]

Mertz Throughway

[@NelsonBernard-h4t]

Kilback Course