Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

[Neil Madden <[e-mail]>]

Three points:

1. In many cases the JWT will be verified using a public key fetched over the same TLS channel. 

2. Many proxies can now also produce and consume JWTs for downstream services, so end-to-end JWT is no more guaranteed than end-to-end TLS.

3. The JWT response already contains an iat claim which is sufficient to judge freshness. 

It would be better to concentrate on ensuring end-to-end TLS rather than trying to reinvent the same mechanisms in JWT form on top. 

— Neil

> On 9 Feb 2021, at 20:38, Andrii Deinega <[e-mail]> wrote:
> 
> 
> How can you guarantee that there are always direct TLS connections between a client and an AS hosted say some cloud provider where you have a little control on their infrastructure?
> 
> Even without all those cloud providers, how can you guarantee the same when there are a bunch of different (software and hardware) components that legitimately perform SSL offloading / DPI in front of an AS...  or the client may just use the proxy server?
> 
> Regards,
> Andrii
> 
>> On Tue, Feb 9, 2021 at 12:43 AM Neil Madden <[e-mail]> wrote:
>>> On 9 Feb 2021, at 06:55, Andrii Deinega <[e-mail]> wrote:
>>> 
>>> 
>>> Hi WG,
>>> 
>>> I wonder if there are any particular reasons to not make nonce a mandatory parameter for the current JWT Response for OAuth Token Introspection draft. Or, at least, force an AS to include the nonce claim in a JWT response when nonce is presented in the introspection request similar to what happens with the similar scenario in the OpenID Connect ID Token?
>>> 
>>> https://openid.net/specs/openid-connect-core-1_0.html#:~:text=If%20present%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Authentication%20Request.
>>> 
>>> This will allow to mitigate replay attacks because clients can correlate the response with the initial request
>> 
>> ID tokens involve flows using an insecure channel (the browser). This is not the case for introspection requests which happen over a direct TLS connection and so are already protected against replay attacks. 
>> 
>> — Neil
>> 
>> ForgeRock values your Privacy

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>