regarding 6.1. Apps Served from a Common Domain as the Resource Server Isn't this recommendation neglecting some benefits or use cases of Oauth?
* An application that doesn't collect user credentials is an app that doesn't need to be audited for problems such as password leakage into log files. * Applications that offload authentication to a identity server can delegate to that server the complexities of MFA, password recovery,and the like. Of course these CAN be done in the app, but isn't it sometimes better to centralize those features in a identity server? Especially if the organization has multiple apps that require these features. I would soften " it is likely a better decision" to "it may be a better decision". Leo On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aa...@parecki.com> wrote: > Hi all, > > I've just uploaded a new version of oauth-browser-based-apps in > preparation for the meeting in Montreal. > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 > > This draft incorporates much of the feedback I've received over the last > couple months, as well as what we discussed at the last meeting in Prague. > > The primary change is a significant rewrite and addition of Section 6 to > highlight the two common deployment patterns, a SPA with and without a > dynamic backend. > > Please have a look and let me know what you think. I have a slot in the > agenda for Montreal to present on this as well. > > Thanks! > > ---- > Aaron Parecki > aaronparecki.com > > _______________________________________________ > 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
