[Openid-specs-ab] client_id vs aud claim (Re: Review of OpenID Provider Commands (draft 00))

[Dick Hardt]

Building on Joseph's response:
> The confusion attack only really applies where you have a ‘sub’ value
that can contain a client id or a user identifier. That isn’t the case here.

An objective is to have a Command Token that is used in the `activate` and
`maintain` commands to be able to be verified and processed similar to an
id_token allowing code reuse.

the id_token specifies that the client_id is the `aud` claim, so following
that same semantic keeps things simple for the RP

We do want to provide mechanisms that make it easy for an RP to not confuse
id_tokens and command tokens -- We can add that the command claim MUST NOT
be in an id_token, and per the other thread, we could require OPs that
support OP Commands to require a nonce in the id_token.

On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <andrii.deinega at gmail.com>
wrote:

> On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>
>>
>>
>> On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <andrii.deinega at gmail.com>
>> wrote:
>>
>>> Hi WG,
>>>
>>> Wanted to send some feedback and suggestions a bit earlier... but didn't
>>> have enough time for that.
>>>
>>> 1. I suggest extending Section 4 (Command Token) with a new required
>>> claim (client_id) to help prevent and address potential misuse and abuse.
>>> Thus, one of the provided examples for the command token (activate) becomes
>>> to look like this
>>>
>>> *{*
>>> *  "iss": "https://op.example.org <https://op.example.org>",*
>>> *  "sub": "248289761001",*
>>> *  "aud": "https://rp.example.org <https://rp.example.org>",*
>>> *  "client_id": "client1234567890"*
>>> *  "iat": 1734003000,*
>>> *  "exp": 1734003060,*
>>> *  "jti": "bWJq",*
>>> *  "command": "activate",*
>>> *  "given_name": "Jane",*
>>> *  "family_name": "Smith",*
>>> *  "email": "jane.smith at example.org <jane.smith at example.org>",*
>>> *  "email_verified": true,*
>>> *  "tenant": "ff6e7c9",*
>>> *  "groups": [*
>>> *    "b0f4861d",*
>>> *    "88799417"*
>>> *  ]*
>>> *}*
>>>
>>>
>>> The key idea is that the aud claim includes (one or more) RP URLs where
>>> the client_id claim "carries" the client identifier. Note, this is in line
>>> with JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)
>>> <https://datatracker.ietf.org/doc/html/rfc9068>.
>>>
>>
>> I'd prefer clarifying that the `aud` is the `client_id`, and has a single
>> value. Is there a motivation for having the `aud` and `client_id` be
>> different?
>>
>
> Once you put "client_id" in the aud claim, you became a vulnerable for
> confusion attacks for those OPs (and authorization servers) that
> allow clients to influence their client_ids, I didn't make this up, this is
> part of the Best Current Practice for OAuth 2.0 Security (RFC 9700)
> <https://datatracker.ietf.org/doc/html/rfc9700>, what I did is
> "simply" applied this to OP Commands.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250313/6a6c3702/attachment-0001.htm>