Keep me logged in functionality about ember-simple-auth-token

[hoIIer]

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

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 [email protected]
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]

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

[calvinmetcalf]

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 [email protected]
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]

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.