There’s a difference in the intended audience of the access token in OAuth vs. the ID token in OpenID Connect. In OIDC, the ID token is read by the client, so the audience of the ID token is the client’s ID. That’s the only party reading that token, in the usual case. In OAuth, the access token goes to the protected resource (or the “API” as you say here). This resource could have an identifier, but it’s not *really* a client ID, since the resource isn’t a “client” in the OAuth sense. As Brian mentioned in his email, due to some unfortunate overlap in functionality, the resource server could be issued its own ID and secret, but these are really *resource* ID and not *client* ID, even though they use the “client_id” parameter for authentication. To confuse things even further, many implementations will store resource servers as “clients” with a special flag. It’s a matter of hindsight that we could have used an abstraction above these two things, some kind of “thing that calls the authorization server” of which instances would include resource servers and clients.
So in the end, the audience of an access token is not a client, and therefore this field isn’t a client ID. Additionally, the ID given to a resource server which could be used in either the “resource” and “audience” field isn’t a client ID either because the resource isn’t a client. And finally, the “resource” identifier used in this parameter is something that has to be known to the client, so that the client can request it at runtime. A system is unlikely to publish a resource server’s internal identifier in this way, and will instead use a developer-facing name or a URL of some flavor. Hope this clears things up, as much as it can be. I agree that between “resource”, “audience”, and “scope”, plus the UMA standard’s “permission” structure, things are more than a bit messy now. — Justin On Feb 27, 2019, at 2:46 AM, Jaap Francke <[email protected]<mailto:[email protected]>> wrote: Hi all, I have some questions/thoughts on the new draft for resource indicators. I didn’t do an in-depth study but would like to share my thoughts with you anyway. 1. In this draft, the Resource is identified by ‘resource’ parameter. For example, when the resource is an API, I would expect that API to validate the access_token at the resource server. The protocol for this would be based on the API’s client_id, so from that angle using the the client_id could be a different way to indicate the intended recipient of the access token. 2. I also think that the ‘resource’ parameter would be closely related to the “aud” claim specified by the OpenID Connect specifications. I think it is getting more and more common to use the OIDC-protocol “on top of OAuth”, so I’m wondering how the resource parameter would relate to that. The values of the ‘aud’ parameter are also client_id’s. Thanks in advance for responding to my views. Ciao! Jaap Francke On 26 Feb 2019, at 21:00, [email protected]<mailto:[email protected]> wrote: draft-ietf-oauth-resource-indicators-02 _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
