Current State of Building Authentication and Authorization in Jets

I’m evaluating Jets for a project that requires control over user authentication and role management. Cognito is probably a no go because it doesn’t look mature enough.

So I did some searches for “Devise” and “auth” on the forums and found some one to two year old threads:


Have there been any significant changes since? I’m trying Devise and Doorkeeper out right now and I run into the same devise_for problem in the routes. I can probably work around this by either manually creating the routes without using the helper or monkey patching devise so that the devise_for method is available in Jets.application.routes.draw. The same could probably be done for use_doorkeeper (also a route helper).
Then I noticed that controllers helpers/extension will probably have the same problem: Jets::Controller::Base. There’s probably a few more places.

Does anyone have any suggestions? Am I going to have to build this from scratch if I want AuthN/AuthZ in jets?

This is a good question. Have quite a few Jets apps under my belt now. Looked through a few open source auth solutions along the way:

  • Other Gems: Most are really designed for Rails. Would probably require forks and updates to get working with Jets. Took a look a while back then and it was a little bit too much effort to get them working with Jets.
  • AWS Cognito: The service has it’s own pros and cons. FWIW, using cognito with one of the internal BoltOps Jets apps. There are trade offs and customizations with Lambda trigger isn’t great from a developer perspective in my opinion.
  • API Gateway Lambda Authorizers: There are some pros and cons with this also.
  • API Gateway API Keys: There are some pros and cons with this also.

Eventually, rolled a simple auth with before actions for the internal app that needed it. It’s would take some time and effort extract it out as an open source library. Unsure if will get to it :pensive: Hopefully someone will create one. :pray:

So it’s not an ideal answer. Think rolling your own simple auth and consider open sourcing is the current advice.

I actually came across a blog post about a Ruby/Rack (not Rails) auth gem that looks promising. https://janko.io/rodauth-a-refreshing-authentication-solution-for-ruby/
I’ve been trying to get it working as a mounted rack app in jets. I come across a few bugs in Jets and opened some PRs. Will let you know if Rodauth works well or not.

1 Like

So update on Rodauth: it works! I got it deployed onto a test/staging environment. What I have so far:

  • Rodauth mounted as a rack app under /auth/*. It’s configured to respond to JSON request only and uses JWT token auth.
  • a Jets api with a generic listings scaffold
  • the ability to call current_account in any controller provided a valid JWT is passed in the headers
  • in listings#create => current_account.listings.new....

Hurdles so far:

  • Routing for mounted rack apps seems to be broken right now https://github.com/boltops-tools/jets/issues/548
    I’ll double check later to make sure I didn’t configure anything wrong. I’m pretty sure my PR does not fix the problem. I’ll likely close it tomorrow with updated findings.
  • Content-Type (for mounted rack apps) seems to behave differently between local and API Gateway. By the time the header makes it to the mounted app, it seems to lowercase locally and uppercase after passing through API Gateway.
  • Have to mount Rodauth as a rack app and use it as a middleware in config/application.rb
    The former is so that API Gateway will route to it. The latter is so that roduath actually gets injected into request.env in the controllers.

It doesn’t integrate seamlessly but looks promising.

1 Like