Can I use token authentication with an API without sending the e-mail and token in every request? (R: Yes, but maybe you shouldn't.) about simple_token_authentication HOT 7 CLOSED

Hi @rafaelcgo your question is fine here, I prefer questions to be accessible afterwards so anyone can take advantage of them : )

The typical sign_in_token option use case involves a web app, not mobile devices. However, AFAIK, it should be possible to use it as long as you can store a cookie on each involved device.

Let's look at the typical use case as an example: I have sent an email to some webapp users, which contains a link to whatever private page I want them to visit (let's say they should approve or reject a special offer). Of course, I want to make their experience to be as seamless as possible, and I don't want it to be bloated by an intrusive sign in page between the e-mail and the action I want them to take.
At this point I add the sign in token to the link; when they open it, before the private page is displayed, their session is created automatically and stored by their browser (as a cookie, here's the whole point). Once that done, they can take the action I want them to take, and continue browsing using the app until they decide to sign out.

In conclusion, if you can store the cookie in your mobile device and use it to persist the session, then that should be sufficient to identify it. ¿Does that make sense to you?

from simple_token_authentication.

That beign said, @rafaelcgo, if you can avoid persisting sessions in your communication with the API, I think you should. A REST API should be stateless, and depending on a stored state use to be considered as a bad practice.

Not using the sign_in_token option doesn't mean your users will have to sign in continuously. The idea is asking the users to signin once (that's to say: give their email/pawword to your app), use their email/password (from the app) to obtain their authentication token from the API (they should be sent in the response to the successful sign in request) and store that token (not the password!) in the app. Subsequent requests will be authenticated sending the email/authentication token of the user into the request header, or as query params.

That way, you don't share any stored state with the API. From the API point of view, authentication is performed on each request (via the authentication token), and your users don't have to sign in again until after they sign out, which is what the token authentication is for in the first place, and is also the default behaviour of Simple Token Authentication : )

from simple_token_authentication.

@gonzalo-bulnes That was my first approach, but I was thinking in use something like a session to prevent db lookups for each API request.
But you're right. REST connections should be stateless.

I'm gonna create a solution from scratch using the built-in rails token authentication method.

Thanks for the clarification!

from simple_token_authentication.

Hi @rafaelcgo,

You're right, there is a trade-off between the database lookups number and the session storage. In the case of an API, I personally prefer to use token authentication on each request.

I confess I didn't undertand which feature was missing from Simple Token Authentication.
To me, the scenario you described seemed to match the gem default behaviour, but I must be missing something : S

Anyway, there is nothing wrong about writting whatever from scratch, much on the contrary.

Regards!

from simple_token_authentication.

@rafaelcgo, if you haven't seen it, the question #45 may be interesting to you.

from simple_token_authentication.

@gonzalo-bulnes Thanks.

I'm using an approach VERY SIMILAR to https://gist.github.com/gonzalo-bulnes/9001010 to login via API and them just authenticating token via authenticate_with_http_token.

from simple_token_authentication.

Cool, I'll close this issue, ok?

from simple_token_authentication.