I agree with Justin. You should be using the code flow if it is a server based client.
The OAuth WG is considering better alternatives to using fragment encoding for in browser JS clients as well. For the moment the only standard for the in browser client is fragment encoding. In the future we hope to have more modern methods based on post message. For people using openID Connect who want a id_token in the front channel (Hybrid flow) they should use the form post response mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html <https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html> Browsers now re-append fragments across 302 redirects unless they are explicitly cleared this makes fragment encoding less safe than it was when originally specified. John B. > On Jun 29, 2016, at 10:30 AM, Justin Richer <[email protected]> wrote: > > The implicit flow was designed for in-browser clients that don’t have a > server back-end. In these cases, keeping the data inside the browser entirely > is exactly the goal: you don’t want to use query or form parameters because > those get sent by the browser back to the server. That was the idea anyway, > except that now new versions of Chrome also send the fragment back (as I > understand things) so we’re in a bit of a lurch with our assumed security > model. > > Even so, you’re absolutely right that the fragment can leak all over the > browser. There are a few tricks you can do to mitigate this, like messing > about with the history, but they’re patches at best. This is why the implicit > flow is considered fairly insecure by most people in the community, and it > really needs to be used only in the very limited context of an in-browser > application, with limited lifetime access tokens (perhaps even tied to a live > session at the AS). What you’re doing with the implicit flow, when used > properly, is really more like a cross-domain session sharing. > > — Justin > >> On Jun 27, 2016, at 3:30 PM, Liyu Yi <[email protected] >> <mailto:[email protected]>> wrote: >> >> While we are working on a project with OAuth2 implementation, one question >> arises from our engineers. >> >> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 >> <https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30>, it is >> specified that >> >> >> (C) Assuming the resource owner grants access, the authorization >> >> server redirects the user-agent back to the client using the >> >> redirection URI provided earlier. The redirection URI includes >> >> the access token in the URI fragment. >> >> >> For my understanding, the browser keeps the URI fragment in the history, and >> this introduces unexpected exposure of the access token. A user without >> authorization for the resource can get the access token as long as he has >> the access to the browser. This can happen in a shared computer in library, >> or for an IT staff who works on other employee’s computer. >> >> >> Shouldn’t it be more secure if we change to use a post method for access >> token, similar to the SAML does? >> >> I feel there might be something I missed here. Any advices will be >> appreciated. >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
