Closed Bug 1019564 Opened 10 years ago Closed 10 years ago

Integrate with the FxA verifier

Categories

(Hello (Loop) :: Server, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

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

References

Details

(Whiteboard: [qa+])

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?
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
Closed: 10 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+]
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 → ---
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
Closed: 10 years ago10 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.