devise vs. devise_token_auth: How to handle authentication for both a web app and API - ruby-on-rails

I'm writing an application that will primarily be accessed via API, but will also have views for editing via web app.
I would like to create a User model with authentication and authorization across both platforms.
I'm having trouble understanding the relationship between the devise and devise_token_auth libraries, other than that the former is recommended for most rails apps and the latter is great for API-only authentication.
For my case, what is the appropriate library to use, or should I be using both? Should I be generating the User model via devise and then adding the token auth to it? Do both systems use different authentication schemes? I'm just trying to understand why devise_token_auth exists apart from devise.
I'm also just a bit confused about the added complexity of token-based authentication. What would be wrong with simply having the users be registered and managed through devise, generating an API secret key for them, and then having them sign their API requests with that. Why the need for token based auth in the API?

devise_token_auth is an advanced method of API authentication which may, or may not, be overkill for your application. Essentially, a new token is generated for each API request.
Depending on what your needs are, you may be fine with token-based authentication, or perhaps even HTTP Basic auth, which devise supports out of the box.

Related

API only Ruby on Rails 5 implementing OAuth2 (preferably with devise and doorkeeper)

I want to make a JSON API with Rails 5 that will feed an angular app and possibly later mobile apps. I do not want to include any html in the rails application. I typically use devise to handle user creation and authentication in regular rails apps. I would like to implement an OAuth2 compliant flow so I found a gem called doorkeeper.
I like devise as it handles the sending of a confirmation email and password reseting, etc. I would like doorkeeper to keep my app OAuth2 compliant.
My issue is that the OAuth2 documentation says to try to not use the password grant type but I cannot find a better alternative method for a site being served by the same server the API is coming from. Should I require a CSRF token only for the OAuth route to acquire the access token to ensure the request is coming from the site? Should I use the CSRF token from within the angular app the entire time in conjunction with the access token?
Also should I have devise handle the sending of the access token? How would that work in the other flows besides password grant? I would also have to edit devise to only accommodate JSON requests and to respond in kind.
Also I would like to implement a JWT however I still think it best to have the token linked to a session ID, I know the kind of defeats the purpose of the JWT but I think its beneficial to use the JWT in order to accommodate native apps.
I am sure this is not an uncommon thing to want to set up nowadays but I have yet to find a solid walkthrough connecting devise, doorkeeper, and an API only setup. Has anyone experienced and implemented a something like this?

Rails Devise token and cookie session at same time

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

How to secure access to rails server which provides REST API access

How to secure access to rails server which provides REST API access.
We use Devise for authentication.
Our Rails app talks to another Rails server (Service App) and we would like the user to authenticate before accessing the Service App. Should I do it via device authentication token. Kindly advise? What should be done at the service level
https://github.com/plataformatec/devise
https://github.com/lynndylanhurley/devise_token_auth
Well, it depends of your app architecture.
You can use devise to authenticate users at REST API.
But if your Service App is for internal use only, for example it provides data only for another app, you can restrict access by ip, or Basic HTTP auth.
My opinion, that devise is good only for authorising end-users, but not services.
In my opinion, this question is highly opinion based as it stands at the moment.
What is the purpose of the Service App? Does your Rails app consumes frequently from the Service App? Or the other way around? Is it just for logging purposes, like statistics or tag-like resources or critical data like credentials?
From my rule of thumb, if an actual end-user needs to access it to modify a resource (POST, PUT, DELETE) I'd go for token based authentication. If it only needs to read, I might just go with just Basic or none at all, depending on the context.
Either way, I would consider twice if Devise is the precise tool for your own scenario. More than few times I have found myself writing more to actually modify Devise than it would be necessary if I implement my own authentication system. It's not that hard and you learn a lot!

Better and simpler solution for API 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.

Omniauth, Devise, Open ID, CanCan - Whats what and When do I use which solution for a Rails API app

So Im developing a Rails app- primarily serves API which I want to lock down behjind a nice authorization system. Ive created Rails apps which render HTML and for that I used Devise and CanCan. This time I want to serve JSON to my clients. I basically have the following requirements:
Need an authorization system thats robust
A user should be able to log in with existing apps such as facebook, twitter, linked in and google
There should be full stack authorization available
Now this is my 1st app that Im writing that serves up API so I started researching and so far Ive found the following solutions that people have used:
I've seen people use Devise with CanCan
I've seen people talk about using Oauth2
http://railscasts.com/episodes/353-oauth-with-doorkeeper?autoplay=true
I've heard... "Use Doorkeeper"
I've heard use ..." Use omniauth"
So basically my 1 day of research basically just confused me more. When di I use these and for my requirements which comnbination would I use! Im struggling to make sense of the alphabet soup, can someone help me understand this
Devise is an authentication engine for Rails apps of all types. Devise allows authentication against username/password, token authentication (good for API's), and an oauth provider (such as Google, Facebook and the like). This obviously allows you to deny access to the API unless the user is signed in through one of the services you offer.
CanCan is an authorization system that will work on top of Devise to allow users access to certain parts of your system based on their role within the system. CanCan has a very slick DSL prviding can and cannot methods for allowing or denying access to views or controller actions.
Doorkeeper is an oauth provider gem if you wanted to roll your own oauth solution on top of your API. This would be if you wanted your application to act in the same manner as Google or FAcebook in providing an oauth endpoint for users to authenticate against. From what you stated above, I don't think this is the case.
Given the requirements you provided above, I believe that Devise and CanCan would be the route that I would choose. This would allow the user to authenticate at first by username/password, or some oauth provider, then allow token authentication after that to access your API. You can then lock down access to specific actions through CanCan.

Resources