Skip to content
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

Closed
calvinmetcalf opened this issue Apr 9, 2015 · 5 comments
Closed

Keep me logged in functionality #43

calvinmetcalf opened this issue Apr 9, 2015 · 5 comments

Comments

@calvinmetcalf
Copy link
Contributor

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?

@hoIIer
Copy link
Contributor

hoIIer commented Apr 12, 2015

@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?

@calvinmetcalf
Copy link
Contributor Author

So not really, the benefit of json Web tokens is that you don't need to
keep track of issued tokens allowing you to avoid redis or similar. When
you add a black list you've got to use a redis db or similar and well then
why bother using json Web tokens if you already have access to redis?

To step back for a minute the reason we've been using json Web tokens is
we've traditionally done stuff on aws with elasticache but have recently
done stuff on Google Compute Engine which doesn't have something equivalent
so we couldn't use that to keep track of sessions between instances so we
switched to Web tokens.

The other side of the issue is that we want to avoid hitting the database
on every single request (we do mapping so when we have tile servers they
can make huge numbers of small requests) but we want to make sure changes
to privileges and info to keep up to date. We could only keep the
username in the jwt and check that against the db but cache the result but
we'd have no ability to communicate that to the client.

On Sun, Apr 12, 2015, 12:19 AM Eric Honkanen notifications@github.com
wrote:

@calvinmetcalf https://github.com/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?


Reply to this email directly or view it on GitHub
#43 (comment)
.

@hoIIer
Copy link
Contributor

hoIIer commented Apr 13, 2015

regarding blacklisting, this article sheds some light on the thoughts behind it

@calvinmetcalf
Copy link
Contributor Author

So I don't think black listing + love g expiration method is going to work
right for my use case. Especially as it would mean that if you granted a
user an additional privilege it would log them out.

A better way to state what I have in mind is that 2 tokens would represent
2 separate things.

The refresh only (long lived) token would represent authentication, that
the holder of this token is identified as x user due to them presenting the
correct password. It's main function would be allowing the user to not have
to log in each time they navigate to the site and could be tied to the user
agent/ip/etc.

The non-refresh (short lived) token would represent authorization, this
user is authorized to claim these things (is an editor, may view this page,
etc).

Imagine you had an rpg, I'd the token only recorded the character's name
and race having a black list approach would work great because those things
would rarely change so the only change you'd need to worry about is banning
the character if they got caught cheating.

Now of the token also had a he characters class that black listing would
work less well because it means that user is logged out if they multiclass
or change classes.

It would be even worse if if you tried to store character level. While you
could include a new token in the response that would still log you out from
other devices if you where also playing on your phone.

To sum up it seems like blacklisting is a good strategy if the privileges
of a user are only ever going to decrease, but would present problems if a
user's privileges are likely to change horizontally or increase.

On Mon, Apr 13, 2015, 12:32 PM Eric Honkanen notifications@github.com
wrote:

regarding blacklisting, this article
https://auth0.com/blog/2015/03/10/blacklist-json-web-token-api-keys/
sheds some light on the thoughts behind it


Reply to this email directly or view it on GitHub
#43 (comment)
.

@quiddle
Copy link

quiddle commented May 15, 2015

I'll add that another benefit of using JWT is that the token can contain pertinent information to the client application. The sub field might contain the user_id that is then used to access a specific page. It also might contain scopes that indicate what access rights a token has. This could be used application side to reveal admin features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants