952347 - Define forceAuthentication and refreshAuthentication in mozId.request for FxAccounts

Status: RESOLVED FIXED

(Core Graveyard :: Identity, defect)

Description

[Sam Penrose]

Vet this proposal:

Add forceAuthentication and refreshAuthentication parameters to navigator.mozId.request(). The refreshAuthentication parameter has a non-negative integer value representing a grace period in seconds. If the user has not authenticated (i.e. by providing their password) since the end of the grace period, we trigger the auth flow. If they have, we return a valid assertion. forceAuthentication is an alternate spelling of {refreshAuthentication: 0}.

Comment 1

[Fernando Jiménez Moreno [:ferjm]]

Sam's proposal makes sense to me.

Jed, Lloyd?

Comment 2

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Overall, that makes sense to me, too, though I'm trying to imagine a case where I would want to use refreshAuthentication with a non-zero value.  Is there one?

Also, I can't remember why forceAuthentication doesn't start by killing the fxa auth token.  Did we decide not to do that?  If we killed the token at the start of request(), would that not do the same thing?  (Sorry if I'm being dim and forgetting something we've already discussed.)

Comment 3

[Chris Karlof [:ckarlof]]

(In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from comment #2)
> Overall, that makes sense to me, too, though I'm trying to imagine a case
> where I would want to use refreshAuthentication with a non-zero value.  Is
> there one?
> 

UX reasons. If you're making a series of purchases, maybe you don't require an auth flow for every single one, but only require if you haven't done it in the last 60s. Then again, there's this:

http://www.consumerreports.org/cro/news/2014/01/google-play-store-lets-your-kid-spend-like-a-drunken-sailor/index.htm

> Also, I can't remember why forceAuthentication doesn't start by killing the
> fxa auth token.  Did we decide not to do that?  If we killed the token at
> the start of request(), would that not do the same thing?  (Sorry if I'm
> being dim and forgetting something we've already discussed.)

FWIW, the proposal for the API endpoint to support this (/session/refresh) requires an existing session token:

https://github.com/mozilla/fxa-auth-server/issues/307#issuecomment-28598232

Comment 4

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Thanks, Chris.  I had forgotten that the API endpoint requires an existing session token.  That makes sense with all the other API calls that are related to it.

As for the UX idea, I can't imagine making more than one purchase per minute, unless I was using a slot machine or other gambling app (though I suppose those probably will exist somewhere).  Under what healthy circumstances could one wish to perform in-app purchases with such frequency?  But with the Mozilla marketplace, I think we have better and less-annoying child-proofing than the Play store does through the PIN code that Marketplace requires for in-app purchases.

It seems like we could conceivably have a potential timing issue with refreshAuthentication:0, given enough clock skew, but I can't imagine how to exploit it, since skew is corrected with each hawk request to the auth server.

So yes, I'm in favor of implementing Sam's proposal.

Comment 5

[Sam Penrose]

I would hope we can implement the grace period client side, whether in FxAccounts.jsm or elsewhere, by adding something like:

  this.lastAuthedWithServer = new Date();

to each call that has done so, then expose that value somewhere in toolkit/identity, so that the first lines of refreshAuthentication become something like:

  if (gracePeriod) {
    // different "this" from the above
    if (this.lastAuthedWithServer && (this.lastAuthedWithServer + gracePeriod*1000) > new Date()) {
      return getAssertion(); // but which call?
    }
  }
  // normal flow, ending with
  this.lastAuthedWithServer = resultFromFxA.lastAuthedWithServer; // not sure about this object either

I confess I'm not seeing a good place for this logic in the existing code, however, and it has to be simple to be better than going all the way down to FxAccounts.jsm

(In reply to Jed Parsons (use needinfo, please) [:jedp, :jparsons] from comment #4)
> It seems like we could conceivably have a potential timing issue with
> refreshAuthentication:0, given enough clock skew, but I can't imagine how to
> exploit it, since skew is corrected with each hawk request to the auth
> server.

Comment 6

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

If warner's plan is implemented, the lastAuth time is going to be written on the token when it comes back from the server, and also inscribed in the certificate: https://github.com/mozilla/fxa-auth-server/issues/307#issuecomment-28611197

So I think that should make things a bit easier since the information will be available in the signedInUserStorage.

Comment 7

[Sam Penrose]

I'm marking this as Resolved since Fernando is working on the implementation.