Should acquiring a token automatically sign someone in? about simple_token_authentication HOT 3 CLOSED

Hello @huttneab!

I'm glad youre finding simple token authentication useful : )

Warning: I'll give you my vision of how token authentication should be used (and how I use it), but please do notice that I may not be the most qualified to respond your question and I think that, if you didn't already do so, you should consider to post it in this conversation. A lot of great people are discussing there and theirs insights would be interesting to have.

Short response: Yes, having an API endpoint which receives a user_email, user_password pair and responds with an user_email, user_token pair each time the password and e-mail do match is how I envision this gem usage.

Then, the (well-named) authentication token really is what authenticates the user, and any request to the API with a valid authentication token triggers the creation of an user session (via the Devise sign_in method).
From your backend point of view, that means having a Devise current_user, and being able to enforce authorization as you always do (e.g. via Cancan, Protector), or any other tools you usually work with.
That also means that anyone who gets access to your user email and token can act on her behalf.

Since we often want the API clients to store their authentication tokens (so users don't have to sign in before each request), I believe that they MUST be provided a way to renew their authentication token and invalidate any previous one. Of course, not anyone should be able do do that because that could lead to a kind of I'll won't let you keep signed in attack. Only authenticated users should be able to reset their own token (and only their own token).
There is an easy way to do that: provide a sign out API endpoint, protected by token auhtentication, which erases the current user authentication_token. Once an user signed out, her old authentication token is turned into garbage and can be safely lost or deleted by her client application. That solves the first half of renewing your authentication token as an user (make the previous token invalid).
The second half (getting a new token) is provided out-of-the-box by the simple token authentication gem, since a new authentication_token is generated each time a user signs in without already having one.

I hope that helps, if you have a few minutes and get other responses, please keep me posted!

from simple_token_authentication.

Hi Gonzo - thanks for providing this gem, its great. I have a couple questions that piggyback off of the above description.

I think it is spot on, just want your advice for one part - "here is an easy way to do that: provide a sign out API endpoint" - OK done - but it'd be nice to take it one step further to say "if user is logging in via the API with email / password (instead of normal API requests of email / auth token), than re-new the token." Do you think this is possible?

This comes into play where you have a website with normal devise auth, and an API for mobile devices (or whatever) using your token auth. When a user gets a new device, it'd be nice for them to just log-in on the new device setting a new token (not reusing the old one to prevent multiple devices at the same time) and eliminating the need to manually revoke the token as described in your sign out end point. The catch is you don't want to reset the auth token on normal website/devise logins, only on the API login requests.

I hope this makes sense, and was just wondering if you have any suggestions as to how to tackle this before I dive under the hood. Thanks!!

from simple_token_authentication.

Hi @halpimded,

I'm glad you find the gem useful. So you want to prevent users to sign in from several mobile API clients at the same time. The question, I think, is how can we identify the email / password calls to the API that come from these clients. In order to make it easier to find I've created a dedicated issue: #24. I continue there.

from simple_token_authentication.