> > Isn't this recommendation neglecting some benefits or use cases of > Oauth?
This recommendation doesn't say you can't still centralize your account management in a dedicated component. If that component shares a domain with the application, you don't need OAuth to hop back and forth, you can just have the centralized account system set a cookie on the same domain. That said, I also agree that it reads better as "it may be a better decision" anyway. Also in section-9.6, it is a bit hard to understand what is meant by the > below statement. > If POSTs in particular from unsupported single-page applications are to be > rejected as errors per authorization server security policy... I agree, it's confusingly worded and I'm not sure it actually adds anything to the section, so I'm removing it. Suggestion: > Public browser-based apps needing user authorization *should *create an > authorization request... I see the intent here, but I don't want to confuse this with normative wording like "SHOULD". I've rephrased this paragraph to better lead into the next two sections instead. Leo and Janak, thanks for the other typo fixes too. These edits are currently in my source file on GitHub, https://github.com/aaronpk/oauth-browser-based-apps as I believe it's no longer possible to publish an updated version to ietf until after the meeting. ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Tue, Jul 9, 2019 at 1:08 PM Janak Amarasena <janakama...@gmail.com> wrote: > Hi, > > A few rewording suggestions; > > *section-6.2* > Original: > The Application Server SHOULD use the OAuth 2.0 authorization code grant > to initiate a request *request *for an access token... > > Suggestion: > The Application Server SHOULD use the OAuth 2.0 authorization code grant > to initiate a request for an access token. > > *section-7* > Original: > Public browser-based apps needing user authorization create an > authorization request URI with the authorization code grant type per > Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being > received by the app. > > Suggestion: > Public browser-based apps needing user authorization *should *create an > authorization request URI with the authorization code grant type *as *per > Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being > received by the app. > > *section-8* > Original: > ... can potentially continue using the stoken refresh token to obtain new > access without being detectable by the authorization server. > > Suggestion: > can potentially continue using the *stolen *refresh token to obtain new > access *tokens *without being detectable by the authorization server. > > Also in *section-9.6,* it is a bit hard to understand what is meant by > the below statement. > *If POSTs in particular from unsupported single-page applications* are to > be rejected as errors per authorization server security policy... > > > Best Regards, > Janak Amarasena > > On Tue, Jul 9, 2019 at 6:43 AM Leo Tohill <leotoh...@gmail.com> wrote: > >> I see now that my arguments for softening the 6.1 language are backed and >> expanded on by the last paragraph of section 5, starting with " By >> redirecting to the authorization server,..." >> >> >> On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill <leotoh...@gmail.com> wrote: >> >>> 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 >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
