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

[Warren Parad <[e-mail]>]

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