Integrate with the FxA verifier

VERIFIED FIXED

Status

VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: alexis+bugs, Assigned: alexis+bugs)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa+])

(Assignee)

Description

4 years ago
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?
(Assignee)

Updated

4 years ago
Flags: needinfo?(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": "4c352927cd4f4a4aa03d7d1893d950b8@msisdn.accounts.firefox.com",
  "status": "okay",
  "idpClaims: {
    lastVerifiedAt: 1389791283,
    verifiedMSISDN: "+442071838750"
  }
}

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
Flags: needinfo?(ckarlof)
https://github.com/mozilla-services/loop-server/commit/c10574474f10ee5e71e2ed161ad0680987985a4e
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
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?
Whiteboard: [qa+]
(Assignee)

Comment 4

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

ccing Benson so that he updates the staging env.
Flags: needinfo?(bwong)
Reopening this as puppet-config needs updates to get these values configurable via our deploy processes.
Status: RESOLVED → REOPENED
Flags: needinfo?(bwong)
Resolution: FIXED → ---
(Assignee)

Comment 6

4 years ago
I don't quite understand, should I do something to fix this?
: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.
These changes have gone out to Stage: see bug 1022887
Still need to verify that they go to Production.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Depends on: 1024222
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.