> On 9 Feb 2021, at 22:04, Andrii Deinega <andrii.dein...@gmail.com> wrote: > > > 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 point of #1 is that an attacker that has compromised the communication channel between the AS and client can do much more than replay introspection responses. In particular they can replace the AS’s public key with their own and then sign their own introspection JWTs, with whatever nonce in them that they like (they can easily see the nonce in the request). They can also steal access tokens and almost certainly also steal user session cookies and manipulate authorization responses from users to change the scopes that are approved for different requests. It’s absolutely essential that ASs and clients ensure the TLS connection between them is secure. The stated purpose of JWT introspection responses is for non-repudiation. It’s not intended as a replacement for TLS. Within that context “iat” is sufficient proof of freshness. > > The main problem here is that the client doesn't have a way to correlate the > introspection response with the initial introspection request. In a properly secured environment this guaranteed by TLS (and even TCP). > > 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. Right - so trying to solve this issue by replacing TLS with another technology that is just as susceptible to the problem is not a real solution. — Neil -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
