to_jwt and from_jwt multiple user models about otp-jwt

[stas]

@dtakeshta your example is valid and correct, I'll try to explain the meaning of support for any model.

First of all, this library does not enforce any business logic. It does provide a basic authentication flow, but the overall design and purpose are not reflected through this example.

Based on your example, both models use integer primary keys and since to_jwt and from_jwt uses the primary key to set the JWT subject, this means that any record with the integer value that matches the other record primary key, will return the relevant record.

You can change this default behavior by overwriting your to_jwt and from_jwt methods to be model-specific (in the end these are a very light wrapper around the OTP::JWT::Token).

Consider this:

module CustomAuth
  extend ActiveSupport::Concern

  def to_jwt(_claims = nil)
    OTP::JWT::Token.sign(sub: self.id, scope: self.class.name.underscore)
  end

  class_methods do
    def from_jwt(token, _claim_name = nil)
      OTP::JWT::Token.decode(token) do |payload|
        return if payload['scope'] != self.name.underscore
        self.find_by(self.primary_key => payload['sub'])
      end
    end
  end
end

Now you can replace the OTP::JWT::ActiveRecord mixin with your own custom mixin with support for private claim scope.

A bit more context.... JWT does not provide rules on how claims should be used except for the registed ones. The introduction of new claims is application/business specific and with this library I'm trying to keep things as generic as possible, but offer enough flexibility to implement custom authentication mechanisms.

How am I using this library without the extra claims? I use UUIDs as primary key values.

@dtakeshta let me know if this helps. In the meantime I will explore the idea of providing a mixin I shared with you as part of the included mixins if you think this is something that will help.

Thanks for filling the issue!

[dtakeshta]

Hi @stas,

Thanks for the quick reply! This makes sense, I guess I wasn't thinking through this very clearly. Using UUID would avoid this issue completely. I agree with your approach to keep things as generic as possible. I think having this issue should provide a bit more context if someone runs into this in the future. I have very little experience with JWT's, so maybe my inexperience is why I ended up with this problem. I will go ahead and close this issue.

[stas]

Thanks @dtakeshta! Still I'll be happy to explore a solution for non-UUID entities. Will keep this issue updated once I come up with something...