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
On Mon, Oct 4, 2021 at 4:28 AM <toshio9....@toshiba.co.jp> 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 <da...@alkaline-solutions.com>
Sent: Saturday, October 2, 2021 6:04 AM
To: Dick Hardt <dick.ha...@gmail.com>
Cc: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <toshio9....@toshiba.co.jp>; oauth@ietf.org
Subject: Re: [OAUTH-WG] self-issued access tokens
On Oct 1, 2021, at 11:06 AM, Dick Hardt <dick.ha...@gmail.com> 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.
ᐧ
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
