Hi all,
I would like to start a thread for a late discussion, in search for a
the proper way to do OAuth 2 flow for packaged Open Web Apps.
The related bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=883510#c12
For hosted apps, since they run on their own http(s) domains, they
could simply use User-Agent flow to get the access token.
The problem is about packaged apps; by OAuth definition, they are
"installed apps" which "cannot keep secrets.... has access to the
system browser or the ability to embed a browser control in the
application" [1], so for packaged apps we should have always use the
"install apps/embedded browser" flow.
[1]
https://developers.google.com/accounts/docs/OAuth2InstalledApp
However, there is the current situation, and some drawbacks if we use that:
-- Our in-Gaia implementations (Calendar, and Contacts * 3) doesn't
use this flow currently (or arguably does, but not in a
provider-specified way.)
-- Would that be an overkill to get mozbrowser permission just because
of the OAuth 2 login? What about the OOP issue we have currently?
-- Embedded browser means the user does not get a "trusted UI", like a
browser chrome with a lock, EV cert, and address bar to verify where
exactly the password is sending to. This is sub-optimal to User-Agent
flow.
-- We have no infrastructure exists in the OS to allow providers to
redirect login requests to their own app (say, on iOS5, people get to
log-in to Facebook by being redirect to Facebook app)
-- Lastly, like all other phone OSes that allows browser embedding,
these embedded browsers does not share cookies -- that essentially
means the user would have type in their password in every application
-- worse if you turned on 2-step verification.
Understandably, much of the problem lies on how OAuth 2 itself works
and/or the UI paradigm of the mobile phone OSes. However, there are
many of the aspects that could be addressed by the OS itself -- and we
definitely need to address that, because we are Mozilla -- the one
organization that build product with security and privacy in mind, and
ultimately, vowed to protect user sovereignty.
Looking forward to hear feedback from all.
On Sun, May 26, 2013 at 1:05 AM, Tim Chien <
timd...@mozilla.com> wrote:
> To store and expose username/password in the OS, we would probably
> need a Keychain API, like what every OS out there do; however, I would
> argue that it's hard to do it right and hard to do in anyway safer
> than what we do now, therefore we should avoid doing so.
>
> For OAuth tokens, I tend to think it's each app's responsibility to
> get their own tokens; OAuth tokens are bound by their limited scope,
> if all FxOS apps shares the same token, it's kind of defeat the
> purpose of authorization management that OAuth offers. There shouldn't
> be a "shared storage" for tokens in any way.
>
> However, I would like to see if we could have the underling pieces
> ready in our OS so that every authentication vendor could offer their
> SDK or library on top of it (*including* Mozilla Persona). Currently,
> the datajar(?) of all the packaged apps are isolated; that means, the
> user would have to log-in Facebook again and again in every app when
> the app ask for a OAuth token (and again when OAuth token expires). We
> should, for example, bring the user to Facebook web app for the
> authentication flow (or better, bring the user to the Trusted UI with
> Facebook).
>
> This is a little different than the data provider apps Andreas
> proposed as they are not invisible (and they shouldn't be coz the user
> would have to do authentication and authorization on that UI).
>
> The fix would probably involve the greater app-to-app communication
> API discussion, unfortunately.
>
> On Sat, May 25, 2013 at 5:53 AM, Andrew Sutherland
> <
asuth...@asutherland.org> wrote:
>> On 05/24/2013 01:25 PM, Etienne Segonzac wrote:
>>>
>>> How are we going to implement this?
>>> The good thing is, we don't even have an ugly hack at our disposal to make
>>> this work.
>>
>>
>> I've discussed an approach to this with Jonas Sicking, James Lal, Brian
>> Smith, and others in the past as it relates to e-mail and calendar.
>>
>> In general, we thought adding a shared credential/password manager would be
>> a good thing for the following use cases:
>> 1) allow FTU setup (which was a partner request at the Berlin work week that
>> ended up not getting any traction)
>> 2) only change your password in one place
>> 3) secure credentials better
>>
>> #3 is somewhat of a concern right now for e-mail. We just store your
>> credentials in cleartext in our IndexedDB database. In the event of app
>> compromise, the credentials are accessible. In contrast, if we had a
>> credential manager and enabled mozTCPSocket to understand the opening
>> stanzas of IMAP and SMTP through authentication, we could make it so the
>> e-mail app never actually touches your credentials. (Just adding
>> "sock.sendCredentials()" is dangerous because you can get the server to echo
>> stuff back to you.) Authentication happens very early on for both
>> protocols, so it's very little code to move to chrome-space.
>>
>> Andrew
>>
>> _______________________________________________
>> dev-gaia mailing list
>>
dev-...@lists.mozilla.org
>>
https://lists.mozilla.org/listinfo/dev-gaia
>
>
>
> --
> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
> OS, Mozilla Corp. (Taiwan)
--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)