[Question] How can I force 'loggout' a user from server-side? #15

Closed
ricsdeol opened this Issue Oct 31, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@ricsdeol

No description provided.

@ricsdeol ricsdeol changed the title from [Question] How can I force 'loggout' a user from server-side! to [Question] How can I force 'loggout' a user from server-side? Oct 31, 2015

@nsarno nsarno added the question label Nov 1, 2015

@nsarno

This comment has been minimized.

Show comment
Hide comment
@nsarno

nsarno Nov 1, 2015

Owner

The bad news: there isn't a way to do this out of the box with JWT.

This is due to the fact that token based authentication is sateless. Which means we don't manage state (e.g. "is the user logged in") server-side, unlike a session does for example.

The benefits in term of simplicity and scalability of having a stateless API are significant, and in my opinion worth sacrificing a feature like force logout.

Trying to re-implement such a feature with a token blacklist for example is not a great idea as it means reintroducing state into your API, which makes token based authentication way less interesting.

A good alternative would be to keep token expiry times short and rotate them often.

Now the good news: I think there is a good way of implementing this.

Instead of storing the user id inside the token, you could store another field like a randomly generated unique lookup id. By changing this lookup id, you automatically invalidate any token previously generated for this user.

For the moment, knock always stores the id inside the payload. I'll make a quick change to allow this to be configured.

Let me know if something is unclear!

Owner

nsarno commented Nov 1, 2015

The bad news: there isn't a way to do this out of the box with JWT.

This is due to the fact that token based authentication is sateless. Which means we don't manage state (e.g. "is the user logged in") server-side, unlike a session does for example.

The benefits in term of simplicity and scalability of having a stateless API are significant, and in my opinion worth sacrificing a feature like force logout.

Trying to re-implement such a feature with a token blacklist for example is not a great idea as it means reintroducing state into your API, which makes token based authentication way less interesting.

A good alternative would be to keep token expiry times short and rotate them often.

Now the good news: I think there is a good way of implementing this.

Instead of storing the user id inside the token, you could store another field like a randomly generated unique lookup id. By changing this lookup id, you automatically invalidate any token previously generated for this user.

For the moment, knock always stores the id inside the payload. I'll make a quick change to allow this to be configured.

Let me know if something is unclear!

@nsarno nsarno closed this Nov 1, 2015

@ricsdeol

This comment has been minimized.

Show comment
Hide comment
@ricsdeol

ricsdeol Nov 1, 2015

@nsarno your was clear thanks!!!

About a way of implementing this.
The lookup where it could be save?
What do you think of saving the token in the database?

ricsdeol commented Nov 1, 2015

@nsarno your was clear thanks!!!

About a way of implementing this.
The lookup where it could be save?
What do you think of saving the token in the database?

@nsarno

This comment has been minimized.

Show comment
Hide comment
@nsarno

nsarno Nov 1, 2015

Owner

The lookup where it could be save?

I would store the lookup id as another column in the user table.

What do you think of saving the token in the database?

This is not a good idea. It means an additional database query for every request. It also greatly reduce the benefits of not having to manage sessions. One of the biggest pros of using tokens is that you can tell if they are valid or not without storing them on the server.

Owner

nsarno commented Nov 1, 2015

The lookup where it could be save?

I would store the lookup id as another column in the user table.

What do you think of saving the token in the database?

This is not a good idea. It means an additional database query for every request. It also greatly reduce the benefits of not having to manage sessions. One of the biggest pros of using tokens is that you can tell if they are valid or not without storing them on the server.

@nsarno nsarno referenced this issue May 19, 2016

Closed

Revoking a token #71

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment