Subject: [OAUTH-WG] can a resource server provide indications about expected access tokens?

From: Nikos Fotiou <[email-masked]>
Date: Sat, 11 Dec 2021 12:35:41 +0200

Hi,

I have a use case where a resource server is protected  and can only be accessed if a JWT is presented. Is there any way for the server to "indicate" the "expected" format of the JWT. For example,  respond to unauthorized requests with something that would be translated into "I expect tokens form iss X with claims [A,B,C]"

Best,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 11 Dec 2021 12:43:42 +0200

Hi Nikos,

The "error_description" can be used to explain the expected token issuer 
and other facts to client developers.

https://datatracker.ietf.org/doc/html/rfc6750#section-3

If you want to give client software the ability to respond 
programmatically this will require some sort of a proprietary extension.

Vladimir

Vladimir Dzhuvinov

On 11/12/2021 12:35, Nikos Fotiou wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Nikos Fotiou <[email-masked]>
Date: Sat, 11 Dec 2021 12:59:14 +0200

Thanks Vladimir,
I am looking for something which is machine readable so that clients can handle the error automatically.

Best,
Nikos

> On 11 Dec 2021, at 12:44 PM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> 
> Hi Nikos,
> 
> The "error_description" can be used to explain the expected token issuer and other facts to client developers.
> 
> If you want to give client software the ability to respond programmatically this will require some sort of a proprietary extension.
> 
> Vladimir
> 
> Vladimir Dzhuvinov

---

From: Warren Parad <[email-masked]>
Date: Sat, 11 Dec 2021 12:25:41 +0100

The section from the RFC, allows for the *scope* or any other standard
parameter to be returned in the WWW-Authenticate header, those would be
machine readable.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Sat, Dec 11, 2021 at 11:59 AM Nikos Fotiou <[email-masked]> wrote:

> Athens University of Economics and Businesshttps://mm.aueb.gr
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Waite <[email-masked]>
Date: Sat, 11 Dec 2021 08:02:20 -0700

> On Dec 11, 2021, at 3:35 AM, Nikos Fotiou <[email-masked]> wrote:
> 
> Hi,
> 

Normally, the scope of the token is part of the contract between the resource server and client (what sort of authorization is needed for the resource server), but other aspects of the relationship - such as format, or required information, or additional verification steps the user needs to take - are part of the contract between the AS and resource server.

The ways to work with indicating that these requirements exist at token issuance include:

1. Scopes - wrap requirements up into scopes, such as having an “admin” scope require additional user authentication, or a “purchasing” scope require the user’s shipping address be embedded as a claim

2. Resources - require the client to use the `resource` parameter to indicate which resource server the token is meant for, and use AS policy to say which RSs get what sort of tokens or have what sort of issuance policy.

-DW

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Dec 2021 11:37:51 -0500

Hi Nikos,

If you mean indicate to the client, then in my view, no — not directly in a delegation protocol like OAuth, at least. The format of the token, and its contents, are abstracted away. As has been mentioned in the thread already, you can return a “scope” and other parameters to the client to indicate what it should ask for, as well as “resource” or even “authorization_details” to use RAR structures. However, there’s an important point that I see so many engineers trip over:

- Scope, resource, authorization_details (RAR), audience, etc: parameters that the client uses to describe what it wants in a request. Let’s call this the “request set”.
- iss, sub, claims, attributes, etc: items inside a JWT access token (when you use that format) to tell an RS what the token’s good for. Let’s call this the “access set”.

The client and AS communicate using the “request set”, while the AS and RS communicate in the “access set”. It’s the job of the AS — literally the primary function of the role of AS — is to translate the “request set” into an artifact, the access token, that can be interpreted in the “access set”. The access token is the artifact that provides that abstraction to the client, and the AS is the mechanism through which a client’s understanding of what it’s asking for gets translated to what the RS actually understands. 

What gets confusing is that sometimes these are the same in practice — you can use “scope” in both places as an abstraction in the access token itself. I’ve seen that work many times. But when you do that it does seem like the client is saying “put the following things inside the access token”, when what’s really happening is the client is saying “I want access to the following things” and the AS is taking that list and saying “that means these other things are what go in the access token”.

The entire purpose of a delegation protocol is that translation from “request set” to “access set” semantics. Trying to skip that gets you out of delegation protocol territory pretty quickly.

 — Justin

> On Dec 11, 2021, at 5:35 AM, Nikos Fotiou <[email-masked]> wrote:
> 
> Hi,
>