1104304 - Require password for OAuth flow

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P1)

Description

[Mark Striemer [:mstriemer]]

Marketplace (webpay) uses a PIN during the payment flow. If a user forgets their PIN they need to enter their password before changing it. Currently there is no way to tell FxA that we need the user to enter their password so if the user is using their Sync account then they will not be prompted for a password. One could imagine this being useful to change certain account settings in a different app.

Supplying the prompt for password after n seconds param as 0 would work if it is sent in the signed JWT. I'm not sure if there is any replay protection in place or if that is something that must be handled by the app but getting the time that the password was entered might help to ensure that the user did recently authenticate.

Comment 1

[Chris Karlof [:ckarlof]]

Issue for a way to force the user to enter her password in an OAuth flow: https://github.com/mozilla/fxa-content-server/issues/1957

Issue for OAuth reliers to learn when the user last entered her password: https://github.com/mozilla/fxa-oauth-server/issues/181

Comment 2

[Andy McKay]

Can we confirm that this doesn't happen on Android?

Comment 3

[Chris Karlof [:ckarlof]]

ATM, login to Web reliers on Android should always require a password.

Comment 4

[Andy McKay]

Note that this API: https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-12 
Returns: "fxa-lastAuthAt - authentication time for this session (seconds since epoch)"

Which should allow us to verify on our end that the password has been entered by a user.

Comment 5

[Chris Karlof [:ckarlof]]

Andy, target date for when you need this?

Comment 6

[Andy McKay]

We were hoping to get Desktop payments out by the end of Jan. 2015.

Comment 7

[Ryan Kelly [:rfkelly]]

> Note that this API: https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-12 
> Returns: "fxa-lastAuthAt - authentication time for this session (seconds since epoch)"

Note that that API is not exposed in the oauth flow, you can only use that if you're dealing directly with raw FxA assertions.

IIUC the proposed flow will have the following moving parts:

1) A special query param you can include when initiating the oauth flow, that will force a password prompt even if the user is logged in.  This is https://github.com/mozilla/fxa-content-server/issues/1957.

2) An additional param in the final response from the oauth flow, giving the lastAuthAt timestamp, so you can check whether the password was actually entered.  This is https://github.com/mozilla/fxa-oauth-server/issues/181.

3) Potentially, some nice logic in https://github.com/mozilla/fxa-relier-client/ that securely combines (1) and (2) to give you what you want without having to check things manually.

Comment 8

[Ryan Kelly [:rfkelly]]

And if push really came to shove, we could ship with just (1) to provide some casual extra security.  IIRC the persona marketplace integration did the moral equivalent of this - you could tell it to "forceAuth" so that the user would be prompted to enter their password, but here was no way to securely validate that they had actually done so.

