> 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.
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/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
