-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep me logged in functionality #43
Comments
@calvinmetcalf Interesting concept... I'm not too familiar with OAuth2 but I did notice they had a concept of access token / refresh token, is that at all similar? Can you explain more of the use case for this? Also something missing that I am thinking to add is token blacklist/revocation (if backend supports it), would that tie into this at all? |
So not really, the benefit of json Web tokens is that you don't need to To step back for a minute the reason we've been using json Web tokens is The other side of the issue is that we want to avoid hitting the database On Sun, Apr 12, 2015, 12:19 AM Eric Honkanen notifications@github.com
|
regarding blacklisting, this article sheds some light on the thoughts behind it |
So I don't think black listing + love g expiration method is going to work A better way to state what I have in mind is that 2 tokens would represent The refresh only (long lived) token would represent authentication, that The non-refresh (short lived) token would represent authorization, this Imagine you had an rpg, I'd the token only recorded the character's name Now of the token also had a he characters class that black listing would It would be even worse if if you tried to store character level. While you To sum up it seems like blacklisting is a good strategy if the privileges On Mon, Apr 13, 2015, 12:32 PM Eric Honkanen notifications@github.com
|
I'll add that another benefit of using JWT is that the token can contain pertinent information to the client application. The |
Currently you have a choice between having a long refresh interval on the tokens but having no way to update information on the token or you can have a short refresh interval but then the user has to login again frequently. I had an idea for a way to get the best of both:
On login with credentials instead of getting a single token you'd get 2, one would be the same as the current set up, it would have a short expiration but have an audience value that made it valid for making requests on the site but not valid for refreshing. The other token would have a much longer expiration but would have an audience that make it only valid for being used to refresh tokens to get new ones.
I.E. the short token could be valid for an hour and the long one for 2 weeks. But that means that if you deleted a user they would still be able to login for another hour but even though they have a valid long token they wouldn't be able to trade it in to get a new short token.
Thoughts?
The text was updated successfully, but these errors were encountered: