Is there a way to store Doorkeeper::AccessToken data inside Doorkeeper::JWT (and not use db-backed tokens)?

[NeilSlater-Clixifix]

Steps to reproduce

Not a bug report, but a feature request for relying on token data storage inside issued JWT

I think this is either an undocumented existing feature (in which case I would appreciate a "how to" link), or more likely something that Doorkeeper 5.5 does not support.

Expected behavior

There should be a way to inform Doorkeeper / Doorkeeper::JWT to not use theDoorkeeper::AccessToken database model, and that instead the details such as client id, approved scopes etc should be stored and read direct from the JWT. This is a common use-case for JWTs as an authentication mechanism, that they embed data for access control.

Specifically it would bedoorkeeper_authorize! and doorkeeper_token helper methods that I would like to run without database backing on the read side. This primarily will require changes to doorkeeper gem, and not doorkeeper-jwt although it may be possible to make changes to the latter for cleaner configuration.

Actual behavior

As far as I can tell from a quick browse of the code and local testing, Doorkeeper always uses database-backed access tokens, and JWTs are not exceptions - the whole serialised JWT is used as an index string to lookup server-side credentials. That means for busy API services, we cannot explore the possibility of skipping the db I/O for granting and reading access tokens.

System configuration

Doorkeeper initializer:

# config/initializers/doorkeeper.rb
Doorkeeper.configure do
  access_token_generator '::Doorkeeper::JWT'
end

Doorkeeper JWT initializer:

# config/initializers/doorkeeper_jwt.rb

Doorkeeper::JWT.configure do
  token_payload do |opts|
    {
      iss: SITE,
      iat: Time.now.utc.to_i,

      # see JWT reserved claims - https://tools.ietf.org/html/draft-jones-json-web-token-07#page-7
      jti: SecureRandom.uuid,

      # Illustrative example (client credentials in this case, so no User information)
      doorkeeper_access: {
        application_id: 2,
        expires_in: 7200,
        scopes: "core_api read write"
      }
    }
  end
end

User and Doorkeeper::Application data could be similarly embedded on granting the token. This will make the token longer, but allow clients to skip more database reads on auth checks. Usually this would be combined with shorter token expiry times, and matches patterns of use for client apps that repeatedly make "one shot" requests and don't store access tokens.

[nbulaj]

Currently there is now way to use just raw JWT tokens without database (and it's not possible for Doorkeeper by design as we can't revoke such tokens and do some other things which is a core of the gem)

[nbulaj]

If anybody interested in this feature - I can suggest to create some doorkeeper-no-orm extension which will implement required ORM interface (at least what is possible) and use JWT tokens instead of database storage. Examples could be found in doorkeeper-sequel / doorkeeper-mongodb / etc projects

[mschoenlaub]

@nbulaj We are also highly interested in it, but to me it seems like the perfect place for this would be the doorkeeper-jwt gem.
So we could extend it configuration to allow for either using an "ORM implementation" based on the JWT tokens or being backwards compatible to what it does now.

What is your take on that?

[nbulaj]

Hey @mschoenlaub . I'm not sure how exactly you plan to extend doorkeeper-jwt gem. Maybe only if you'll introduce a JWT ORM inside it 😺 Because all the interactions with the tokens are performed using the models (like find, create, revoke and so on). Some of the features will be missed for sure (reuse_access_token , token revocation and many more).

You can try to if you want, I'll be happy to review it 🙇

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.