Signing out should reset the authentication token about simple_token_authentication HOT 14 OPEN

Thanks @gonzalo-bulnes. Based on @austinpray's response, I think this should be an option, since it would break the multiple-devices use case. I'm not sure yet whether it should be on or off by default.

A more thorough solution would be to have multiple authentication tokens per user, one for every device, and signing out would only destroy the one that corresponds to the current device. However, I expect this would be beyond the scope of a 'simple' gem, and I personally have no need for that particular use case right now.

from simple_token_authentication.

Hi @dmdeller! What do you think about using several authentication tokens per-user? (Reply here please!)

from simple_token_authentication.

@gonzalo-bulnes Please see my previous message.

from simple_token_authentication.

Before we go any further: @dmdeller what exactly are you trying to accomplish by resetting the authentication token after a user signs out? What issue does this solve?

from simple_token_authentication.

The issue is that sign out currently does nothing (for API clients).

What do we expect sign out to do? To a user, sign out means: this device can no longer access my resources on the server. But currently, that's not true. In fact, sign out does not affect an API client whatsoever; there is no point in an API client ever requesting to sign out because everything is exactly the way after the sign out as it was before, as far as the API client is concerned.

At the most basic level, this violates the principle of least privilege: a program must only be allowed to access the resources that are necessary for its legitimate purpose. After a user has signed out of a device, there is no longer any legitimate purpose for the device to access any resources, until the next sign in. Therefore, it should not be allowed.

As a purely practical matter, if we assume the API client (and underlying operating system, and hardware device, and connected networks) are always bug free and completely trustworthy, then there is no need to restrict its access. But those are not good assumptions.

from simple_token_authentication.

That makes sense to me.

from simple_token_authentication.

So you are concerned that the API client will not clear the token from it's local store (cookies, localStorage, etc.) and then someone can then access that user's account by getting the cookie or localStorage data? Or someone steals the token and uses it even when the user has signed out?

I mean, if the user's computer is compromised there is nothing anybody can do to prevent the attacker from gleaming login credentials. Why would the attacker bother with the token when they could just get the user's login and password? Then even with our complex sign in and sign out system the user can just generate their own good token from the user's login and password. If the user suspects their computer has been compromised, they should just reset their password (which should change both their password and their token).

After a user has signed out of a device, there is no longer any legitimate purpose for the device to access any resources, until the next sign in. Therefore, it should not be allowed.

If the API client successfully deletes the auth information, the API client has no access to make authenticated requests. If you are worried about garbage collection then the token should have a TTL or something.

I will go back to the fact that people have a ton of different devices they use on a daily basis. Clearing the token on logout would invalidate all token-based auth sessions across all the user's devices. This is DOA for apps that have perhaps an iOS app and a responsive web app running off the same API.

A unique token for each device would work, but it would have to be implemented such that the device has no knowledge that the token it has is unique to that device. The API client side should work such that it:

• sends correct login info to the server and sent a token in response
• stores the token
• sends the token along with requests to authenticate them
• deletes the token when the user decides to end the session

No logic on the API client side should have to exist to handshake or to establish the device's identity, because that can be exploited anyway.

Deleting the singular token on sign out should at very least absolutely not be a default behavior. A reusable helper or something like refresh_user_token that can be manually added to a logout action on the session controller would be harmless however. Or some sort of configuration option.

from simple_token_authentication.

Is it safe to just destroy/erase the token from the client?

In the case of a browser and mobile client I do believe that signing out on the browser should not affect the mobile. At the same time signing out on the browser or mobile should stop any and all users from using the api without sending the email/password again.

from simple_token_authentication.

@Rotimi As I see it, yes, destroying the client token on sign out is enough (but it strongly depends on what you expect from your service, see the last autinpray versus dmdeller comments). Why?

I would start asking who wants their sessions to be destroyed on signout so nobody (even with access to their browsers mobile apps) can acceed their data. Users, of course. Who owns the client app, or browser? Those same users. In this case, there is no conflict of interests and the client apps, in order to provide a good service, should ensure they destroy all trace of the authentication tokens once users sign out, and that until users sign in again and the client receives the (same) authentication token again from the API. Users can trust their client apps, because they own them. That's pretty much the austinpray point.
Now, if you asks me, I don't find that the dmdeller lacks of sense, but that's a very different vision of the API, where the users perceives the service as a safe that they can lock or unlock by signing in or out, but that always protects their data from any access when locked (even from previously authorized devices). The discussion is open.

The password change, for example, is a different case (and there is no debate about it) because it goes beyond the user-client couple. A password change should affect all clients, and therefore involves the API. That's why a password change should reset the authentication token server-side (which is a pending issue, see #26).

from simple_token_authentication.

@gonzalo-bulnes sorry if I've misunderstood (I've read all of the related issues)--what is the proper way to sign out? I don't see anything in the source allowing for sign out--so is that just up to the client? In that case, seems like a third party could just stay logged in forever.

I KNOW I'm missing here, so excuse my obvious ignorance.

from simple_token_authentication.

Hi @TrevorHinesley,

Unless you're explicitly using the sign_in_token option (typical use case: a sign in link sent in an email), using valid authentication credentials (by default authentication token + email) does not create a persistent session.

That means that the API clients have to provide the token in every request. Of couse, if a third party does get access to your credentials, they can impersonate you. To prevent that, HTTPS should always be used when authenticating using tokens.

That being said, nothing prevents you from re-generating the authentication tokens regularly. The good part here is that they are much less painful to renew than the user's passwords (the users would need to sign in again using their client to get the new tokens, but that's all).

Does this make sense to you?

from simple_token_authentication.

Ah yes that makes sense. So "sign out" on the client side would be just that--don't send the email and auth token with further requests. Correct?

from simple_token_authentication.

Correct. A well-behaved client would also forget the authentication token, since it will get it back (the same or a new one) when the user signs in again.

from simple_token_authentication.

Awesome, thanks so much @gonzalo-bulnes. Very helpful.

from simple_token_authentication.