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 <andrii.dein...@gmail.com> 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 <neil.mad...@forgerock.com> >> wrote: >>> On 9 Feb 2021, at 06:55, Andrii Deinega <andrii.dein...@gmail.com> 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>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
