Hi Thomas,

Thanks for reading my article and for your response!

As long as the user has a session in any way, shape, or form, there's always the risk of session highjacking. However, that's really not what this is about, i'm afraid you're missing the point.

Moving token exchange to the server side makes it more difficult to elevate permissions, and to access back-end services directly. To state it more correctly, moving token exchange to the server side makes it more difficult to exploit impersonation.

Allow me to elaborate: Like stated in this article, obtaining an access token starts by redirecting the user to the /authorize endpoint. If an attacker can abuse the session at the identity provider, this will allow the attacker to use the /authorise endpoint to request any scope or (in case of auth0) audience. It means the attacker will not only be able to obtain an access token for ONE api, it means the attacker can obtain access for ANY api (because OIDC is a protocol that is meant to be used for Single Sign On, meaning it provides tokens for several api's/applications).

Therefor, by moving the token exchange to a trusted machine, the attacker can now only highjack the session of one single front-end, thereby limiting the number of endpoints the attacker can abuse, drastically. So, in other words, moving token exchange to the server side reduces the blast radius of a potential breach.

Hope this sheds some more light on the topic?

Cheers!