Integrating a JWT access/refresh token authentication strategy as a configurable option.

[aarona]

What is the problem the enhancement will solve?

This would add a standardized authentication strategy - access and refresh tokens in JSON web token (JWT) format - into GraphQL Devise (GD) as an alternative to Devise Token Auth's (DTA) authentication strategy. Essentially, We would be integrating Devise JWT Auth's (DJA) access and refresh token strategy as an alternative strategy.

Describe the solution you have in mind

Because this would be a little bit of an undertaking and because this feature would potentially touch many files in the project, I see three different approaches on how to do this:

Option 1: Total fork of the project.

I could fork the existing GD project and port it like I did with DTA to support JWT access/refresh tokens. The upside to this is that this means the contributors of this current project wouldn't have be a part of this process if they didn't want to and this feature request would end here. The downside is that it would be difficult to maintain both of the projects if a new feature/bug is found that is agnostic to DTA/DJA. We would want that patched in both projects. I think it would also divide the community into two groups of end users which means less eyes on ONE project. Less focus on good documentation and that sort of thing.

Option 2: Create a highly maintained branch in this project.

In this scenario, We'd create a fork of the project and set it up as a actively maintained branch. This would allow end users who want to use the JWT strategy support by adding something like this to their Gemfile:

gem 'graphql_devise', :git => 'https://github.com/graphql-devise/graphql_devise.git', branch: 'jwt'

The upside is that it would be easier to maintain it (most likely I would do this) whenever changes are made to the main branch that are applicable to the jwt branch.

Option 3: A full integration with a configuration setting

I think this would be the most ideal option for end users and everyone involved because it would allow end users a simple config setting set up like so:

/config/initializers/graphql_devise.rb

# This is the authentication strategy setting. By default, the strategy will be
# Devise Token Auth. If you would prefer a JWT-based access and refresh token
# strategy, you will need to set this to :jwt. The values supported for this
# setting are: [:dta, :jwt]
# config.authentication_strategy = :dta

The upsides for the maintainers is that this will attract more people to this project because people are looking for a GraphQL interface that supports JWT (the standard for authentication) as well as refresh tokens. @jeffchuber can attest to this. I believe there IS a real need for this.

Some of the issues/hurdles I have considered going the Option 3 route

Gem dependencies

If we integrate the JWT strategy, most likely we will have to include Devise Token Auth as a gem dependency. That means we'd have to require both DTA and DJA to be bundled. That's kind of a draw back since we really only want one or the other. Maybe someone knows a way around this? Maybe we could have a conditional in the *.gemspec file or maybe we can pass an argument to the rubygems version of GD in the end user's Gemfile that will require one or the other? A possible way around this would be to take the code that I've written and create an entire module in the library. That could possibly solve this problem.

Code branches

I've looked at the places where DeviseTokenAuth is located in the GD code and there are places where DJA and DTA behave the same way. Usually this would be related to email notifications or something to that affect. The places where we'd need a code branch (i.e. if config.auth_strategy == :dta; else # jwt branch here end) are going to be where we want to use the SetUserByToken module or anywhere where we are doing something with authentication headers.

Spec tests

We may want to consider putting any JWT based request specs in a separate sub folder under /spec/requests. Something like /spec/requests/jwt. This might help with maintainability of the tests by keeping the files smaller.

Returning GQL Errors for unsupported requests based on auth strategy

There are going to be mutations/queries that will not be supported by both the DTA auth strategy and the JWT-based one. I think in those cases we should return GraphqlExecutionErrors and put any detailed reasons in the extensions hash. For example we will want a refreshTokenRequest query. This would not be supported by the DTA auth strategy and therefore any requests made to this should return an execution error. Spec tests should be added to cover this scenario and others like it.

Documention

If we go this route, we will want to communicate to the end user that they will want to decide on which strategy they're going to use before starting the application (i.e. We won't support any moving back or forth and they would need to figure out what database migrations they may want to add if they decide to move to a different strategy. They will need to pick the strategy THEN go with the installation process.

We would add a --jwt-strategy option to the install generator like so:

rails generate graphql_devise:install --jwt-strategy

This would generate an initializer file that had all of the supported jwt config settings. Many of DTA's settings do not overlap with the ones I needed to create DTA.

Features not currently supported on DJA

Before we even did this, I'd want to implement a way for multiple clients to be supported. I have a few features that you can see here and here that I want to add to DTA before I did move this to the GD project. I think some of what I'm thinking about in those features (specifically a way to query what clients currently have active sessions) could actually be pretty interesting features for GD by they way.

Conclusion

All of this is just an idea I had today. I know it might add a bit of complexity to the library and if this is something that is totally out of the question, I would fully understand but I think it could really be a good addition to what the community wants and I think it would definitely put even more eyes on the Graphql Devise project in all honesty.

Let me know what you all think.

[00dav00]

Hey @aarona this would represent a major change on how the gem is structured, to say yes or no we would have to check this with detail which will probably take sometime. So, if this is blocking you in any way, I would recommend going with the fork option.

That said, I would like to point out that if the purpose of this integration is to have a way to refresh JWT tokens, there is probably other possibilities several degrees less complex than replacing DTA. For example adding a mutation that provides that functionality.
WDYT?

[aarona]

This isn't blocking right now because I'm using Devise Jwt Auth for what I need. I created DJA for the purpose of having JWT-based authentication with refresh tokens. It's working great and I'm using it for my clients right now. This is really just a low priority "just throwing this idea out there" kind of thing.

I'd like to go through GD's code and see what exactly would need to change if we were going to integrate JWT based authentication with refresh tokens. Usually anywhere were SetUserByToken or DeviseTokenAuth shows up, we might want to check for an authentication_strategy when including a those modules. A good idea might be to create another controller like GraphqlJwtController and GraphqlDevise::Concerns::SetUserByJwtToken. Creating a special namespace under GraphqlDevise like GraphqlDevise::Jwt that way it would keep the strategies separate. Instead of branching inside the mutations for example, you would just use the ::Jwt:: ones. I think that if we did that, you'd probably see a lot more "new" files in a PR under /jwt/ sub folders and a lot less "modified" files. Keeping the business rules separate where ever possible could make this a mostly seamless integration.

I haven't totally thought this through yet as you can see. I just wanted to put this out into the ether so to speak and gauge what the reaction might be.