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

Thu Mar 27 18:59:44 UTC 2025

Here is the issue for this discussion

https://github.com/openid/openid-provider-commands/issues/4

I'll turn it into a PR soon unless there is discussion in the issue or on
the list

/Dick

On Sat, Mar 15, 2025 at 2:42 PM Dick Hardt <dick.hardt at gmail.com> wrote:

>
>
> On Sat, Mar 15, 2025 at 3:58 AM Andrii Deinega <andrii.deinega at gmail.com>
> wrote:
>
>> Dick, yes, your example properly illustrates my suggestion. It's safe to
>> say it becomes even more important when dealing with multi-tenant OPs. You
>> never want a malicious actor to trick an OP into creating a client with a
>> specific name to abuse RPs in different tenants (due to lack of controls /
>> checks on either or both sides).
>>
>
> The one proposal I worry about is where the client_id is a URL per
> https://www.ietf.org/id/draft-parecki-oauth-client-id-scheme-01.html --
> this could be the same URL as the commands_uri for a client, so the `aud`
> and `client_id` in a Command Token would have the same value.
>
>
>>
>> It's also worth noting that the aud claim can take not only a single
>> string but also an array of strings, as specified in the OpenID Connect
>> Core 1.0 spec.
>>
>
> I have the opinion that allowing the `aud` claim to be an array was an
> edge case that overly complicated token processing.
>
>
>> On a side note, one day OpenID Connect ID Tokens will be explicitly
>> typed... along with Logout Tokens, and JWT assertions used as client's
>> credentials.
>>
>>
>> https://bitbucket.org/openid/connect/issues/2162/recommendation-to-the-use-of-explicit
>>
>
> I think the odds of existing deployments updating id_tokens to be
> explicitly typed to be low. We could specify in OP Commands that an OP that
> supports OP Commands SHOULD explicitly type their tokens. That does not
> help all the RPs that are not coded to look for it though.
>
>
>>
>> All the best,
>>
>> Andrii
>>
>>
>>
>> On Fri, Mar 14, 2025 at 8:03 AM george--- via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> Hi Dick,
>>>
>>> My apologies! I read the “command” claim as the “aud” claim which of
>>> course doesn’t (and shouldn’t) have the full URL.
>>>
>>> George Fletcher
>>> Identity Standards Architect
>>> Practical Identity LLC
>>>
>>>
>>>
>>> On Mar 14, 2025, at 10:59 AM, Dick Hardt via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>> The example I provided was the full URL George — what am I missing?
>>>
>>> On Fri, Mar 14, 2025 at 2:55 PM <george at practicalidentity.com> wrote:
>>>
>>>> +1 for this approach
>>>>
>>>> It might be useful to put the full URI in the `aud` claim so that
>>>> domain matches can be made as well
>>>>
>>>> George Fletcher
>>>> Identity Standards Architect
>>>> Practical Identity LLC
>>>>
>>>>
>>>>
>>>> On Mar 14, 2025, at 7:33 AM, Dick Hardt via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Mar 14, 2025 at 12:51 AM Joseph Heenan <joseph at authlete.com>
>>>> wrote:
>>>>
>>>>> Hi Dick,
>>>>>
>>>>>
>>>>> > On 14 Mar 2025, at 01:01, Dick Hardt via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>> >
>>>>> >
>>>>> > 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.
>>>>>
>>>>> Unfortunately I think it’s not just the RP that we need to worry about
>>>>> - whilst doing so is contentious, there are various patterns of third
>>>>> parties accepting id tokens, and we should at least be aware of the
>>>>> implications if one of those third parties would accept a command token in
>>>>> place of an id_token.
>>>>>
>>>>
>>>> I'm not that familiar with those patterns Joseph. Would you share those
>>>> so we can reflect on how to minimize the risk of a command_token being used
>>>> in place of an id_token?
>>>>
>>>> Perhaps Andrii's proposal (if I understood it correctly) of the `aud`
>>>> being the commands_uri and the `client_id` claim containing the client_id
>>>> is the better approach. It seems this would significantly reduce the risk
>>>> of token confusion.
>>>>
>>>> The command token endpoint then knows the command was intended for it,
>>>> and it and the `client_id` is then just a claim in the command. This may
>>>> simplify RPs that host multiple client tenants that are each identified by
>>>> their own client_id value
>>>>
>>>> The example at the end of section 4 would then change from
>>>>
>>>> {
>>>>   "iss": "https://op.example.org",
>>>>   "sub": "248289761001",
>>>>   "aud": "s6BhdRkqt3",
>>>>   "iat": 1734004000,
>>>>   "exp": 1734004060,
>>>>   "jti": "bWJr",
>>>>   "command": "unauthorize",
>>>> }
>>>>
>>>> to
>>>>
>>>> {
>>>>   "iss": "https://op.example.org",
>>>>   "aud": "https://rp.example.net/commands",
>>>>   "sub": "248289761001",
>>>>   "client_id": "s6BhdRkqt3",
>>>>   "iat": 1734004000,
>>>>   "exp": 1734004060,
>>>>   "jti": "bWJr",
>>>>   "command": "unauthorize",
>>>> }
>>>>
>>>> where https://rp.example.net/commands is the commands_uri
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250327/ec0e00ef/attachment-0001.htm>