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!
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 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
I created a microservices architecture with Spring Boot 3 and Auth0 last week using JHipster. You can check out the video at ua-cam.com/video/kq31RuT4Bxw/v-deo.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.
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 :)
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
Super clear, thank you for this awesome video! I feel smarter.
that's genius, you explained what I was working for it for three months,thanks bro❤!!!
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.
One of the best video I have watched 👌❤ loved the way you explained
Super clear and educational!
Honestly, great video!
Thank you sir for making this video informative and fun to watch.
Sir, thanks you very much ,I have been searching for long for this😂 ...
From India 🇮🇳 ♥️
Thank you, the video gives me the answer for how to secure refresh tokens.
Glad we could help!
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?
Thanks for your question! Let us do some research and get back to you, please 🙏
Thank you! It helped me a lot
Glad to hear that!
Good explanation. Thanks. God bless you
You are very welcome :)
great explaination! Thank you
Great vid, informative and very entertaining. Well done, Sir!
Great video! thank you!
It was a great session, easy to understand comparing with others
Thought I was tripping when I saw the guy's beard starting to grow grey towards the end of the video lol.
thank you for the content you are very knowledable. Mini tip that would help so much is to use tables charts eg for part about which auth flow ot use.
wouldn't the automatic resuse detection system require state? In that case why not use Oauth 2?
Thank you.
You're welcome!
Awesome viedo! However, I wonder if the token family break the server stateless?
Thanks!
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!
Plain English. I understand now!!!
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 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
Thanks for your kind feedback! We have shared it with Will :) You can find him on Twitter here: twitter.com/willjohnsonio
@@OktaDev Thank you for your time and effort🌺
Thank you
How the heaven I generate.a new refrsh token ? Am noob
Clearly explained. Thanks. But, but how can a beginner get an example of using Okta and spring boot 3 microservices?
Thanks for your feedback. We don't have content on Spring Boot 3 yet but we'll keep that in mind as a topic to tackle.
@@OktaDev Thanks. But you know if there any major changes I should be aware of, in case I want to use Okta with a spring boot 3 application?
I created a microservices architecture with Spring Boot 3 and Auth0 last week using JHipster. You can check out the video at ua-cam.com/video/kq31RuT4Bxw/v-deo.html.
@@mraible Thanks.
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?
I am wondering too
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.
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 :)
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 see the whole flow bullshit, next years must be a much better way for doing this. current methods are so ridiculous
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
@@abdulhaimohamed ... but not before the malicious user steals all the legit user's data. It doesn't take long.
the editing is a bit weird