Enable seamless login for first-party clients (embed, Via, extensions)

[dhwthompson]

Background
In our new cookieless login world, we’re currently looking at having the Chrome extension, Via and embedded Hypothesis all function as separate clients. As recently pointed out by @dwhly, part of the value of Hypothesis comes from the user not having to care which of these they are using – effectively being able to treat them all as the same client – and it would be a shame to lose this benefit as a result of the OAuth work.

We will likely need to do some investigation to determine whether it’s possible to keep this feature in some way while still getting the benefits of the new way of logging in.

Proposed Solution

There is a working implementation of a solution in the "oauth-login-prototype" branch in the "h" repo, which should work for the embed, Via and extensions. This is described in the "Streamlined login for first party clients" section of the design doc.

Acceptance criteria

• Given that I am user who has logged into the web service but who has not logged into the embedded client, when I use an OAuth-enabled embedded client I am automatically logged into the client with the same identity that I am logged into the web service.
• Given that I am user who has logged into the web service but who has not logged into the Chrome extension, when I use an OAuth-enabled Chrome extension I am automatically logged into the client with the same identity that I am logged into the web service.
• When I log out of the web service, I remain logged in to the client unless I explicitly log out there as well.

[dwhly]

A bit more:

When I use Hypothesis today, I'm always logged in. It doesn't matter whether I'm using the extension, via, bookmarklet or embed. That is very very powerful. I know that I personally appreciate this, and I was not aware that we were at risk of losing this capability in the shift away from cookies.

It's something that personally as a user that I treasure, and something that in demoing the "magic" of Hypothesis that is showcased each and every time we present. We don't necessarily say "oh, hey, notice that you're still logged in here too", but most certainly the fact that I am still logged in, which they can see is taken for granted, allows us to move on to the next magic thing, such as that my groups also work over here.

Even if there was a constraint such as that the chrome extension version of H and the CDN-delivered version of H had to be separately logged into, but that once you were logged into both (which you might have to do once every couple weeks or a month), you could move across the web-- using embedded versions of the client wherever they were, or the bookmarklet or via proxy, and experiencing the same seamless experience-- that would still be extremely powerful.

What I'd love to avoid is that each and every delivery mechanism (extension, via, embed, bookmarklet) has to be separately logged into, and particularly that the embed would need to be separately logged into for each and every different site it was embedded on.

David's right in that our "brand" is not our logo or name so much as it is the experience through this standard client which works everywhere, on any format, across any page, through any delivery mechanism and that once you're logged in you remain so, magically, across those contexts. This last thing is something worth preserving if at all possible.

[robertknight]

Thanks for the feedback @dwhly. I think these are all good points. We had a discussion this morning and have a tentative plan for how we can preserve the current seamless login across the service and first-party clients while enabling us to get the other things that are motivating use of OAuth (which @fatbusinessman wrote up here).

We'll continue to flesh this out today and tomorrow.

[dwhly]

That's great to hear. I see the last paragraph which seems to get to the key bits. Just quoting here for context:

Once we switch to using access tokens, there will most likely no longer be a way to share these between browser extensions and embedded clients, which may mean users have to log into browser extensions separately. This does not mean they’ll have to log in separately to every site that’s embedded Hypothesis: embedded clients, Via and the bookmarklet should all still share a single state.

[robertknight]

There was some discussion about this on Slack after backlog grooming about whether it would be simpler overall to implement an endpoint that returns a token as JSON vs. opening the auth window in a hidden iframe: https://hypothes-is.slack.com/archives/C1M8NH76X/p1498143372525694 . I agreed to look into it a little more.