1320862 - Look into identity api with fxa backend

Status: NEW

(WebExtensions :: General, defect, P5)

Description

[Shane Caraveo (:mixedpuppy)]

We've implemented launchWebAuthFlow and getRedirectURL support for general oauth dialogs.  We could consider using the google specific parts of the API (the rest) backended by fxa.

Comment 1

[Ryan Kelly [:rfkelly]]

From a quick look, the shape of the API makes sense to me and maps well onto what FxA has to offer.  I think there's definitely potential here.

Comment 2

[Andy McKay]

Given that FxA is not targeted at a general audience (not every site can sign up for one), it seems to me this functionality is going to be as limited to services like Pocket, so would make it a pretty low priority.

Comment 3

[Alex Davis [:adavis]]

Just to clarify, would this allow add-ons to easily use FxA authentication if the user has an authenticated Sync session?

And, could this be used by websites too like AMO?

Comment 4

[Kris Maglione [:kmag]]

(In reply to Andy McKay [:andym] from comment #2)
> Given that FxA is not targeted at a general audience (not every site can
> sign up for one), it seems to me this functionality is going to be as
> limited to services like Pocket, so would make it a pretty low priority.

Given that we'd like to convert as many system add-ons as possible to WebExtensions, I think that makes it a fairly high priority.

(In reply to Alex Davis [:adavis] from comment #3)
> Just to clarify, would this allow add-ons to easily use FxA authentication
> if the user has an authenticated Sync session?

In theory, yes.

> And, could this be used by websites too like AMO?

Not directly, but we could certainly expose a similar API to sites like AMO.

Comment 5

[Ryan Kelly [:rfkelly]]

> Given that FxA is not targeted at a general audience (not every site can sign up for one)

*Yet*.  Opening FxA up to more general audiences is on the table for 2017 if it can be plausibly part of a growth/value-add strategy.

As we plan for 2017 I'm also open to other suggestions for how to make the account provide more value.  For example, we could consider an additional API to give addons access to encryption keys derived from the master key material on the account.

Comment 6

[Andy McKay]

(In reply to Ryan Kelly [:rfkelly] from comment #5)
> > Given that FxA is not targeted at a general audience (not every site can sign up for one)
> 
> *Yet*.  Opening FxA up to more general audiences is on the table for 2017 if
> it can be plausibly part of a growth/value-add strategy.

\o/ If that was the case, it would definitely bump this up in priority.

Comment 7

[:shell escalante]

if FXA changes strategy - reconsider

Comment 8

[akkaya.hu]

I give an example from myself, I have an idea about bookmark. I have lost of bookmark and bookmark tab is not very good looking. İt just only link don't have any category like time, tittle there is not. I want to create an extensions for this. May be users get public links for other users, and someone search what you need from this pool. Like pinterest but there is not too much image only text and fast. Not just special idea for every link. whatever I need a user id for this extensions and normally I must create login, register service and the service must integrated with extensions, may be I need using cookie for user sessions. But if there was a user ıd I could use, I do not need a login register system for my users interact.

Comment 9

[Ryan Kelly [:rfkelly]]

(For context for existing folks on this bug, I've started directing any inbound requests re: FxA and webextensions to this bug)

Comment 10

[Ryan Kelly [:rfkelly]]

Linking the API docs for reference: https://developer.chrome.com/apps/identity

Comment 11

[Ryan Kelly [:rfkelly]]

Andy, if we want to start exploring this, would is make sense to try using [1] rather than hacking directly in the browser in the first instance?

[1] http://webextensions-experiments.readthedocs.io/

Comment 12

[Andy McKay]

Experiments are intended as a path for people who might not be familiar with bugzilla, mozilla-central, hg and want to play around with a prototype quickly. So, depends upon the implementors.

Comment 13

[Alex Davis [:adavis]]

Small update here. The FxA team is *investigating* getting this done in Q2. We are in discussions with hoverpad and pageshots teams to see if we can dog food this work since they both have needs for FxA auth in webextensions.

Comment 14

[Vlad Filippov (:vladikoff)]

Hey :mixedpuppy, as you see from the comment above we have several internal projects that are interested in using FxA for webextension auth. After some meetings we figured out that PageShot (Firefox Screenshots) does not need to use the identity API. However, we are planning to support Hoverpad (https://github.com/mozilla-services/hoverpad). Our plan is to have Hoverpad be the first relier to use `identity.launchWebAuthFlow` APIs with Firefox Accounts OAuth APIs. Besides basic auth, Hoverpad also requires derived encryption keys (to encrypt and safely sync data), so we are currently prototyping that. After we get Hoverpad working (target is end of Q2), we are hoping to expand support of this flow to more internal projects or maybe even web extension developers!
 

Please let me know if you need any more details about any of this. Thanks!

Comment 15

[Shane Caraveo (:mixedpuppy)]

Hey Vlad, didn't realize you were on Mozilla projects, thought you were external :)  That all sounds good!  The only thing I'd add is that launchWebAuthFlow needs to remain compatible with the existing API, otherwise do what you need.  Feel free to ping me with questions.

Comment 16

[Vlad Filippov (:vladikoff)]

:andym, we talk about this bug every quarter in FxA but it's never a priority. I'm gonna remove [fxa] assignment from this. Please re-add if this is something we should explore.

Comment 17

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958