Support multiple-user clients #357
Description
The DOT code makes the assumption that Application <-- 1:1 --> User and forces it to be non-null.
Reading the OAuth2 specification, this is not the case in some of the grant types. In client_credentials grant type, there is not necessarily a user (in the oauth sense) associated with the client. Since Django always expects an auth.User of some sort, creating a dedicated auth.User to represent the client is a reasonable workaround. In issue #38 I had offered a workaround where an auth.User that represents the client could be used if one wished so Django/DRF is happy.
Now, it is also common to use the password grant type with mobile clients. In this mode, the client_id is unique and there is no client_secret (because it is assumed that the client can't keep it secret.) There is not a very good way for the server to authenticate the client. In this case, the user has to verify that they are using an official client some other way (out of band). In this flow the user's username/password is sent over and therefore it is the case that the same Application/client_id would be used by more than one auth.User. Generally, DOT seems to do the right thing and authenticate the client when it can and the user separately and returns that user.
At the end of #38 it seemed like there was some agreement for relaxing the constraint and making user optional on AbstractApplication. If that still stands, I'd like to make that PR and submit it for consideration.