1019564 - Integrate with the FxA verifier

Status: VERIFIED FIXED

(Hello (Loop) :: Server, defect)

Description

[Alexis Metaireau (:alexis)]

The code that currently leaves on the server uses the remote verifier via a library hosted at https://github.com/chilts/browserid-verify-node.

It doesn't seem to work well with Firefox Accounts, and I'm not sure to exactly understand why.

In order to fix this, It's possible to change how the library interacts with FxA, by sending the right contentType and assertion. Jaoo hacked something up that's working, but I would need to fully understand how this is supposed to work.

Chris, can you tell me if there is a reference client I should use to consume the endpoint at https://verifier.accounts.firefox.com/v2?

Is this version 2 compatible with BrowserID (in which case we should update the library I mentioned to use this v2 of the API) or is it something completely different?

Is it best to use a remote verifier or to do the verification locally?

Comment 1

[Chris Karlof [:ckarlof]]

> The code that currently leaves on the server uses the remote verifier via a library hosted at https://github.com/chilts/browserid-verify-node.

The correct repo for the production BrowserID verification service is:

https://github.com/mozilla/browserid-verifier

> Is it best to use a remote verifier or to do the verification locally?

I recommend using the remote verifier at https://verifier.accounts.firefox.com/v2

> Is this version 2 compatible with BrowserID (in which case we should update the library I mentioned to use this v2 of the API) or is it something completely different?

Yes it is compatible with BrowserID.

This is largely a v2 endpoint because it supports the v2 Browserid format, but it also supports the legacy v1 format. We're using the v1 format. More info here: http://lloyd.io/evolving-browserid-data-formats/

There is no reference client for the verifier. It is a single endpoint and you use it like:

$ curl -H 'Content-Type: application/json' \
  -d '{ "audience": "https://loop.firefox.com" , "assertion": "eyJhbG...ZEe7A" }'
  https://verifier.accounts.firefox.com/v2
{
  "audience": "https://loop.firefox.com",
  "expires": 1389791993675,
  "issuer": "msisdn.accounts.firefox.com",
  "email": "[e-mail]",
  "status": "okay",
  "idpClaims: {
    lastVerifiedAt: 1389791283,
    verifiedMSISDN: "[phone]"
  }
}

Extra claims are returned as within a sub-object called idpClaims.

An example of a service using this: https://github.com/mozilla-services/tokenserver/blob/175f266b8423a9a48a254044dae807c615ede292/tokenserver/views.py#L167

Comment 2

[Rémy Hubscher (:natim)]

https://github.com/mozilla-services/loop-server/commit/c10574474f10ee5e71e2ed161ad0680987985a4e

Comment 3

[James Bonacci [:jbonacci]]

Did we only want to code up the Production version of the Verifier?
as in https://verifier.accounts.firefox.com/v2 ?

or did we want the option of pointing to the Stage version for running loop-server Stage?
as in https://verifier.stage.mozaws.net/v2 ?

I am concerned that we might have a case where the Stage verifier has been updated with something crucial that has not yet been deployed to Production. Do we care?

Comment 4

[Alexis Metaireau (:alexis)]

We probably want stage to point to stage, you're right.

ccing Benson so that he updates the staging env.

Comment 5

[Benson Wong [:mostlygeek]]

Reopening this as puppet-config needs updates to get these values configurable via our deploy processes.

Comment 6

[Alexis Metaireau (:alexis)]

I don't quite understand, should I do something to fix this?

Comment 7

[James Bonacci [:jbonacci]]

:alexis I don't think so.
:whd and :mostlygeek are working on the OPs side of this bug.

I will make sure the changes make it to Stage and to Prod.

Comment 8

[James Bonacci [:jbonacci]]

These changes have gone out to Stage: see bug 1022887
Still need to verify that they go to Production.

Comment 9

[James Bonacci [:jbonacci]]

Changes should now be in Production.
Loop-Client Prod: https://bugzilla.mozilla.org/show_bug.cgi?id=1024180
Loop-Server Prod: https://bugzilla.mozilla.org/show_bug.cgi?id=1024222