1343170 - (webext-chrome.identity-api) Grabbing an FxA Bearer Token if the user is connected Firefox Sync from a Web Extension

Status: RESOLVED WONTFIX

(WebExtensions :: Experiments, enhancement, P5)

Description

[Rémy Hubscher (:natim)]

We are planning to ship Hoverpad as a Test Pilot web extension experiment. [0]

The idea is to have a popup add-on that shows a pad.
Its content is saved encrypted with a passphrase on the disk.
If the user has got Firefox Sync enabled the encrypted content is synced between browsers.

We will have a Android, iOS and web app with the same synced content.

In order to achieve that we would need to be able to use a web-extension API to ask a FxA Bearer token with a specific scope in order to authenticate the user of the pad on the server side.

The related Chrome Extension API is called IDENTITY [1]

What we basically need is an implementation of:

- chrome.identity.getAccounts() to detect if the user is logged in.
- chrome.identity.getAuthToken() to get a FxA Bearer Token with the expected scopes.
- chrome.identity.getProfileUserInfo() eventually if we want to display the user email.
- chrome.identity.launchWebAuthFlow() to be able to trigger the Firefox Sync setup if the user is not already connected to Sync.

For Hoverpad we will not need the FxA keys at first.

[0] https://github.com/mozilla-services/hoverpad
[1] https://developer.chrome.com/apps/identity

Comment 1

[Mark Hammond [:markh] [:mhammond]]

(In reply to Rémy Hubscher (:natim) from comment #0)
> - chrome.identity.getAccounts() to detect if the user is logged in.

That says it's only on the dev channel, but it looks trivial to implement - we'd return [fxa_uid]

> - chrome.identity.getAuthToken() to get a FxA Bearer Token with the expected
> scopes.

And removeCachedAuthToken :)

> - chrome.identity.getProfileUserInfo() eventually if we want to display the
> user email.

FxAccounts.jsm should also support enough for the above to all be fairly simple and thin wrappers.

> - chrome.identity.launchWebAuthFlow() to be able to trigger the Firefox Sync
> setup if the user is not already connected to Sync.

I suspect this will be slightly more complicated - maybe another bug for this makes sense, so the above can be done earlier for development purposes and relying on existing signup flows?

Comment 2

[Ryan Kelly [:rfkelly]]

> - chrome.identity.launchWebAuthFlow() to be able to trigger the Firefox Sync
> setup if the user is not already connected to Sync.

Is the intention that this would connect the browser to sync, or would do an oauth login that's just for hoverpad?  If it's the former then I think we'll need a new API rather than re-using launchWebAuthFlow, which seems to be for generic oauth flows.

Comment 3

[Vlad Filippov (:vladikoff)]

(In reply to Ryan Kelly [:rfkelly] from comment #2)
> > - chrome.identity.launchWebAuthFlow() to be able to trigger the Firefox Sync
> > setup if the user is not already connected to Sync.
> 
> Is the intention that this would connect the browser to sync, or would do an
> oauth login that's just for hoverpad?  If it's the former then I think we'll
> need a new API rather than re-using launchWebAuthFlow, which seems to be for
> generic oauth flows.

In addition, there are plans to be able to login to Hoverpad from OAuth (on mobile platforms) so we will probably need Hoverpad to use our OAuth flows.

Comment 4

[Ryan Feeley [:rfeeley]]

It's most preferable for Hoverpad to appear and behave as an additional Sync datatype for the user, although preffed in Hoverpad itself, not in Sync prefs.

If the user is not signed in to Sync, the option inside Hoverpad would be: Sign in to Sync

If the user is signed in to Sync but unverified, the option inside Hoverpad would be: Verify your account

If the user is signed in to Sync, but Hoverpad syncing is off, the option inside Hoverpad would be: Sync Hoverpad (checked off)

If the user is signed in to Sync, but Hoverpad syncing is on, the option inside Hoverpad would be: Sync Hoverpad (checked on)

Comment 5

[Ryan Kelly [:rfkelly]]

> It's most preferable for Hoverpad to appear and behave as an additional Sync datatype for the user,

I know it's been discussed previously, but: the easiest way to achieve this and get all the edge-cases right, may be to store data in the chrome.storage.sync API.  At least for the initial testpilot prototype.

Comment 6

[Rémy Hubscher (:natim)]

> At least for the initial testpilot prototype.

We already built that prototype but it doesn't fit our requirements for Hoverpad.

- We don't have chrome.storage.sync support in Android and glasserc can explain it better than I but it is unlikely that we will have it anytime soon.

- chrome.storage.sync uses the Firefox Sync keys that we cannot get from outside the browser using the Oauth flow which will prevent us from using Hoverpad as a standalone app on Android or IOS or as a web app in the browser.


Reading Ryan Feeley comment I am not sure anymore if I understood correctly the scope of this add-on.

But for me the goal is to experiment with Firefox Account and web-extensions and prototype some API's for one to use FxA with web-extensions without requiring a privileged add-on and I personally think we can iterate without being as tight to sync as described.

The problem of using chrome.storage.sync is that we won't be able to iterate because we can't implement the same protocol outside of BrowserID.

My plan is implement Ryan UX without being tight to Sync for the FxA part.

[0] https://cloud.githubusercontent.com/assets/229453/23546235/eac4ad48-fffe-11e6-8d53-b9d6ff83312c.png

Comment 7

[Vlad Filippov (:vladikoff)]

We don't need this API change anymore.