The client app could (and should) do a window.location.replace or
window.history.replaceState to remove the entry from the browser history.
AFAICT, this is out of scope of the OAuth specs because they're about the
protocol and interactions between the parties involved, not about securing
each one on its own.

That said, if the computer is shared between users, they should take care
of properly signing out, which should (in most cases) revoke tokens and, in
the case of client apps should also involve explicitly revoking the tokens
they've been handed out. So even if a token is present in the browser
history it shouldn't be usable. If the previous user hasn't signed out,
then he has bigger problems.

See also https://tools.ietf.org/html/rfc6819#section-4.4.2.2

As for the form post, see
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

On Wed, Jun 29, 2016 at 4:08 PM Liyu Yi <liy...@gmail.com> 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,
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to