[Openid-specs-ab] Review of OpenID Provider Commands (draft 00)

[Dick Hardt]

Joseph:

10.1 attempts to summarise how to prevent a command token from being used
as an id_token.
https://openid.github.io/openid-provider-commands/main.html#name-cross-jwt-confusion

I lifted this from OpenID Backchannel Logout.

An idea for other normative language: An OP that supports OP Commands MUST
/ SHOULD require a `nonce` in the authorization request.



On Thu, Mar 13, 2025 at 1:56 AM Joseph Heenan via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

>
>
> On 13 Mar 2025, at 06:53, Andrii Deinega via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> 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.
>
>
> 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.
>
> The “typ” header (as already used in the provider command spec) avoids
> confusion with other types of token, and as this token is defined to only
> have ‘client_id’ in aud there’s no chance of confusion between client ids
> and user identifiers.
>
> I think there probably is a small chance of confusion with an id_token
> though (the command token appears to pass all/most of the rules for
> validating an id_token as per
> https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation ).
> I’m not sure if that is a real problem, but if it is it would probably be
> best to put the client id into “client_id” and have no “aud”. “Client url”
> seems to be a new concept that we don’t have right now, I can’t see how it
> helps to introduce a new “client url” concept just to use in “aud” here.
>
> Joseph
>
> _______________________________________________
> 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/20250313/489a1ce2/attachment.htm>