OAuth flow for packaged Open Web Apps (was: Re: Global accounts management in FirefoxOS)

[Tim Chien]

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)

[JOSE MANUEL CANTERA FONSECA]

El 18/06/13 04:50, "Tim Chien" <timd...@mozilla.com> escribió:

>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.

I strongly disagree with this statement. The current approach for Oauth 2
flows is totally correct.

>
>The related bug is here:
>https://bugzilla.mozilla.org/show_bug.cgi?id=883510#c12

Yes and a fix is there.

>
>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.

Gaia apps are packaged apps but as they live in a browser environment they
can open up browsing contexts which in the end can perform Oauth 2 flows
seamlessly.

>
>[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.)

They are using the implicit grant flow : quoted from the Oauth 2.0 IETF
spec

"The implicit grant is a simplified authorization code flow optimized
for clients implemented in a browser using a scripting language such
as JavaScript. In the implicit flow, instead of issuing the client
an authorization code, the client is issued an access token directly"

"Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application),
since it reduces the number of round trips required to obtain an
access token."

"The authorization server issues the registered client a client
identifier -- a unique string representing the registration
information provided by the client. The client identifier is not a
secret; "

>-- 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.

Mozbrowser is not needed, you get the mozbrowser by calling window.open

>-- 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.

If you want to "improve" the current solution you can do that but please
do that in future versions.

In the current version what we need to do is:

A/ Have the proper registerd client_ids (vanilla or whitelisted) that will
act as OAuth consumers. Those client_ids can be registered by Mozilla or
partners. For instance, Telefónica has a different client_id for Facebook
because it is whitelisted to have more privileges.

B/ Have the proper owned redirection domains that guarantee that nobody
else can get access to the tokens

C/ Update the corresponding Gaia resources (manifest, parameters.js, etc.)
applications-data.js to point and generate the correct configuration that
allow to run the Oauth 2 apps, for the different partners and
configurations.

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Tim Chien]

Thank you for you quick reply.

On Tue, Jun 18, 2013 at 3:21 PM, JOSE MANUEL CANTERA FONSECA
<jm...@tid.es> wrote:
> El 18/06/13 04:50, "Tim Chien" <timd...@mozilla.com> escribió:
>
>>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.
>
> I strongly disagree with this statement. The current approach for Oauth 2
> flows is totally correct.
>

No it's not, as explained below.

The "implicit grant flow" is what commonly known as the "user-agent
flow". Anyhow, terminology is not important.

On the provider facing side, we are indeed declare ourselves as an
"user-agent flow" OAuth 2 client, but there is one key difference: For
Contact app, at the very end, we rely on Gecko to redirect [1] the
declared redirect_uri to an app:// url. and for Calendar app, we rely
on mozbrowserlocationchange to get the token from the 404'd
https://oauth.gaiamobile.org/ callback.

[1] Implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=852848

Neither are standard "user-agent flow" specified in the OAuth 2 spec
nor by the provider.

>>-- 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.
>
> Mozbrowser is not needed, you get the mozbrowser by calling window.open

But a Gecko redirection is needed in order to complete the flow
without actually rely on a http/https host.

>
>>-- 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.
>
>
> If you want to "improve" the current solution you can do that but please
> do that in future versions.
>

I DO intend improve the future versions start by pointing out
potential flaw of our current practice, like
https://bugzilla.mozilla.org/show_bug.cgi?id=882398

(sorry for pointing security bug on a public thread)

> In the current version what we need to do is:
>
> A/ Have the proper registerd client_ids (vanilla or whitelisted) that will
> act as OAuth consumers. Those client_ids can be registered by Mozilla or
> partners. For instance, Telefónica has a different client_id for Facebook
> because it is whitelisted to have more privileges.
>
> B/ Have the proper owned redirection domains that guarantee that nobody
> else can get access to the tokens
>

The ineffectiveness of this step is documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=882398
I will redirect security-sensitive comments to the confidential bug.

> C/ Update the corresponding Gaia resources (manifest, parameters.js, etc.)
> applications-data.js to point and generate the correct configuration that
> allow to run the Oauth 2 apps, for the different partners and
> configurations.

This is arguablely the alternative proper fix to bug 883510, but the patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=883510#c5
doesn't do what you say here (allowing applications-data.js to change
the URL in manifest)

However, as Fabrice and I point out in the bug #c0 and #c1,
specifically for Facebook, we could simply prevent
applications-data.js to change the redirect URL and always lock the
URL to https://www.facebook.com/connect/login_success.html; It's
actually easier than (C).

So for *this version*, have we reach an agreement on how to fix bug 883510?

Lastly, I would like to share some thought on security.

The problem with coding your own security-sensitive features is that
you will probably never do it right, so it's better to do it by the
book. For example, here is a good example on things could happen if
devs try to be smart and create a hash function to store passwords in
database: https://coderwall.com/p/nnyida

The "book", in this case, is the complete flow described OAuth 2 spec
or the documentation from providers. Given the fact we are being
prevented from using provider-provided libraries (because of how
packaged app works), we need to be vigilant and know that we are
dealing when we code our own stuff; mixing the two OAuth 2 flow ...
would work, but it would only work to a certain extend, and the last
thing I want would be having Mozilla break it's promise to the users.

[Tim Chien]

I googled the wrong URL. Will find the correct one (if I could find it).

Basically it was a series of case studies on how devs could come up a
hash calculation function and how each function is being cracked,
including the one listed in this article. At the end, the author
suggest the engineers simply look for built-in crypt function or
libraries that is known to be secure.

On Tue, Jun 18, 2013 at 3:57 PM, Tim Chien <timd...@mozilla.com> wrote:
> The problem with coding your own security-sensitive features is that
> you will probably never do it right, so it's better to do it by the
> book. For example, here is a good example on things could happen if
> devs try to be smart and create a hash function to store passwords in
> database: https://coderwall.com/p/nnyida
>

[Jan Jongboom]

Regarding the facebook auth ios5 flow. This is also perfectly possible with WebActivities at the moment. For our internal services we have an app that acts as an auth broker and that can be called through a web activity. It will return an OAuth token to be used to authenticate with services on our platform.

[cool...@gmail.com]

I've been searching around, but I can't find the appropriate method for redirecting back to an app during the OAuth flow.

I've seen several references to the Gaia Calendar app, but this doesn't redirect flow back to the app.

I've read about the redirects option in manifest.webapp, but I don't understand what url scheme I would need to use in an oauth redirect_url to use the allowed redirect.

[Fabrice Desré]

You can use an http(s) url scheme in your "public" redirect url. We will
then map it to an app:// url that is local to your app. Look for example
at the email app:
https://mxr.mozilla.org/gaia/source/apps/email/manifest.webapp#76

Fabrice
--
Fabrice Desr�
b2g team
Mozilla Corporation