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

[Akila Amarasinghe <[e-mail]>]

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