Re: [OAUTH-WG] self-issued access tokens

[Warren Parad <[e-mail]>]

fwiw we are currently doing this in some flavor, and there are two things
that have come up:

   - Standardize place to read client public keys from (JWKs)--Currently
   these are uploaded to the AS for storage for a particular client. This
   helps to avoid needing every client to host the public key. Obviously
   putting the public key in the jwt is rife with vulnerabilities.
   - Impossible to prevent client impersonation attacks by default with
   crypto/jwt verification libraries as the client can create tokens that
   specify a different sub then the clients. Because this extra restriction
   exists which is non-standard, verification can't be automatically handled
   by a library that doesn't understand this restriction. Which means that the
   only place which can verify that the sub is actually valid for the client
   is also the AS. (Specifically for us we make this easier by authorizing
   token that fetch AS resource data, including JWKs)

It would be great to have a standard around the second one, but I honestly
don't see how, since the client can always lie, there would have to be a
signature format that stores the *kid/clientId* identification information
in a way that is tamper proof or still the trusted third party in this case
the AS. We tend to call this reverse oauth. A small consolation would be a
standard adding an attribute to the JWK and the JWT signally the
requirement that the sub has to match some other property, but I also don't
see this happening.

- Warren

Warren Parad

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


On Mon, Oct 4, 2021 at 4:28 AM <[e-mail]> wrote:

> Thanks Dick,
>
>
>
> Our use case is basically the option 2. There is only one RS. So, to
> simplify
>
> the architecture, we want to omit the round-trip of getting an access
> token from
>
> AS.
>
>
>
> I agree with your idea of using JWTs to convey client's signature. So my
>
> original question was if there was a standardized profile of a JWT for that
>
> purpose. From the responses to this thread so far, I think the answer is
> no.
>
>
>
>
>
> Thanks for comment, David,
>
>
>
> Yeah, maybe it's wise to have AS anyway for better extensibility.
>
>
>
>
>
> Toshio Ito
>
>
>
> *From:* David Waite <[e-mail]>
> *Sent:* Saturday, October 2, 2021 6:04 AM
> *To:* Dick Hardt <[e-mail]>
> *Cc:* ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[e-mail]>;
> [e-mail]
> *Subject:* Re: [OAUTH-WG] self-issued access tokens
>
>
>
>
>
>
>
> On Oct 1, 2021, at 11:06 AM, Dick Hardt <[e-mail]> wrote:
>
> <snip>
>
> If there is really only one service, then there is little value in an AS.
> I would have the client post a JWT that has the request payload in it, or a
> detached signature if it is a large payload. Personally, I like sending the
> request as a JWT as it allows services further down the processing pipeline
> to independently verify the request from the client.
>
>
>
> This assumes sufficient computing power on the IoT device, and reasonably
> low call volume.
>
> [image: イメージは差出人によって削除されました。]ᐧ
>
>
>
> One interpretation of the purpose in the AS is to create tokens based on
> its authorization decisions, while direct submission of client-authored
> JWTs would be more in line with having the RS make those decisions directly.
>
>
>
> Even if they were hosted on the same hardware, I’d still push to use an
> AS-role component in order to optimize the decision making process and to
> not have to refactor (or risk duplication) of that logic later.
>
>
>
> -DW
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>