Remove access token from browser history

[raucao]

... maybe just remove the whole OAuth callback URL entry.

Here are some docs for the History API: https://developer.mozilla.org/en-US/docs/Web/API/History_API#Adding_and_modifying_history_entries (I'm actually not sure if this will delete the entry from the history database in all browsers, though)

[untitaker]

In Firefox, History.replaceState doesn't remove the entry from the browser history, but only from the "tab history".

[raucao]

Ah, dang! So maybe a generic browser extension cleaning out all entries with OAuth access tokens is the better/only way then.

[untitaker]

It seems to work in Chromium though, so this might be a browser bug actually.

[raucao]

Great!

I think it's worth doing it as long as it works in at least one browser, especially if it's one of the big ones.

[untitaker]

Meh, it seems I can grep the access token from the sqlite database in Chromium. Maybe it's just some stuff that will soon get GC'd, but I'm not sure.

[lewisl9029]

This might not be necessary if we're willing to switch to doing OAuth in a popup window for browsers. We're already doing this for Cordova through InAppBrowser, and the Cordova OAuth flow doesn't ever leave any traces of the access token in history AFAIK.

I think it also happens to make the OAuth process potentially less disruptive for end-users (i.e. the app will be in the exact same state before and after the OAuth flow, although this won't be true in our case until #885 is fixed).

Any thoughts?

[untitaker]

You mean in an actual popup, or an absolutely positioned iframe? (is the latter even possible)

[raucao]

I think he means actual popup.

@lewisl9029 There's a number of issues with popups, which is why most sites/apps have abandoned it now. In any case, are you certain that URLs in popups aren't entering the history? In Cordova you're not in an actual browser, so no browser history is saved outside of the app.

[lewisl9029]

Oh my bad. I was only thinking of history in terms of the back button on the current tab, but I just realized you guys are talking about the browser history.

The OAuth 2 specs does list this as a concern, but their recommended approach involves server-side restrictions on token usage (limit tokens to 1 time use and short expiry times) rather than messing with history on the client. I'm not sure how feasible these recommendations are for a federated service like remoteStorage though.

https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-4.4.1.1
https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-4.4.2.2

Going back to the topic of popups, it's true that popups in general have been abandoned for most use cases, but OAuth is a notable exception, probably due to the fact that the alternative results in the loss of current app state. Most OAuth flows I recall encountering have been processed in a popup, which is why it was a bit jarring for me when first seeing remoteStorage's same-window OAuth flow.

[raucao]

Oh wow, talk about individual experiences. :) In fact, I was talking about OAuth popups, as all sites I log into with e.g. Twitter or FB these days have switched to full-page redirects. I think the only thing left I know was Disqus, because it's run on arbitrary sites outside of their control.

Regarding short-lived tokens, that's certainly something the user should be able to do. We do have it on our todo list for 5apps Storage (with dropdown for expiry from "1 day" to "never" or similar).

I think it's still worth trying to remove them from the browser history, wherever possible. The first tests at least yielded a little bit of success in Chrome.

[untitaker]

I wonder whether running the OAuth dialog in an iframe overlay is possible. afaict this would prevent writing anything into history in the first place (as opposed to removing the entries afterwards)

On 13 October 2015 15:43:02 CEST, Sebastian Kippe notifications@github.com wrote:

Oh wow, talk about individual experiences. :) In fact, I was talking
about OAuth popups, as all sites I log into with e.g. Twitter or FB
these days have switched to full-page redirects. I think the only thing
left I know was Disqus, because it's run on arbitrary sites outside of
their control.

Regarding short-lived tokens, that's certainly something the user
should be able to do. We do have it on our todo list for 5apps Storage
(with dropdown for expiry from "1 day" to "never" or similar).

I think it's still worth trying to remove them from the browser
history, wherever possible. The first tests at least yielded a little
bit of success in Chrome.

---

Reply to this email directly or view it on GitHub:
#893 (comment)

Sent from my phone. Please excuse my brevity.

[untitaker]

Though this probably would open the door for a lot of attacks by malicious apps.

On 13 October 2015 15:43:02 CEST, Sebastian Kippe notifications@github.com wrote:

Oh wow, talk about individual experiences. :) In fact, I was talking
about OAuth popups, as all sites I log into with e.g. Twitter or FB
these days have switched to full-page redirects. I think the only thing
left I know was Disqus, because it's run on arbitrary sites outside of
their control.

Regarding short-lived tokens, that's certainly something the user
should be able to do. We do have it on our todo list for 5apps Storage
(with dropdown for expiry from "1 day" to "never" or similar).

I think it's still worth trying to remove them from the browser
history, wherever possible. The first tests at least yielded a little
bit of success in Chrome.

---

Reply to this email directly or view it on GitHub:
#893 (comment)

Sent from my phone. Please excuse my brevity.