> > Does this historical note mean to indicate that if the implicit flow were > designed today, it could use path instead of fragment to carry the token?
I see how it reads that way, but that was not my intent. The implication is that now browsers can use the authorization code flow with no modifications needed, (getting the authorization code back in the query string rather than modifying it to use the fragment), since the Session History API can be used to remove it from the URL. I've updated the section to clarify that, so thanks! ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Tue, Jul 9, 2019 at 8:55 AM Leo Tohill <leotoh...@gmail.com> wrote: > > re: > > 9.8.7 > <https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#section-9.8.7>. > Historic Note > > Historically, the Implicit flow provided an advantage to single-page > apps since JavaScript could always arbitrarily read and manipulate > the fragment portion of the URL without triggering a page reload. > Now with the Session History API (described in "Session history and > navigation" of [HTML > <https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#ref-HTML>]), > browsers have a mechanism to modify the path > component of the URL without triggering a page reload, so this > overloaded use of the fragment portion is no longer needed. > > > Does this historical note mean to indicate that if the implicit flow were > designed today, it could use path instead of fragment to carry the token? > > Doesn't this overlook the important aspect that fragments are not sent to > the server? > > > _______________________________________________ > 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
