Subject: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 7 May 2019 15:57:39 +0900

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.

---

From: Justin Richer <[email-masked]>
Date: Wed, 15 May 2019 20:54:33 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

I have a question regarding "JWT Response for OAuth Token Introspection" (draft-02).

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth