Re: [OAUTH-WG] oauth-browser-based-apps-05 - BFF

[George Fletcher <[e-mail]>]

Sorry to have missed the meeting.

To your second point, I think we should provide guidance in this area. 
Currently section 6.2 requires all requests to be proxied via the 
application server. Should we add an additional section for the use case 
Vittorio mentions?

Also there is no mention of DPoP (which of course is a draft) but if the 
private key is stored in the secure enclave of the browser/device and 
all requests to the Authorization server and Resource server are signed, 
is that not strong protection of the access_token/refresh_token? Even if 
an attacker can obtain the tokens some how, they would also need to be 
able to run JS to build the appropriate DPoP header in order to use the 
tokens.

Finally, in the cookie models, I don't see any security considerations 
around things like Server Side Request Forgery or logging the cookies. 
As these cookies are all bearer tokens, if they are exposed they can be 
replayed.

On 4/6/20 5:35 PM, Vittorio Bertocci wrote:
> Hey Aaron,
> Thanks for today�s update on oauth-browser-based-apps, very useful.
> As agreed, here�s the summary of the point mentioned during today�s call.
>
>
>    1.  The last paragraph of 6.2 mentions that an access token could be used as session between the JS frontend and its backend, but no details are given about the security characteristics of making that choice vs using cookies. I would suggest that we either give more guidance on the mechanics of how that would happen (how does the AT get delivered to the JS frontend, what attacks developers should watch out for, etc) or that we recommend the traditional cookie based session approach only.
>    2.  Currently 6.2 doesn�t mention topologies where the backend obtains ATs and forwards them to the JS frontend, where they are used to perform the actual API calls. Those topologies do exist in the wild, and I know there are practitioner advocates for that approach on this list too, hence it seems we should at least acknowledge those topologies and give some guidance.
> If we do position those topologies as legitimate: given that the chatter between JS frontend and backend could in some cases reach sophistication comparable to the client-AS dialog (token requests, renewals, etc), it seems we should either warn people about the security pitfalls they have to watch out for (shorter task for us, but not very actionable) or actually invest some time in specifying how a JS frontend should talk to its backend to delegate its client duties to it and safely retrieve/renew the artifacts the backend obtains on the JS frontend�s behalf (much bigger task for us, but unambiguous guidance and solid threat model developers can safely rely on).
>
> Thanks!
> V.
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth