We have an OAuth server that uses doorkeeper. We want to start using doorkeeper JWT, but we can't turn it on for all OAuth clients yet as some are out of our control and we are pretty sure they are storing the access tokens their apps receive in a varchar(255) column which won't work if we start to hand out JWT tokens for all apps. Also, we don't really want to be storing the whole JWT in our database either if we can avoid it.
Our idea is to have doorkeeper generate an opaque access token for all apps first, and store that in the db. Then before returning the opaque access token to the app, we check to see if the app has JWT tokens turned on and if so convert the opaque access token to a JWT access token using the opaque access token as the JWT's jti claim. We are thinking of utilizing the before_successful_strategy_response callback to convert to a JWT using the gem 'doorkeeper-jwt' if the app has JWT access tokens enabled.
Then, when we get a request which has an access token, check to see if the access token is a JWT access token and if so read the jti claim out of it and use that to load the access token from the DB. We don't have a good place to hook into this at the moment. Right now we are thinking of monkey patching Doorkeeper::Oauth::Token in the from_request method to check to see if the token is a JWT before returning it, and if so, return the JWTs jti instead.
Does that seem like a reasonable approach? Is there another way without monkey patching Doorkeeper::Oauth::Token?
More recent versions of doorkeeper allow you to configure the access token model class as seen here:
So we can hook into the access token lookup there without resorting to monkey patching.