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]> 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] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
