Man, you grow older by the end of the video, and got more experience in front of a camera, no more looking down to cheat-sheets. Fantastic delivery and cover of the content. Amazing, keep it up!
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?
@@bige2899 even if rotation is requested by malicious user, when legitimate user tries to refresh token, the token family is discarded and both of them will logout. Max to max malicious user will access account till access token expires
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
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.
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 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 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.
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 :)
@@whatsoever6863 nobody knows everything from top of their head, notes are needed for talking points, that doesn’t mean he doesn’t know what he’s 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
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
Man, you grow older by the end of the video, and got more experience in front of a camera, no more looking down to cheat-sheets. Fantastic delivery and cover of the content. Amazing, keep it up!
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.
@@pD5V0DdsaoVhq how exactly? Not one video explains why the same is not possible through just access token
Super clear and educational!
One of the best video I have watched 👌❤ loved the way you explained
Sir, thanks you very much ,I have been searching for long for this😂 ...
From India 🇮🇳 ♥️
Thank you sir for making this video informative and fun to watch.
Clear, precise, cheers!
wouldn't the automatic resuse detection system require state? In that case why not use Oauth 2?
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 🙏
Honestly, great video!
Great vid, informative and very entertaining. Well done, Sir!
Thank you, the video gives me the answer for how to secure refresh tokens.
Glad we could help!
Good explanation. Thanks. God bless you
You are very welcome :)
12:35 What are the measures to determine that the rotation is being requested by a malicious user ?
@@bige2899 even if rotation is requested by malicious user, when legitimate user tries to refresh token, the token family is discarded and both of them will logout. Max to max malicious user will access account till access token expires
Thank you! It helped me a lot
Glad to hear that!
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
It was a great session, easy to understand comparing with others
Awesome viedo! However, I wonder if the token family break the server stateless?
Great video! thank you!
great explaination! Thank you
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.
Thank you
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!
That was awesome
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.
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.
Thank you.
You're welcome!
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.
Thought I was tripping when I saw the guy's beard starting to grow grey towards the end of the video lol.
Thanks!
How the heaven I generate.a new refrsh token ? Am noob
Plain English. I understand now!!!
the editing is a bit weird
let data = "hello"
Seems token is quite... dynamic
Jerrell Ridge
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 :)
@@whatsoever6863 nobody knows everything from top of their head, notes are needed for talking points, that doesn’t mean he doesn’t know what he’s 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.
Sammy Circles
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
7767 Jamel Prairie