I still don't see how your #1 and #3 points mitigate the replay attack when an attacker somehow eavesdrops a successful response from an AS (yes, it's signed by a public key) and then starts to replay it for other requests from the same client.
The main problem here is that the client doesn't have a way to correlate the introspection response with the initial introspection request. Regarding #2, it's true that there are many proxies that do this and that. In practice, you don't always have control over the infrastructure where you may run your AS as I was saying before. Regards, Andrii On Tue, Feb 9, 2021 at 1:30 PM Neil Madden <neil.mad...@forgerock.com> wrote: > 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 <https://www.forgerock.com/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
