979845 - [meta] Desktop Client needs ability to authenticate via FxA to the server

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect, P5)

Comment 2

[Alexis Metaireau (:alexis)]

Some context from duplicate bug 971988:

It seems we would need to do the following, once signed in with about:accounts:

- We want to listen to login / logout events, see http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccountsCommon.js#45
- Once logged in, we can request our assertion with getAssertion(audience). http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#242
- To have this working we would need to check the verified state with getSignedInUser() http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#186

Comment 3

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Bug 961920 suggests we could have user information in the notification data. Let's push this.

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Alexis Metaireau (:alexis) from comment #2)
> Some context from duplicate bug 971988:
> 
> It seems we would need to do the following, once signed in with
> about:accounts:
> 
> - We want to listen to login / logout events, see
> http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/
> FxAccountsCommon.js#45
> - Once logged in, we can request our assertion with getAssertion(audience).
> http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.
> jsm#242
> - To have this working we would need to check the verified state with
> getSignedInUser()
> http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.
> jsm#186

IMHO we should be only be worried about getting a valid assertion. The rest should be handled by the FxA core implementation. That's the current situation in FxOS.

We might still want to listen for the onlogout notification if we want to log the user out from Loop too.

Comment 5

[Fernando Jiménez Moreno [:ferjm]]

Check bug 996494

Comment 6

[:shell escalante]

shell:  email Services team on prioritization to get this high on their list.  There are 3 listed things in contract we are required to do - and this is one.  EME is targeted for 36.  need a breakdown from their part.

Comment 7

[:shell escalante]

shell:  write services team that this is one of 3 contracted deliverables. EME isn't contracted until fx36, we need fx33 (last chance early 34 to hit contract), so we can do our part.

loop client part needs new bugs for integrating into FxA hooks [p=2, investigation - blocked by services]

Comment 9

[Chris Karlof [:ckarlof]]

I would expect to see some Loop Desktop Client bugs as dependencies that break down the work to take advantage of the API landing as part of bug 1022064. IMO, bug 1022064 is close enough to start the breakdown. Bug 1022064 also includes a PoC patch to suggest what shape that would take in Loop as well.

Comment 10

[Mark Banner (:standard8)]

Bug 1022064 attachment 8461282 [details] [diff] [review] has an example implementation for this bug.

Comment 11

[Chris Karlof [:ckarlof]]

> Target Milestone: mozilla34 → mozilla35

Is FxA integration with Loop no longer targeting Fx 34?

Comment 12

[Maire Reavy [:mreavy]]

(In reply to Chris Karlof [:ckarlof] from comment #11)
> > Target Milestone: mozilla34 → mozilla35
> 
> Is FxA integration with Loop no longer targeting Fx 34?

We really WANT FxA integration for Fx 34 -- especially if it is close to ready. We may not have enough of contacts available to expose all of it as a user-visible feature until Fx 35.  We're discussing that this week as well as what it is the best success path for Fx 34. (It likely makes sense to focus on making accountless mode solid and deliver contacts in Fx 35.)  

Getting FxA integration done in Fx34 helps us A LOT, and I'd like to still target it if we can do so and deliver a solid accountless mode experience.

Comment 13

[Maire Reavy [:mreavy]]

P3 is not because we don't want it, but because we believe folks outside of our core Loop dev team will work on this.

Comment 14

[Chris Karlof [:ckarlof]]

Ok.

Bug 1022064 (FxA integration API for browser services) is waiting on final review from Desktop. It would be great to push that through whenever Desktop resources are free.

Comment 15

[Alexis Metaireau (:alexis)]

Chris, Maire;

It's a bit unclear to me if having Firefox Accounts integration for loop needs having the OAuth flow in place for loop-server (e.g. the ability to login with the OAuth dance for a Firefox Account).

Given the fact we already accept firefox accounts assertions, should we consider the inclusion of FxA+OAuth a blocker, or is it just something that is the "preffered" way to authenticate to FxA?

Thanks.

Comment 16

[Chris Karlof [:ckarlof]]

(In reply to Alexis Metaireau (:alexis) from comment #15)
> Chris, Maire;
> 
> It's a bit unclear to me if having Firefox Accounts integration for loop
> needs having the OAuth flow in place for loop-server (e.g. the ability to
> login with the OAuth dance for a Firefox Account).

For FxOS, no. FirefoxOS uses FxA BrowserID assertions to make identity assertions. Our FxOS team is working on migrating to Oauth flows in the future, but for now it's BiD.

For the Web and Firefox Desktop, yes, the Loop server needs to support the FxA Oauth flow to integrate with FxA. 

> Given the fact we already accept firefox accounts assertions, should we
> consider the inclusion of FxA+OAuth a blocker, or is it just something that
> is the "preffered" way to authenticate to FxA?

For Web and Desktop integration of Loop+FxA, yes, Oauth support on the Loop server is a blocker. 

Vlad has a very rough suggestion of what this would look like here: https://github.com/mozilla-services/loop-server/pull/98

I spoke with Vlad today and he will extend this PR to include a standalone testing (throwaway) Web app for the loop-server, so you guys can develop Oauth support on the Loop server without depending on the FxA Desktop Loop client changes.

Comment 17

[Maire Reavy [:mreavy]]

Alexis -- I don't think I have anything to add to Chris' answer.  Is there anything in Chris' answer that isn't clear, or do you anything more to proceed with Oauth support on the server?

Comment 18

[Matthew N. [:MattN]]

Some resources I have found that explain the UX:
* https://etherpad.mozilla.org/MWt7hqDivW
* https://www.lucidchart.com/documents/view/d211775b-8e54-4f16-ba56-8cbee1e63eae/0
* https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/

"[using sync sign-in is ok]" contradicts what is in the etherpad. Is that just a fallback plan still?

Comment 19

[Chris Karlof [:ckarlof]]

> "[using sync sign-in is ok]" contradicts what is in the etherpad. Is that just a fallback plan still?

There is no plan to use the existing sync sign in for Loop. We are planning on using the FxAOauthClient due to land in bug 1022064 for Loop and future attached services in the Desktop browser.

Comment 20

[:shell escalante]

should have been moved to Fx35, sprints where work is happening.  work still targeted for Fx34 uplift - but this particular meta bug isn't being uplifted and can likely be closed, as the work is broken down. it's just holding so many bugs -that i left for ease of bug management.

Comment 21

[Maire Reavy [:mreavy]]

We should triage the dependent bugs on this bug individually.

Comment 22

[Mark Banner (:standard8)]

FxA integration into Hello is complete as of a few versions ago. The remaining bugs will be tracked separately and don't strictly block this meta.