This video has enough information to tell you "refresh tokens are very powerful" and they also tell you "auth0 takes measures to secure it" (which satisfies their goal I guess). The main difference between access tokens and refresh tokens is that the refresh tokens are stored in the database and the server can invalidate them at will. So, if a user changes password or the refresh token is compromised, the refresh token can be revoked and the bad actor loses access as soon as the access token expires.
Awesome and easy to understand! Thank You Very Much! I do have one question though, that I can't seem to find the answer to. For refresh token rotation, is it a sliding rotation? Meaning when I get a new refresh token is the expiration pushed back further than the initial expiration? Or is there a way to configure it to, regardless of how many refresh tokens I get, have a combined expiration of... let's say 30 days?
Hi, I'm trying to understand since I'm building an app in Php and I have to use a rest service, I have the service to request a token that also returns the refresh token, ¿Should I request the token, store it in a database and every time I request the token, before checking if I have a valid one in the database based on the expiration date? ¿What would the refresh token be used for? Thanks for all
If both the access token and refresh token have expired at the same time (i.e., after 15 minutes), it presents a challenge because the client can no longer use the expired refresh token to obtain a new access token. In this case, the user would need to re-authenticate to obtain a new pair of tokens innit?
Yes, this is by design. You shouldn't configure your access token and refresh token lifetimes to be the same. If a 1-hour access token happens to coincide with a 30-day refresh token expiring, that is correct, and the intent is that the user has to log in again. Hope that helps!
I JUST WANT TO SAY THAT I SPEND ABOUT 4-5 DAYS JUST SEARCHING WHY WE NEED REFRESH TOKEN, THANKS ALLAH FORR FIND THIS VIDEO AT THE END OF MY DAY AND THANKS YOU FOR THE PLAIN AND CLEAR UNDERSTANDABLE ANSWER , KINDLY THANK THIS GUY TOO MUCH AND PROVIDE ME BY HIS TWITTER IF HE HAS, THANK YOU
What happens if a malicious person gets their hands on the refresh token, but the actual user doesn't make a request for quite some time? Wouldn't that let the malicious person misuse the long-lasting refresh token? While I do agree that rotating refresh tokens can enhance security, I'm curious about how this specific scenario would be managed.
Thanks for watching! If a refresh token issued to a public client is stolen, the attacker can impersonate the client and use the refresh token without being detected. It is also possible to bind refresh tokens to the public client instance using DPoP (oauth.net/2/dpop/) which can counter this attack. Confidential clients need to authenticate to the authorization server in order to use the refresh token, so the risk of stolen refresh tokens is lower for this type of client.
I created a microservices architecture with Spring Boot 3 and Auth0 last week using JHipster. You can check out the video at ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-kq31RuT4Bxw.html.
What happens in 12:07, if the malicious user authenticated with the stolen refresh token before the legitimate user does? Wouldn't the melicious user then have a legit access token to impersonate the legit user?
he would, for a short while. If a refresh token is used twice, all subsequent refresh tokens will be invalid. So both attacker and the legimate users would had to relogin. (Which attacker cant). Correct me if I am wrong.
What happens if refresh token was played by hacker before real user needs it? So the hacker gets the new 2nd access token. So silly 😂. The whole opened has a flaw! The persistence of the token should be on the SP side so not post them and stop. Not the IDP checking later. Which is pure useless
i was just about to write the same comment, but think in it for 1 second, it does not depend on who uses it first it depends that it can be used once, otherwise, all is unauthenticated so if the hacker uses it first, when the real user tries ti use it again i=> all will be un authenticated and the real use can log in again with his credentials
infromative, but it is visible that the man presenting the topic reads everything from behind camera, feels like he doesn't really know what he is talking about :)
