Open sustained opened 5 years ago
@sustained Do you need more info on this or should this be closed?
Well the discussion was somewhat enlightening. I too thought refresh tokens were an inherent part of the JWT spec. I didn't realise they are a custom thing that most implementations add.
But one of the comments in there has me wondering...
As I know access tokens and refresh tokens should be stored differently too on the client side. Access tokens can be "not as securely" stored as refresh tokens. What happens if let's say hacker gets access token from you? They can refresh and refresh it forever am I right? Can anyone explain it to me why we only have access tokens here and not using refresh tokens? I think it's very insecure...
Like, if a "hybrid" access/refresh token from this library leaks then they can refresh forever. However, in an implementation where the concept of access and refresh are separate, if the access token leaks then while that is certainly a bad thing it's not as bad as it could be, since it will expire after some time and at that point the leaked access token is useless.
So is this library's implementation less secure then? :thinking:
I think its more implementation dependent.
Like in my projects the web token is limited to the server side and never gets exposed or sent in anyway to the front end. I store it in a memory store and the encrypted session has a randomized password to access it.
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Isn't that the way this usually works? You get an
access_token
AND arefresh_token
? It seems like this library is doing things differently to most others, how come?