To add some color, here there's a concrete scenario where many of those concepts come together (or collide, if you prefer). Azure AD implements am early draft of token exchange, largely for implementing a cloud friendly version of kerberos constrained delegation- say a native client calls a mid tier API, and the mid tier API turns around and calls a backend API flowing the identity of the user. In order to do so, the mid-tier API performs a request to the authorization server asking for the scopes the backend API requires, and presenting as a grant the access token it received from the native client. The AS verifies that the resource owner previously granted consent (as there is no opportunity to show any UX). Here's the relevant part: *the AS also verifies whether the audience in the access token (in whatever way it is expressed) corresponds to the client ID of the requestor, to prevent MITM attacks to gain an avenue for minting new tokens from arbitrarily captured ATs*. In other words, the AS needs a mechanism to know that the resource indicator for the mid tier API and the client ID used by the app implementing that API to ask for new tokens are in fact pointing to the same entity. The AS can always do this on its own, without relying on any standard guidance, and provide its own mechanism to associate API resource indicators with client IDs - but this scenario does suggest that it would be handy to be able to use the mid tier API clientID as an identifier in the request from the native client to get the bootstrap token. I agree that doing so today is super confusing, as the developer would use something with "client" in its name to indicate a resource. To me this is a consequence of expressing everything in term of clients, which comes from the OAuth2 heritage of those flows, but doesn't provide a way of modeling the frequent occurrence in which an application legitimately plays both the resource (in the most general sense, including web sites) and the client role.
On Sun, Mar 3, 2019 at 6:17 PM Justin Richer <[email protected]> wrote: > 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]> 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] wrote: > > draft-ietf-oauth-resource-indicators-02 > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
