Doorkeeper: Allow resource_owner_id's value to be configurable

[f3ndot]

Problem

Complex systems may need the AccessToken#resource_owner_id to not be the primary, integer key typically located at User#id but some other column or identifier.

In our case, we want the User#canonical_id to be the stored value.

We serialize and display the resource_owner_id value in distributed microservices that utilize Doorkeeper. As a result we don't want to use the internal User id record, but our canonical IDs instead.

Proposed Solution

Expose a configuration value where Doorkeeper can be told which column/method on the resource owner class to call in order to derive the resource_owner_id.

i.e.

# The method to call on the resource owner record to get the id value. By default it is :id 
resource_owner_id_method :canonical_id

---

Let me know if this is acceptable or if it doesn't make sense and workarounds should be tried instead.

[nbulaj]

Hi @f3ndot . I have similar case on my current project where we have real ID and tokens that we expose to end users. So at first sight it makes sense. From the other side we can't fit everybody use-cases that can be personally extracted to a concern (module) and then prepended / included individually. So I'm on parting of the ways ...

[felipeelias]

If I understand correctly, the idea is to associate access tokens to owners still via resource_owner_id field, but doorkeeper would call a custom method instead of .id everywhere?

Wouldn't be enough (although, super hacky) to wrap your resource owner in another object which would define such id field?

class ResourceOwner < SimpleDelegator
  def id
    @user.canonical_id
  end
end

# config/initializers/doorkeeper.rb
Doorkeeper.configure do
  resource_owner_authenticator do
    ResourceOwner.new(current_user)
  end
end

I'm not entirely sure this works though... I'm quite curious how you both are solving this at the moment.

[f3ndot]

@felipeelias interestingly that's almost exactly how we solved for it. Great minds!

I think that perhaps my request should be closed as a delegator pattern is acceptable here without mucking with the database internals of Doorkeeper.