Re: [OAUTH-WG] Standardising JWT access token type determination

[Warren Parad <[e-mail]>]

It is not limited to OIDC, it is not OIDC specific. The RFC just includes
what to do if you also want to be OIDC compliant, since open ID already
specified a definition for the acr claim prior, but as the RFC title
indicates, this is for OAuth.

On Wed, Jan 17, 2024 at 10:46 AM Akila Amarasinghe <akilaa=
[e-mail]> wrote:

> Hi Warren,
>
> Please correct me if I am wrong. As I understood, the "acr" claim is only
> returned with the ID token, which is OIDC-specific.
>
> Also, how about the point #2 I explained above?
>
> Thanks,
> *Akila Amarasinghe **| **Software Engineer | WSO2 LLC*
> (M)[phone] *| *(E)[e-mail]
> (B) medium.com/@akilaamarasinghe
>
> <http://wso2.com/signature>
>
>
> On Wed, Jan 17, 2024 at 1:28 PM Warren Parad <wparad=
> [e-mail]> wrote:
>
>> > I'm afraid that claim is specific to OIDC
>>
>> Where exactly do you see that?
>>
>> On Wed, Jan 17, 2024, 05:12 Akila Amarasinghe <akilaa=
>> [e-mail]> wrote:
>>
>>> Hi Warren and all,
>>>
>>> I believe this will get you exactly what you are looking for,
>>>
>>> I did some digging into the "acr" claim you mentioned in your last
>>> email. I'm afraid that claim is specific to OIDC. Open Banking and Identity
>>> providers may not use OIDC always. For my requirement, there should be a
>>> way to distinguish the token type for both OIDC and non-OIDC providers. Is
>>> there any other way that supports both of the above scenarios?
>>>
>>>
>>>
>>>> without attempting to utilize existing claims in a way that wasn't
>>>> intended. While I definitely wouldn't recommend putting the
>>>> *grant-type* in the property, but rather the *depth of security that
>>>> the grant-type represents*, you are of course free to interpret the
>>>> spec how you wish.
>>>>
>>> Regarding #2 (Adding a custom claim to the access token), let me
>>> *correct* what I mentioned in the first email. *The custom claim won't
>>> contain the grant type itself in plain text*. It will contain some sort
>>> of string pre-defined by the authorization server which is determined based
>>> on the grant type. For instance, if the token request is with the
>>> "authorization code" grant type, the claim will contain something like
>>> "APPLICATION_USER". And if the grant type of the token request is "client
>>> credentials", the claim will contain the value "APPLICATION".  So we can
>>> use this claim to distinguish the token type.
>>>
>>> Is the above recommended by the authors of IETF?
>>>
>>> Thanks,
>>> *Akila Amarasinghe **| **Software Engineer | WSO2 LLC*
>>> (M)[phone] *| *(E)[e-mail]
>>> (B) medium.com/@akilaamarasinghe
>>>
>>> <http://wso2.com/signature>
>>>
>>>
>>> On Fri, Jan 12, 2024 at 3:49 PM Danuta Kusik-Wieland <
>>> [e-mail]> wrote:
>>>
>>>> Witam.Nie jestem informatykiem.Prubowałam stworzyć witrynę niestety
>>>> jest problem z tolkenem.Wiem o tym ale nie wiem jak to zmienić.Jeżeli masz
>>>> dobry pomysł proszę napraw to bo ja nie potrafię.Pozdrawiam Danuta
>>>> Kusik-Wieland
>>>>
>>>> pt., 12 sty 2024, 09:48 użytkownik Akila Amarasinghe <akilaa=
>>>> [e-mail]> napisał:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am researching a standard way to distinguish the token grant type
>>>>> (client credentials of authorization code) by inspecting the content of the
>>>>> self-contained JWT token.
>>>>>
>>>>> I expect to build a discussion within the Oauth/OpenID community
>>>>> around the need to identify the grant type in which a JWT access token is
>>>>> issued.
>>>>>
>>>>> In the context of Open Banking, regulators around the world enforce
>>>>> the API resource access validation specifying which type of access token
>>>>> should be used to access the API resources. This is becoming a general
>>>>> enforcement and the Open Banking solution providers are searching for a
>>>>> standard way to distinguish the access token type by checking the content
>>>>> of the JWT token.
>>>>>
>>>>> I researched this and please find my findings below,
>>>>>
>>>>> 1. *"sub" claim is a potential way to distinguish the token type*
>>>>>
>>>>> In rfc9068 <https://datatracker.ietf.org/doc/html/rfc9068> specification,
>>>>> it is mentioned that the "sub" claim should contain the client ID of the
>>>>> authorization server if the resource owner is not involved during
>>>>> authorization (see the screenshot below).
>>>>>
>>>>> [image: Screenshot 2024-01-12 at 12.15.42 PM.png]
>>>>>
>>>>> We had discussions about using this claim to validate the token type
>>>>> (auth code or client credentials), but it seems this is not a standard way
>>>>> to do this since there can be client impersonation attacks. However, it is
>>>>> very rare for an actual authorization code access token to have the same
>>>>> client ID in the "sub" claim as the client exists in the authorization
>>>>> server.
>>>>>
>>>>> 2. *Add a custom claim to the access token*
>>>>> Another option is to add a custom claim to determine the token type.
>>>>> This will be set after determining the grant type of the token request and
>>>>> will be contained in the JWT access token when issued by the authorization
>>>>> server. This is a reliable way to identify the token type because the
>>>>> authorization server determines the grant type by inspecting the request
>>>>> sent into it. Therefore, making it more reliable. This custom claim will
>>>>> contain from which grant type the access token is obtained.
>>>>>
>>>>> 3. *Validating the "azp" claim in the token*
>>>>> This is not applicable generally because this claim is optional and is
>>>>> only used in OpenID connect. The applications that don't use ID tokens
>>>>> cannot use this claim.
>>>>>
>>>>> We seek the help of the OAuth/OpenID community to build up a
>>>>> discussion on this and find a standard way to do the token type
>>>>> determination using the JWT token. It could be one of the above scenarios.
>>>>>
>>>>> The feedback from the Oauth/OpenID community is highly appreciated.
>>>>>
>>>>> Thanks,
>>>>> *Akila Amarasinghe **| **Software Engineer | WSO2 LLC*
>>>>> (M)[phone] *| *(E)[e-mail]
>>>>> (B) medium.com/@akilaamarasinghe
>>>>>
>>>>> <http://wso2.com/signature>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>