I'm building a rails app and I want to have token authentication but I don't want to build a separate API, I want it to be all integrated into one rails app.
Is this possible? Every single tutorial about token authentication I can find is about APIs, and every API seems to need to be its own standalone entity running in parallel with the main app.
Is what I'm asking impossible, or stupid? If not, how do I do it?
For "classical" web applications you want to use session based authentication instead of tokens.
Token based authentication is stateless and requires the token to be sent along with every request. This is done via HTTP headers or by placing it in the request body. Which is how you use API's.
For a classical web application there is simply no practical way to send the token along on GET requests.
Session based authentication instead works by using cookies to store the authentication claim (usually a user id). While you could use a token and store it in the session its just an overly convoluted solution since it defeats the whole purpose of token based auth.
Related
I'm using devise_token_auth for a rails application with react on the frontend and rails as the backend acting as the backend.
In the readme the author states that
If you're building SPA or a mobile app, and you want authentication,
you need tokens, not cookies.`
Why? I understand the basic differences between tokens and cookies, but don't understand why you couldn't just use cookies (simply including the headers with any XHR requests)?
There are a few major reasons.
First of all most SPA's are designed as stateless and using cookie based authentication is not stateless. Using cookies also makes every request take a little bit longer because there is a lookup on every request.
Cookies are also tied to a domain. Most SPA's use multiple services across multiple domains which is a no go with cookie based authentication. This also applies to SPA's which have a web app and mobile app, using token based authentication means scaling this is much easier.
Tokens can also be used to store data and only need to be generated once, after that there is no work involved except for the server reading the token. This means you can store user permissions in there etc and the server can get this information with very little work.
I have a rails web which has been using cookie session authentication (devise) from its beginning. Now, we are developing an ionic mobile application which uses the API available from the rails application.
I have considered to use JWT or token authentication for this new application but I can't find a way to combine both authentication methods, cookie and JWT. Also, both applications have different requirements. For example, in the web a user can have concurrent sessions only if he/she has a certain role. On the opposite, in the mobile application it is possible to have concurrent session without any restriction.
I have reading a lot trying to figure how to combine both methods but I can't find the way. Maybe I should consider to use only one of the methods (JWT) or use another approach (doorkeeper).
Finally I have found a solution. According to refaelos and Zac Stewart, I have combined devise with JWT gem, using the last as a new strategy for the first. By this way, when I don't use JWT tokens, devise will choose the default strategy (database_authenticatable in my case). Otherwise, it will use JWT strategy.
However, when the user is not authenticated and make a post request to Session#create to get the credentials, the strategy chosen by devise/warden is database_authenticatable. In order to avoid this, I needed to add a new parameter to the request but only for this case because, as I said, when the token appears in the request, the new strategy is selected.
See also:
An Introduction to Using JWT Authentication in Rails
I am building an API and I'm stuck at the authentication part. I will try to explain what I have and what I'm trying to accomplish:
First, the API is closed to the public, it will only be used on the admin's back-end and for 3rd party devices in the company.
I have a model called Member that is being used with Devise for authentication
I'm also using STI to distinguish between 3 levels of users (using CanCan for roles)
What I thought:
I tried the Token authentication by Rails, it worked but I was afraid of expose the token in each Ajax request, I don't know if I was right.
I also tried to use a '/token' route to post my credentials and get a token, but I was facing the same problem in a more complicated approach. The link with the tutorial
I don't wanna use OAuth because it's unnecessary for that kind of application.
Is it secure to use this token authentication with ajax requests or is there a more secure way to prevent people accessing my API?
Token authentication needs to be done over a secure connection.
If for example you are using Heroku, it is possible to use
their credentials to gain a HTTPS url. With this the contents
will be encrypted and so exposing the token through JSON
over the API will be acceptable.
I am developing an ASP.NET MVC web application. The application is consuming a REST API, but authentication for REST-full application is quite unclear for me.
As REST is stateless, do I have to implement two different Authentications with two different databases, one for client, and one for the REST service?
Or, do I have to send the login/password each time, to authenticate on the server?
Please give me some advice or tutorial on this.
You can authenticate a Web API using individual user accounts that are stored in a database.
In this case client should obtain access token first. And then include it to each request, that requires authorization, header:
Authorization: Bearer boQtj0SCGz2GFGz[...]
Good tutorial can be found HERE
Also authentication methods could be extended in Startup.Auth.cs with Cookies or some external authentication methods (Google, Facebook etc)
The stateless isn't a main problem in your situation, problem is that browser can only send GET or POST request in tradition way in tag form, so to send PUT or DELETE request you should use Ajax, the easiest way is to use JQuery library and config it to send user credentials in http header(between requests it can be store in cookies) in every request and use basic-authentication if you plan use own auth logic. I recommned you to look some SPA frameworks like angularjs
or emberjs
or backbonejs
to simplify your life from hardcode JavaScript . Also in future you can easy extend your auth by OAUTH 2.0.
I'm building a Rails app on Heroku.
I installed devise to manage user authentication on which I wanted to add "token authenticatable".
I basically used this tutorial and it works great
However, I ran across more complex tutorial about token authenticatable like these two ones:
http://matteomelani.wordpress.com/2011/10/17/authentication-for-mobile-devices/
http://mojoware.com/posts/mobile-rails-api-with-devise
I don't understand why they get much more complex than what I implemented? They seem to mention "mobile" stuff so does that mean it's a more complex way to use "token authenticatable" because it allows to authenticate in more cases of use such as on mobile?
Really in the dark so I appreciate any help.
For the most part, authentication in a (native) mobile app works pretty much the same way as authentication through a browser: the user gives his credentials, these are sent over the wire to the server/app, and the app responds by giving the user a 'token' representing an authenticated session.
The main differences: browser-based clients will generally submit said credentials using HTTP POST of an HTML form, using application/x-www-form-urlencoded. The returned token is usually given as a session cookie, which the browser presents with every subsequent HTTP request.
Native mobile clients, on the other hand, while functioning as the browser aren't restricted to the HTML way of doing things, and most of them don't use cookies.
The typical mobile client uses a Web service API. Most APIs are designed to be as stateless as possible (unlike browser/cookie-based sessions).
Most Web service APIs also need/want to be able to send & receive as much hierarchical, complex data as possible, using as little bandwidth as possible. Hence, they favor more compact representations of structured data such as JSON (or in some cases, BSON).
In most cases, as well, it is undesirable to present the authentication token as a URL query parameter (or, if you're sending over a JSON payload you might as well include the token in there).
For that reason, the stock Devise session controller and token authentication mechanism is inadequate, and hence numerous examples of how to provide alternative, REST-ful or JSON-based authentication that extends Devise.