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

[Akila Amarasinghe <[e-mail]>]

Adding @Janak Amarasena <[e-mail]> to the thread to get more context.
I will discuss this with my teammates and get back to you.

Meanwhile, what about the other point I highlighted? Using a custom claim
based on the requested grant type.

*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 3:20 PM Warren Parad <wparad=
[e-mail]> wrote:

> 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
>>>>>>
>>>>>