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