search

fenichelar / ember-simple-auth-token

Ember Simple Auth extension that is compatible with token-based authentication like JWT.
MIT License
348 stars 139 forks source link

Keep me logged in functionality #43

Closed calvinmetcalf closed 8 years ago

calvinmetcalf commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 https://github.com/jpadilla/ember-cli-simple-auth-token/issues/43#issuecomment-91985091 .

hoIIer commented 9 years ago

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

calvinmetcalf commented 9 years ago

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 https://github.com/jpadilla/ember-cli-simple-auth-token/issues/43#issuecomment-92419025 .

quiddle commented 9 years ago

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.