> On 15 Feb 2021, at 10:26, Philippe De Ryck > <phili...@pragmaticwebsecurity.com> wrote: > > > >>> On 15 Feb 2021, at 11:14, Neil Madden <neil.mad...@forgerock.com> wrote: >>> >>>> On 15 Feb 2021, at 08:32, Philippe De Ryck >>>> <phili...@pragmaticwebsecurity.com> wrote: >>>> >>> [...] >>> >>> Compared to using a worker for handling RTs, I believe the TMI-BFF only >>> adds a single security benefit: an attacker is no longer able to run a >>> silent flow to obtain a fresh set of tokens (since the client is now a >>> confidential client). >> >> But they can just call the bff-token endpoint to do the same. If there is a >> security advantage, IMO it is as a defence in depth against open redirects, >> unicode normalisation attacks (ie not validating the redirect_uri correctly >> at the AS), etc. > > A Web Worker and the TMI-BFF both encapsulate the RT and only expose the > (short-lived) AT.
I don’t think this distinction matters at all from a security point of view. It’s the AT that attackers are after - why bother with a RT if I can just call the bff-token endpoint to get a new AT every time? > > With the worker-based approach, the client is a public client that completes > the code exchange without authentication. This allows an attacker to run an > independent silent flow in an iframe within the legitimate application. This > flow relies on the existing cookie-based session with the AS to obtain an AT > and RT, independent of the tokens of the client application. A confidential > client does not suffer from this problem (a stolen code cannot be exchanged > without client authN, and when done through the BFF, the RT is not exposed). > > And as you state, there are other benefits as well. > > Philipp > > — > Pragmatic Web Security > Security for developers > https://pragmaticwebsecurity.com/ -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
