This is not an easy question to answer, as resource servers in OAuth have never really had a strong identity (or identifier) within the OAuth ecosystem. The Resource Identifiers draft [1] tries to address this somewhat. In practice, many resource servers are registered and stored as “clients” at an AS so that the AS can re-use authentication code paths and storage systems. I know that in several large deployments that I’ve worked on, resources are stored as clients with empty “grant_types” and “response_types” arrays, and with a flag set to allow them to call the introspection endpoint. Otherwise they are all “client” objects and therefore get ‘client_id’ fields assigned to them, which would be what the “aud” would be in this case, most likely.
However, unlike clients, resource servers arguably always have at least one URL associated with them. The real problem comes from the fact that the “resource” isn’t easily defined by a single URL. — Justin [1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators On May 7, 2019, at 2:57 AM, Takahiko Kawasaki <t...@authlete.com<mailto:t...@authlete.com>> wrote: Hello, I have a question regarding "JWT Response for OAuth Token Introspection" (draft-02). https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/?include_text=1 How to determine the value of "aud" in the response JWT? The example payload uses "https://protected.example.net/resource"; as the value of "aud". The example value implies that it represents the identifier of the target resource or the resource server, but how does an authorization server implementation know the identifier? I'm sorry if this has already been discussed. To be honest, I fear that some inconsistencies might occur in future by treating resource servers as clients. If I had to write the specification, I would start from defining "resource server metadata" (e.g. expired draft: https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/) and devising a way to register resource servers into an authorization server and issue resource server credentials (e.g. rs_id and rs_secret, RS JWK Set, etc.) in order to treat resource servers and clients as different entities explicitly. I hope that discussion for distinguishing "resource server authentication" from "client authentication" will be initiated sometime in future. Best Regards, Takahiko Kawasaki Authlete, Inc. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