(I do not think we *should* ship that, but it's nice to know what the options are when there are tight timelines involved...)

Comment 9

[Chris Karlof [:ckarlof]]

> And if push really came to shove, we could ship with just (1) to provide some casual extra security.  

Indeed, this wouldn't be a regression over what is currently implemented with Persona.

Comment 10

[Chris Karlof [:ckarlof]]

> We were hoping to get Desktop payments out by the end of Jan. 2015.

Is this on schedule?

Comment 11

[Andy McKay]

(In reply to Chris Karlof [:ckarlof] from comment #10)
> > We were hoping to get Desktop payments out by the end of Jan. 2015.
> 
> Is this on schedule?

Yep.

Comment 12

[Shane Tomlinson [:stomlinson]]

A pull request(https://github.com/mozilla/fxa-content-server/pull/2019) is outstanding and waiting for final review. If all goes well, it should be merged today (20-Jan-2015) to ride the train out to prod for next week (the prod push day of week varies).

For an OAuth relier to force the user to authenticate as a specific email, a new action, `force_auth`, has been added. When redirecting to the FxA OAuth server, set `action=force_auth` and specify an `email` parameter.

e.g.,

window.location = 'https://oauth.accounts.firefox.com/v1/authorization?action=force_auth&email=<users_email>';

When on the content server, the user cannot modify the email address and must enter their password. If an account does not exist for the email address, the flow dead ends and the user cannot sign up.

Comment 13

[Kumar McMillan [:kumar]]

For others following the Marketplace side of this: We currently have a workaround that explicitly logs the user out before resetting the PIN so we'd like to wait until the server validation part lands (https://github.com/mozilla/fxa-oauth-server/issues/181) before making use of the action=force_auth URL parameter. Otherwise, our implementation would be less secure than it is now.

Comment 14

[Chris Karlof [:ckarlof]]

> We currently have a workaround that explicitly logs the user out before resetting the PIN so we'd like to wait until the server validation part lands (https://github.com/mozilla/fxa-oauth-server/issues/181) before making use of the action=force_auth URL parameter. Otherwise, our implementation would be less secure than it is now.

I'll leave for you to decide what's appropriate on the Marketplace side to do in response to a PIN reset. However, I think that using action=force_auth is strictly an improvement, with or without the server validation bit. By using action=force_auth, you can at least guarantee that the UI forces the user to enter her password.

Comment 15

[Kumar McMillan [:kumar]]

oops, disregard my statement at comment #13, we don't have any workaround in place for this. So, yeah, we should at the very least implement action=force_auth ASAP even before the server verification is ready.

Comment 16

[Caitlin Galimidi [:c8o]]

hi team 

apps on desktop are now live in the firefox browser! woohoo!

desktop payments in apps is targeted to launch next week, 27-January.
however, it looks like this bug is a P1 or P2 and will block our launch if not fixed.

when is this fix scheduled for release?


bestest and many thanks,
caitlin

Comment 17

[Kumar McMillan [:kumar]]

Hi Caitlin. We just discussed this; the Marketplace side is ready for the initial implementation (i.e. supporting action=force_auth) so I'll put it in my queue.

Comment 18

[Ryan Kelly [:rfkelly]]

I've started on the second half of the necessary server changes, adding a way to check the freshness of a session once the oauth dance is completed:

  https://github.com/mozilla/fxa-oauth-server/pull/205

Kumar, please weigh in on the proposed change and whether it will give you what you need to securely verify that the password was re-entered.

We'll target this for the next FxA server train, which will go out in two weeks time.  I'll see about getting it deployed to a testing server ASAP; please feel free to bug me if you're blocked waiting for this to show up somewhere testable.

Comment 19

[Kumar McMillan [:kumar]]

I think that should work for us. My one comment on the PR was that it should be a UTC unix timestamp to make dealing with it easier. What I think we'll do is set a session variable with the UTC timestamp on our server when the user requests a PIN reset. Then we can check the last auth timestamp from the token response here: https://github.com/mozilla/webpay/blob/master/webpay/auth/views.py#L187

There is an edge case where the user decides to abort the PIN reset but we can probably work that out on our end.

Comment 20

[Kumar McMillan [:kumar]]

Hey Shane, is your action=force_auth patch live on https://oauth-stable.dev.lcip.org/ ? When I make a request to /v1/authorization?state=...&email=...&action=force_auth it's not redirecting to a login URL with the force_auth param. Is that expected? I'm also not sure it is forcing the authentication because I still see a 'Use a different account' link.

Comment 21

[John Morrison [:jrgm]]

Kumar. The updated version is now on https://{oauth-,}stable.dev.lcip.org/. 

$ curl https://stable.dev.lcip.org/ver.json; echo ; curl https://oauth-stable.dev.lcip.org/; echo 
{"version":"0.29.0","commit":"f60b92ddf39de716ff0d09e8a0ed82cb9609c959","l10n":"2ad63d07ff","tosPp":"29ec46747a"}
{
  "version": "0.29.0",
  "commit": "281b15a2ad3480cbb8164eb51426c543bab22ac9"
}

Comment 22

[Shane Tomlinson [:stomlinson]]

Thanks :jrgm!

:kumar, I did a manual check to ensure the "latest" oauth server acts as expected with the following url (email removed):

https://oauth-stable.dev.lcip.org/v1/authorization?scope=profile&state=8b318b378af542f69d41e66043da0229&client_id=11c73e2d918ae5d9&action=force_auth&email=<email>

I was redirected to the /oauth/force_auth page of the content server, looks like things are now good to go!

Comment 23

[Kumar McMillan [:kumar]]

Yep! I see /oauth/force_auth too now. Thanks.

Comment 24

[Kumar McMillan [:kumar]]

I spun off bug 1127509 for Marketplace to integrate with the new server changes when they're ready

Comment 25

[Kumar McMillan [:kumar]]

Webpay now uses action=force_auth for all PIN resets. https://github.com/mozilla/spartacus/pull/198