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
Related
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.
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.
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?
I am creating an ember app that has devise worked in for authentication. I'm really getting stuck with how all these different tokens come into play.
I'm reimplementing the recently deprecated :token_authenticatable devise "strategy" using the method described here. I'd like to add token authentication to my API and sign requests to that with the user's token.
What I'm wondering is, even though it's using Devise.secure_compare to thwart timing attacks, it's still storing the authentication_token in plain text, so if anyone were to gain access to the database, those tokens could potentially used to steal a session, no?
Devise seems to use two different types of "tokens" in the modules:
Creating a token with Devise.friendly_token and storing it as plain text. Then doing a look up by this token (as used in :rememberable).
Creating a salted token with Devise.token_generator (as seem in :confirmable).
The second method looks to me like the token is salted using Devise.secret_key which is derived from the Rails secret in config/secrets.yml. That way the token is encrypted and if the database was exposed for some reason, the tokens couldn't be used, right? Would be the equivalent of having a private key (rails secret) and a public key (authentication_token).
I have quite a few concerns:
Should I use Devise.token_generator to create my authentication_tokens?
What is the word on security for these type of tokens?
How does the CSRF token factor into Devise?
Devise does a lot of things, and not necessarily the things your particular application needs or in the way your applications needs. I found it wasn't a good fit for my application. The lack of support/removal of api token authentication provided enough motivation to move on and implement what I needed. I was able to implement token auth from scratch fairly easily. I also gained full flexibility for managing user signup/workflows/invitations and so on without the constraints and contortions required of Devise. I still use Warden which Devise also uses for its Rack middleware integration.
I've provided an example of implementing token authentication/authorisation on another stackoverflow question. You should be able to use that code as a starting point for your token authentication, and implement any additional token protection you require. I'm also using my oAuth token approach with Ember.js.
Also consider if encrypting tokens is just hand-waving because depending on your deployment environment and how you manage your master key/secret, it may be giving a false sense of security. Also remember that encryption says NOTHING about the integrity/validity of the token or related authentication/authorisation information, unless you also have a MAC/signature that encompasses everything used in your access decision. So whilst you may go to the trouble of protecting tokens from attackers whom have access to your database, it may be trivial for those same attackers to inject bogus tokens or elevate privileges for existing users in your database, or just steal or modify the real data which may be what they really want to achieve!
I've made some large comments in respect of providing integrity and confidentiality controls for ALL authentication/authorisation information (which tokens are part of) on the Doorkeeper gem. I would suggest reading the full issue to get an idea of the scope of the problem and things to consider because none of the gems currently do what should be done. I've provided an overview on how to avoid storing tokens on the server altogether and I've provided some sample token generation and authentication code in a gist which also deals with timing based attacks.
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.