You probably dont give a shit but does someone know a method to log back into an Instagram account?? I somehow lost my login password. I would love any tricks you can offer me!
@Kye Sullivan I really appreciate your reply. I found the site through google and im in the hacking process now. Takes a while so I will get back to you later with my results.
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.
Thank you for your question. Unfortunately, any possible configuration depends on the product you are using. So, it may not be possible at all. If this type of configuration is important for you, you may need to choose your OAuth server based on that requirement. I hope this helps.
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
Hi Ajay, if all tokens have expired, the user needs to re-authenticate and re-grant the client (depending on implementation details). Especially with a "fixed" window in regards to lifetime, it does not matter if the user was active or not. I hope this helps.
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?
Hi Vincent, it seems I have mixed this comment! Well, in some use cases the application may want users to re-authenticate after a given time (1 week, 1 month). Most important is the difference of those token: access_token access resources against a resource server (your bank account, insurance account, calendar) and refresh_token retrieve new access_token against the authentication server. I hope this helps.
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
Hi Ahmed! No, scalability is not a reason for those two token. Access_token allow your client to access resources, refresh_token cannot. access_token are sent to resources servers, refresh_token only to the issuing authorization server (as you mentioned). I hope the confirms what you have understood
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
Hello Jason! Yes, that is a little confusing, thanks for pointing that out! Both token can be revoked, so the access_token may be in the black list also. The other option to check if the access_token is still valid is to check if it's 'parent' refresh_token is in that black list. In that case the access_token would also be invalid. However, where systems issue very short lived access_token (maybe 2 minutes or less) revoking access_token may not be an option. Unfortunately, implementations always seem to cook their own little soup. If you are implementing this, make sure to address your specific use case! I hope this helps!
I see, so the revocation token store contains the access tokens both in reference / random string access token and jwt implementations. the main difference, the former is a whitelist while the latter a blacklist. Or as you say, in the latter, can also just check the.parent refresh token if not wanting to store the jwt in token store. Thanks again Sascha
Hi Jason, just to clarify. An authorization server will either maintain all valid, simple string based, token in a whitelist (token that are not in that list are revoked of have expired) or, for JWT bases token, the same server will either not support revocation due to the maintenance effort of the blacklist, the distributed nature of the system it is responsible for or because token lifetimes are just very short. And, in the case it does support revocation, it will do that for refresh_token only and is also aware of the associated access_token. You may want to checkout the documentation of Ping Identity, ForgeRock, Auth0 or Okta. They all support enterprise grade oauth/ openid connect implementations and will give you a good idea what kind of revocation they support. Most likely you will discover different types of revocation. Thanks for your questions and the discussion!
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 🤷♂?
Hello Riza! The difference is that a refresh_token is never exchanged with the resource_server. IT is only used between the issuing authorization_server and the requesting client. Therefore, it is at leas only less party that has access to it. And it cannot be used to retrieve protected data from a resource_server. And yes, access_token lifetimes are usually short. There are cases where they can even only be used once. For example, transferring USD 10.000 to another account, could be such case. I hope this helps, if not, please let me know.
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.
Hello, thanks for your question. Refresh_token usages are often implemented differently. Some OAuth/ OpenID Connect providers allow multiple usages, some just once. Therefore 'MAY'. If you plan to work against a provider, you need to read their developer documentation. If you plan on implementing a server yourself, I would try the 'once only' approach first. I hope this helps!
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
@@saschazegerman I have many concerns... mostly related to security. But mostly I wish you'd hold my hand. Lol. I've done so many advanced algorithm implementations like day warren and order stat tree implementation and have even seen sliding window as part of an algorithmic approach to solving some real world problems (like this but others as well, like calander availability checking) . Definitely interesting, a little different but still quite similar.. new to the backend though. Wish you could hold my hand :(
Anthony, it took me quite a while to get these things in order. Every video I make is based on my own experience, reading the specs. up and down, talking to oauth mailing list participants, attending identity centric conferences. So, if you have a hard time getting started, that is just how it works :-). Looking forward to hear your implementation ended up
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?
Hello Prashanth, thanks for your question! In that sliding window scenario a user would only authenticate if the refresh_token has expired. And that will be the case if the app had no reason to request a new one which indicates an inactive user. Apps (clients) can request a new refresh_token without asking the user for authentication or granting consent as long as the current refresh_token is valid. This means users will not notice any token exchange related behaviour. Please let me know if this answers your question!
@@saschazegerman it does. Is tlit the same in Auth0 protocol too. It does provide a way to re-authenticate in case of a inactive user. Is that similar to OAuth? Secondly, is extending the refresh token a good practice for web-apps as they are more susceptible for attacks?
@@prashanthbp I am not sure about Auth0, I have not looked into their refresh_token implementation for a while. I believe they recently introduced the "rotation" of refresh_token which is the feature of issuing a new one each time one is used. If you are referring to SPAs and similar apps when saying web-apps (in oauth terms 'public' clients) the sliding-window may not be used. For some guidance see this section of the RFC 6749: datatracker.ietf.org/doc/html/rfc6749#section-10.4 In regards to user authentication, a typical flow would be like this: client uses access_token until that fails, client then uses refresh_token, and if hat fails, take the user through an authentication flow. I hope this helps!
Thank you for this video. I would just like to ask, is it possible for the jwt access token to contain within it the refresh token? This way, a client sends a revocation request, the jwt is modified by the auth server and revokes both the claims and the contained refresh token. Next time a resource request is sent, the resource server can always just validate the jwt locally. I hope my question makes sense, I am still learning. Thanks
Hello Jason! By design the refresh_token should only be exchanged between the authorization server and the client. If it would be included in the access_token the refresh_token would be exposed to the resource_server. Let's say the access_token would also include the client_id, the resource server could now use the refresh_token to request a new access_token itself which may cause a vulnerability. For that reason it cannot (should not) be done. I hope this helps, if not, feel free to ask for more clarification!
The access token JWT simply contains the matching refresh token id. Every time an access token is validated, the auth server checks for revocation of the refresh token ID.
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?
Hello Vipul! In that case is it the same situation as if the user would use the service the first time. The user needs to authenticate and grant access so that the app can receive new token. I hope that helps.
I watched so many videos on this subject but I still cannot understand what makes the refresh token any safer. If a man in the middle attack intercepts both the access token and refresh token then they can just keep on issuing new access tokens, can't they?
Hello Karim! Thanks for your question, it makes total sense! There are a few things to it. You can stop searching for videos that explain why refresh_token make things safer. In regards to making things safer look at it from these two angles: does it make my app safer? does it make the usage of my app safer? As you pointed out, if the refresh_token leaks everything is lost. But to avoid that refresh_token should not be issued to public clients and for confidential clients they should have a limited life time. With that they will most likely not end up in hackers hands. What refresh_token do make safer though is reducing the chances for your users to be phished for their passwords. If refresh_token are used with an app, the app users have to provide their passwords less often and therefore do not have to be requested for it too often. I hope this makes sense, if not, please ask more questions!
@@saschazegerman thx for the reply. Ok I don't know what you mean by confidential client vs public client, but as far as your second point , if the benefit of having the refresh token is less chances of being phished, then why set a short expiry on the access token in the first place? Why not do away with the refresh token completely and just have an access token with a longer expiry date instead
@@karimk8551 The access_token is used way more often, practically each time a protected resource is being accessed. The refresh_token is only used whenever the access_token is expired and it is only send to the authorization_server. In regards to client types, please watch my video about confidential and public clients. That is a very important concept in oauth!
@@karimk8551 what’s actually not captured here on why refresh tokens are “safer” is that per the OAuth protocol, they require a second factor - to obtain another access token using the refresh token, the request made typically requires the client ID and client secret be sent, too. While an intercepted request pokes holes in this, it’s not the vector it’s protecting against. The vector that is protected is if a DB storing these tokens is compromised. Assuming the client ID and secret are only set in the environment of the host machine, unless that, too, is comprised, it’s unlikely a malicious actor can obtain a new access token once it expires, because a refresh token alone is missing the other components of a valid request for a new access token.
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?
Hi Jonathan! Yeah, refresh_token may raise questions. But foremost, they are not meant as an additional security element. Refresh_token are purely meant to retrieve a new access_token without having to require an explicit consent of a user again. To mitigate the misusage of these token, servers may only issue them to confidential clients. If that is not possible, they should issue a new one when used and the old one should be revoked and should have a shortest possible lifetime for the use case. Please find RFC 6819 for more advise about the usage of refresh_token. I hope this helps!
@@saschazegerman The refresh for exact, I was getting on the game Cookie Run Kingdom and it said my Facebook Refresh Token expired, and it said “cancel” and “ok”
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?
Hi Daniyar! To answer your question I would need to know little more context. For example, if you get the error because your access_token has expired, and you do not have refresh_token, you need to get the user to login and grant access to resources again. If you do have a refresh_token, then use it 'behind the scenes' so that it is transparent to your user. Does this help? If not, please explain a little more.
Hello Christian! Well, that is not too important I would say. The question is: how does you app get a new access_token once the current one has expired? For that you either need to have a valid user session (e.g.: cookie) that could be used instead of asking for username, password. Or a refresh_token which is more convenient since it improves the usability of you application. If this does not answer your question feel free to come back
@@saschazegerman my access token expires 1 day before its being issued to the user and it is stored using HTTP only cookies. The data that is embedded in the token is just the user-id and the expiration date of the token. The user is also being forced to log out if the front end detects that the user is not interacting with the system for some time.
@@Malcolm777-i Did I understand you correctly, the token expires before it is being issued? If that is the case you may want to revisit your configuration. The access_token should be issued when the user logs. Typical access_token life times are 5 - 60 minutes. The idea is not so much to manage user sessions via access_token. They are really meant to access protected resources such as personal user data.
Hi Sam! You first need to request an access_token (i.e.: authorization_code flow). You may need to include the scope offline_access to have a refresh_token included in the response. Once you received it, you can use the refresh_token grant_type. I hope this helps.
Hello Debu, I missed your question! Unfortunately, when it is expired ... it is expired and a new access- and refresh_token have to be requested. One way out could be if the target authorization server accepts id_token_hint and your client could provide one. Sometimes an id_token has a longer lifetime and with that it may work (instead of requesting username,password of the user). I hope this helps
That is correct, Ibrahim! But refresh_token are never send to resources servers, only to the authorization servers and only if the access_token has expired. I hope that my video does not create confusion about that!
Wow, such a nice and crisp explanation, please continue making such videos. I strongly believe everyone who watched it definitely liked it a lot.
You probably dont give a shit but does someone know a method to log back into an Instagram account??
I somehow lost my login password. I would love any tricks you can offer me!
@Misael Harry Instablaster :)
@Kye Sullivan I really appreciate your reply. I found the site through google and im in the hacking process now.
Takes a while so I will get back to you later with my results.
@Kye Sullivan it worked and I finally got access to my account again. I'm so happy:D
Thank you so much, you saved my ass !
@Misael Harry happy to help xD
Amazing video Sascha! Very crisp explanation. Thank you!
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
you are gem. your description is awesome.really appreaciate
Great explanation. I got a better understanding of auth from this content.
Reeeeally helpful video, thank you and take care 👍
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.
Thank you for your question. Unfortunately, any possible configuration depends on the product you are using. So, it may not be possible at all. If this type of configuration is important for you, you may need to choose your OAuth server based on that requirement. I hope this helps.
Vielen Dank! Sehr gut erklärt. 👍
thanks Sascha, very clearly explained!
Excellent explanation
Incredible video, thanks!
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
Hi Ajay, if all tokens have expired, the user needs to re-authenticate and re-grant the client (depending on implementation details). Especially with a "fixed" window in regards to lifetime, it does not matter if the user was active or not. I hope this helps.
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?
Hi Vincent, it seems I have mixed this comment! Well, in some use cases the application may want users to re-authenticate after a given time (1 week, 1 month). Most important is the difference of those token: access_token access resources against a resource server (your bank account, insurance account, calendar) and refresh_token retrieve new access_token against the authentication server. I hope this helps.
Thank you very much for this informative video! -
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
Hi Ahmed! No, scalability is not a reason for those two token. Access_token allow your client to access resources, refresh_token cannot.
access_token are sent to resources servers, refresh_token only to the issuing authorization server (as you mentioned).
I hope the confirms what you have understood
Awesome videos. Can you contrast OAuth vs OpenIDConnect
Thank you! I do have a video that covers OpenID Connect basics. It does show how they relate to each other. Please let me know if that helps.
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
Hello Jason! Yes, that is a little confusing, thanks for pointing that out! Both token can be revoked, so the access_token may be in the black list also. The other option to check if the access_token is still valid is to check if it's 'parent' refresh_token is in that black list. In that case the access_token would also be invalid. However, where systems issue very short lived access_token (maybe 2 minutes or less) revoking access_token may not be an option. Unfortunately, implementations always seem to cook their own little soup. If you are implementing this, make sure to address your specific use case! I hope this helps!
I see, so the revocation token store contains the access tokens both in reference / random string access token and jwt implementations. the main difference, the former is a whitelist while the latter a blacklist. Or as you say, in the latter, can also just check the.parent refresh token if not wanting to store the jwt in token store. Thanks again Sascha
Hi Jason, just to clarify. An authorization server will either maintain all valid, simple string based, token in a whitelist (token that are not in that list are revoked of have expired) or, for JWT bases token, the same server will either not support revocation due to the maintenance effort of the blacklist, the distributed nature of the system it is responsible for or because token lifetimes are just very short. And, in the case it does support revocation, it will do that for refresh_token only and is also aware of the associated access_token. You may want to checkout the documentation of Ping Identity, ForgeRock, Auth0 or Okta. They all support enterprise grade oauth/ openid connect implementations and will give you a good idea what kind of revocation they support. Most likely you will discover different types of revocation. Thanks for your questions and the discussion!
@@saschazegerman Many thanks, appreciate it 👍
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 🤷♂?
Hello Riza! The difference is that a refresh_token is never exchanged with the resource_server. IT is only used between the issuing authorization_server and the requesting client. Therefore, it is at leas only less party that has access to it. And it cannot be used to retrieve protected data from a resource_server.
And yes, access_token lifetimes are usually short. There are cases where they can even only be used once. For example, transferring USD 10.000 to another account, could be such case.
I hope this helps, if not, please let me know.
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.
Hello, thanks for your question. Refresh_token usages are often implemented differently. Some OAuth/ OpenID Connect providers allow multiple usages, some just once. Therefore 'MAY'. If you plan to work against a provider, you need to read their developer documentation. If you plan on implementing a server yourself, I would try the 'once only' approach first. I hope this helps!
Thank you.
You're welcome, glad you liked it
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
Hello Ajay! I am not a Kong expert, but usually it is the client, the recipient of the tokens, that is responsible. I hope this helps.
Implementing this currently
Hi Anthony, good luck! Let me know how it goes!
@@saschazegerman I have many concerns... mostly related to security. But mostly I wish you'd hold my hand. Lol. I've done so many advanced algorithm implementations like day warren and order stat tree implementation and have even seen sliding window as part of an algorithmic approach to solving some real world problems (like this but others as well, like calander availability checking) . Definitely interesting, a little different but still quite similar.. new to the backend though. Wish you could hold my hand :(
@@saschazegerman btw great video. You deserve more likes. I subbed
Anthony, it took me quite a while to get these things in order. Every video I make is based on my own experience, reading the specs. up and down, talking to oauth mailing list participants, attending identity centric conferences. So, if you have a hard time getting started, that is just how it works :-). Looking forward to hear your implementation ended up
@@saschazegerman worked great
What mic are you using? Dedicated mixer or usb mic? It sounds good
Hi! It is just the mic of my MacBook. I am glad it sounds good!
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?
Hello Prashanth, thanks for your question! In that sliding window scenario a user would only authenticate if the refresh_token has expired. And that will be the case if the app had no reason to request a new one which indicates an inactive user.
Apps (clients) can request a new refresh_token without asking the user for authentication or granting consent as long as the current refresh_token is valid.
This means users will not notice any token exchange related behaviour.
Please let me know if this answers your question!
@@saschazegerman it does. Is tlit the same in Auth0 protocol too. It does provide a way to re-authenticate in case of a inactive user. Is that similar to OAuth?
Secondly, is extending the refresh token a good practice for web-apps as they are more susceptible for attacks?
@@prashanthbp I am not sure about Auth0, I have not looked into their refresh_token implementation for a while. I believe they recently introduced the "rotation" of refresh_token which is the feature of issuing a new one each time one is used.
If you are referring to SPAs and similar apps when saying web-apps (in oauth terms 'public' clients) the sliding-window may not be used. For some guidance see this section of the RFC 6749: datatracker.ietf.org/doc/html/rfc6749#section-10.4
In regards to user authentication, a typical flow would be like this: client uses access_token until that fails, client then uses refresh_token, and if hat fails, take the user through an authentication flow.
I hope this helps!
Thank you for this video. I would just like to ask, is it possible for the jwt access token to contain within it the refresh token? This way, a client sends a revocation request, the jwt is modified by the auth server and revokes both the claims and the contained refresh token. Next time a resource request is sent, the resource server can always just validate the jwt locally. I hope my question makes sense, I am still learning. Thanks
Hello Jason! By design the refresh_token should only be exchanged between the authorization server and the client. If it would be included in the access_token the refresh_token would be exposed to the resource_server. Let's say the access_token would also include the client_id, the resource server could now use the refresh_token to request a new access_token itself which may cause a vulnerability. For that reason it cannot (should not) be done. I hope this helps, if not, feel free to ask for more clarification!
The access token JWT simply contains the matching refresh token id. Every time an access token is validated, the auth server checks for revocation of the refresh token ID.
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?
Hello Vipul! In that case is it the same situation as if the user would use the service the first time. The user needs to authenticate and grant access so that the app can receive new token. I hope that helps.
I watched so many videos on this subject but I still cannot understand what makes the refresh token any safer. If a man in the middle attack intercepts both the access token and refresh token then they can just keep on issuing new access tokens, can't they?
Hello Karim! Thanks for your question, it makes total sense! There are a few things to it. You can stop searching for videos that explain why refresh_token make things safer. In regards to making things safer look at it from these two angles: does it make my app safer? does it make the usage of my app safer?
As you pointed out, if the refresh_token leaks everything is lost. But to avoid that refresh_token should not be issued to public clients and for confidential clients they should have a limited life time. With that they will most likely not end up in hackers hands.
What refresh_token do make safer though is reducing the chances for your users to be phished for their passwords. If refresh_token are used with an app, the app users have to provide their passwords less often and therefore do not have to be requested for it too often.
I hope this makes sense, if not, please ask more questions!
@@saschazegerman thx for the reply. Ok I don't know what you mean by confidential client vs public client, but as far as your second point , if the benefit of having the refresh token is less chances of being phished, then why set a short expiry on the access token in the first place? Why not do away with the refresh token completely and just have an access token with a longer expiry date instead
@@karimk8551 The access_token is used way more often, practically each time a protected resource is being accessed. The refresh_token is only used whenever the access_token is expired and it is only send to the authorization_server.
In regards to client types, please watch my video about confidential and public clients. That is a very important concept in oauth!
@@saschazegerman ok I think I got it thanks
@@karimk8551 what’s actually not captured here on why refresh tokens are “safer” is that per the OAuth protocol, they require a second factor - to obtain another access token using the refresh token, the request made typically requires the client ID and client secret be sent, too. While an intercepted request pokes holes in this, it’s not the vector it’s protecting against. The vector that is protected is if a DB storing these tokens is compromised. Assuming the client ID and secret are only set in the environment of the host machine, unless that, too, is comprised, it’s unlikely a malicious actor can obtain a new access token once it expires, because a refresh token alone is missing the other components of a valid request for a new access token.
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?
Hi Jonathan! Yeah, refresh_token may raise questions. But foremost, they are not meant as an additional security element. Refresh_token are purely meant to retrieve a new access_token without having to require an explicit consent of a user again.
To mitigate the misusage of these token, servers may only issue them to confidential clients. If that is not possible, they should issue a new one when used and the old one should be revoked and should have a shortest possible lifetime for the use case.
Please find RFC 6819 for more advise about the usage of refresh_token. I hope this helps!
@@saschazegerman So is it bad if your token expires?
@@saschazegerman The refresh for exact, I was getting on the game Cookie Run Kingdom and it said my Facebook Refresh Token expired, and it said “cancel” and “ok”
@@saschazegerman and also because I had linked it with Facebook and another one
@@SirQuackles Hi! No, it is not bad. Your client just has to handle that case and may have to involve the user for retrieving a new one.
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?
Hi Daniyar! To answer your question I would need to know little more context. For example, if you get the error because your access_token has expired, and you do not have refresh_token, you need to get the user to login and grant access to resources again. If you do have a refresh_token, then use it 'behind the scenes' so that it is transparent to your user. Does this help? If not, please explain a little more.
Is refresh token necessary when your API and front end will run on the same domain/server?
Hello Christian! Well, that is not too important I would say. The question is: how does you app get a new access_token once the current one has expired? For that you either need to have a valid user session (e.g.: cookie) that could be used instead of asking for username, password. Or a refresh_token which is more convenient since it improves the usability of you application. If this does not answer your question feel free to come back
@@saschazegerman my access token expires 1 day before its being issued to the user and it is stored using HTTP only cookies. The data that is embedded in the token is just the user-id and the expiration date of the token. The user is also being forced to log out if the front end detects that the user is not interacting with the system for some time.
@@saschazegerman my API is only available with one (1) domain / IP.
@@saschazegerman thank you also for the clarification regarding this topic appreciate it! ☺️ I’m new to this refresh token thing...
@@Malcolm777-i Did I understand you correctly, the token expires before it is being issued? If that is the case you may want to revisit your configuration. The access_token should be issued when the user logs. Typical access_token life times are 5 - 60 minutes. The idea is not so much to manage user sessions via access_token. They are really meant to access protected resources such as personal user data.
Can u please tell me how can I get try refresh token ???
Hi Sam! You first need to request an access_token (i.e.: authorization_code flow). You may need to include the scope offline_access to have a refresh_token included in the response. Once you received it, you can use the refresh_token grant_type. I hope this helps.
Refresh token goes invalid after 7 days. Do you have any suggestions to get new refresh token or access token without re Authorization?
Hello Debu, I missed your question! Unfortunately, when it is expired ... it is expired and a new access- and refresh_token have to be requested. One way out could be if the target authorization server accepts id_token_hint and your client could provide one. Sometimes an id_token has a longer lifetime and with that it may work (instead of requesting username,password of the user). I hope this helps
@@saschazegerman dedicated video?
@@debu4118 Have you tired my video about id_token? That may explain it in detail
sending refresh token with each resource request invalidates the idea of refresh token .. refresh token shouldn’t be used a lot
That is correct, Ibrahim! But refresh_token are never send to resources servers, only to the authorization servers and only if the access_token has expired. I hope that my video does not create confusion about that!
Hi can you provide any sample code
Hello Ashoka! Are you looking for code that uses the refresh token flow, exchanges an existing refresh token for new one?