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
