Closed Bug 979845 Opened 6 years ago Closed 4 years ago

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

Categories

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

defect

Tracking

(Not tracked)

RESOLVED FIXED
Blocking Flags:
backlog -

People

(Reporter: standard8, Unassigned)

References

()

Details

(Whiteboard: [using sync sign-in is ok][first release needed][FxA])

User Story

As a FF browser user not signed into FxA I can sign into FxA via the existing FxA sign-in UX so that I can access the Loop registered user features.
As a FF browser user already signed into FxA, I am identified with my FxA without extra sign-in so that I can access the Loop registered user features.
As a FF browser user not signed up to FxA I can sign-up to FxA via the existing FxA sign-up UX so I can access the Loop registered user features.
As a FF browser user already signed into FxA, I can sign-out so that I can't access the Loop registered user features anymore.


Approximate UX:

- On the panel, a link to sign-in with Firefox Accounts is available
- Hitting sign-in brings up the accounts sign-in via a tab
- Once FxA is signed-in the panel should show Signing In... or similar
- The client gets the FxA assertion and sends it to the Loop server
- Once the server is signed in, the panel is shown
- The panel now shows that the user is signed in
No description provided.
User Story: (updated)
Summary: Desktop Client needs ability to register with the server → Desktop Client needs ability to authenticate with the server
Whiteboard: [est: TBD, need to investigate how sync connects & auths]
Assignee: nobody → standard8
Duplicate of this bug: 971988
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
User Story: (updated)
Summary: Desktop Client needs ability to authenticate with the server → Desktop Client needs ability to authenticate via FxA to the server
Bug 961920 suggests we could have user information in the notification data. Let's push this.
Priority: -- → P2
Whiteboard: [est: TBD, need to investigate how sync connects & auths] → [blocked by FxA][may be able to do something for MLP, but needs more investigation]
Blocks: loop_mvp
No longer blocks: 974875
Assignee: standard8 → nobody
Priority: P2 → --
Whiteboard: [blocked by FxA][may be able to do something for MLP, but needs more investigation] → [using sync sign-in is ok][not needed for MLP]
(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.
User Story: (updated)
User Story: (updated)
Depends on: 972014
No longer depends on: 996494
Blocks: 972014
No longer blocks: loop_mvp
No longer depends on: 972014
Depends on: 996494
User Story: (updated)
Priority: -- → P1
Target Milestone: --- → mozilla33
Priority: P1 → P2
Blocks: loop_mvp
No longer blocks: 972014
Summary: Desktop Client needs ability to authenticate via FxA to the server → [meta] Desktop Client needs ability to authenticate via FxA to the server
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.
Flags: needinfo?(sescalante)
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]
Flags: needinfo?(sescalante)
Whiteboard: [using sync sign-in is ok][not needed for MLP] → [using sync sign-in is ok][not needed for MLP][estimate blocked on response from services on other FxA integration work]
Priority: P2 → P1
Target Milestone: mozilla33 → mozilla34
Duplicate of this bug: 1009488
Depends on: 1022064
No longer depends on: 996494
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.
Depends on: 1041814
Blocks: 972017
backlog: --- → Fx34?
Blocks: 1029436
Target Milestone: mozilla34 → mozilla35
Bug 1022064 attachment 8461282 [details] [diff] [review] has an example implementation for this bug.
> Target Milestone: mozilla34 → mozilla35

Is FxA integration with Loop no longer targeting Fx 34?
(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.
Target Milestone: mozilla35 → mozilla34
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.
Priority: P1 → P3
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.
Whiteboard: [using sync sign-in is ok][not needed for MLP][estimate blocked on response from services on other FxA integration work] → [using sync sign-in is ok][first release needed]
Whiteboard: [using sync sign-in is ok][first release needed] → [using sync sign-in is ok][first release needed][FxA]
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.
Flags: needinfo?(mreavy)
Flags: needinfo?(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.
Flags: needinfo?(ckarlof)
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?
Flags: needinfo?(mreavy)
> "[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.
Depends on: 1058060, 1057125
Depends on: 1058268
Depends on: 1058181
Depends on: 1059503
No longer depends on: 1059503
No longer blocks: 1029436
Depends on: 1065777
Depends on: 1069750
Depends on: 1072965
Depends on: 1074112
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.
Target Milestone: mozilla34 → mozilla35
Depends on: 1078261
We should triage the dependent bugs on this bug individually.
backlog: Fx34? → Fx35?
Target Milestone: mozilla35 → ---
backlog: Fx35? → -
Rank: 55
Flags: firefox-backlog-
Priority: P3 → P5
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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.