As David suggested, it is easier to get rid of the code from a query using a referrer policy header or a meta than getting rid of a fragment which would require the each client to have a javascript snippet rewriting the current window.location.hash
S pozdravem, *Filip Skokan* On Sun, Dec 9, 2018 at 2:53 PM Brock Allen <[email protected]> wrote: > Yes, I meant response_mode. Thanks. > > And those are good points about the referrer policy. Thanks for that > insight as well. > > In the context of this thread/topic, I'm assuming browser-based JS > clients, and a common deployment is from a CDN, so I suspect the <meta> tag > approach for a referrer policy is sufficient (especially since many SPAs > are designed for CDN deployment)? > > -Brock > > On 12/9/2018 3:00:23 AM, David Waite <[email protected]> wrote: > I assume the original post meant response_mode, not response_type. > > Fragments have their own data leakage problems, in particular they are > preserved on 3xx redirects (per > https://tools.ietf.org/html/rfc7231#section-7.1.2). The form_post mode is > the safest, but unfortunately was not defined in the original > specifications so it doesn’t have as widespread support. > > In the absence of a response_mode RFC, I would typically suggest both > killing the code in the referrer as part of processing, and a server-wide > Referrer Policy of never or origin (as those have reasonably broad support) > as server-wide response headers are easier to operationally audit. > > -DW > > On Dec 8, 2018, at 3:53 PM, Brock Allen <[email protected]> wrote: > > Not pure OAuth. This only came up as a question while I was implementing > code flow/pkce for oidc-client-js. > > I can appreciate not expanding the current OAuth2 behavior in the BCP, so > that's fair. I only wanted to mention it in case it had not been considered. > > Having said that, I think I will implement an optional response_type in my > code flow/pkce to allow fragment, but default to query (as that's the > default for pure code flow). > > -Brock > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
