I'm curious and would appreciate some background as to why there is no user identifier associated with tokens (access, refresh, or authorization code)? It seems so common to use identifiers, and convenient, that this is a surprise. In contrast, the spec does define a client identifier.
In my use case I have a client (native application) that stores records retrieved from a server, for one or more individuals (i.e. I maintain credentials for multiple users). Without a user identifier, it would seem that user identification would have to be retrieved from data returned from the protected resource, and it seems plausible that existing protocols might not have this capability. It would also seem more efficient to be able to determine if a user already has a local (on client) credential without going through the full process of getting an access token and retrieving a protected resource. For instance, if a user initiates an enrollment process the process could be stopped early if a token for a userid is already possessed. I would think the protected resource server would also benefit from a user identifier. At a minimum it would provide useful logging information for failed login attempts, and perhaps could be used in risk analysis. Apologies if this is an old topic or if I missed the explanation somewhere. Regards, Jim _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
