[Possible Feature Request] Questions about a "new" mechanism for authentication / session handling
Hamza Mahmood
[I am looking for a reliable authentication mechanism for rails-api/SPAs and I am wondering about the addition of a "TokenStore"]
Hello Rails,
I have been using Rails 4 for about two years and have found it to be very reliable.
For a newer projects, because of the SPA (Single Page Application) trend, I have decided to try rails 5's api mode.
However I find myself in an unsure position: while in "older applications" Devise was "the go-to" solution, for SPA and rails-api, there is no clear solution.
Before proceeding, I'd like to state one strong conviction I have: security related code should be "battle tested" - and one way to achieve this is to have a solution used by a majority of developers (as Devise is/was).
---
Searching for "rails api authentication", and especially "rails api token based authentication" yields many hand-rolled solutions. These solutions seem to be divided in two groups.
The first group's implementations mostly use rails' authenticate_with_http_token or variants of https://gist.github.com/josevalim/fb706b1e933ef01e4fb6 (by one of the authors of Devise). The better ones seems to mitigates timing attacks.
Beside the fact that most of these solutions don't seem to have the backing of any strong community, I find the absence of (out of the box stateless) sessions troublesome. I also can't help wondering about the consequences of using random but unsigned tokens (but I have failed to find any relevant resource on this matter).
The second group's implementations build on the somewhat "newer" JWTs (JSON Web Tokens), and a few gems seems to be gaining traction. While JWT provide a (stateless) session, it is not encrypted and JWEs (JSON Web Encryption), which could solve this issue, do not seems to get much attention by the (ruby) community. I also have the impression that JWTs have a certain complexity associated to some extra power they provide.
---
In Rails 4, the use of encrypted (and signed) cookies became the default. I found this feature to be quite simple (of use), reliable and quite handy at times. Looking at the code, I find it very clear, and looking at github's issues, I can see that many aspects have been discussed, involving may developers and security experts.
I can't help, but think about using this code to generate a signed and encrypted token, and sending it in the header instead of sending it in a cookie. The utilization, on the SPA side, would be to save it in LocalStorage and attach it to every request (my understanding is that CSRF attacks would become a non-issue, while XSS could be more potent).
Is this a good idea? While it builds on existing code, I am afraid I could be overlooking crucial security issues.
I believe that any rails/ruby developer can find a good enough implementation using/reading the following links:
- Rails's EncryptedCookieJar implementation: https://github.com/rails/rails/blob/b70fc698e157f2a768ba42efac08c08f4786b01c/actionpack/lib/action_dispatch/middleware/cookies.rb#L568
- A (very practical) how to: http://stackoverflow.com/questions/41474176/how-to-decrypt-a-rails-5-session-cookie-manually
- The doc of the underlying encryption function: http://api.rubyonrails.org/classes/ActiveSupport/MessageEncryptor.html
- A simpler access to rails' key_generator function: https://github.com/rails/rails/blob/8f59a1dd878f56798f88369fa5b448f17a29679d/railties/lib/rails/application.rb#L168
---
There are many session store in Rails. I believe that we can provide a new "TokenStore" similar to CookieStore, but more geared toward SPA/mobile/apis, and I would like to have the opinion of Rails' community.
Could something like this find its place in Rails' core?
I, for now, don't know how to integrate it in Rails in a transparent way and would be glad to have any pointer/help/advice.
Regards,
Hamza
Hamza Mahmood
Hamza