Questions about using FirefoxAccount information

Lloyd Hilaiel lhilaiel at mozilla.com
Thu Nov 14 00:42:11 PST 2013


On Nov 14, 2013, at 12:30 AM, JR Conlin <jrconlin at mozilla.com> wrote:

> On 2013/11/13 2:14 PM, Ryan Kelly wrote:
>> On 14/11/2013 6:51 AM, JR Conlin wrote:
>>> As I understand it, login is performed by a gherkin script on the
>>> browser that returns a certificate. The server I'm building is not
>>> node.js, so I have a few questions about certificate management:
>> 
>> At a high level, the login flow from the server's perspective is
>> completely identical to the exiting BrowserID login flow (which probably
>> explains why we haven't documented it separately):
>> 
>>  * Client talks to FxA server to obtain an identity certificate
>> 
>>  * Client uses certificate to sign an identity assertion
>> 
>>  * Client delivers identity assertion to the server to login
>> 
>>  * Server verifies the identity assertion and exchanges it for
>>    e.g. a session cookie
> 
> As noted, I am working on the Where's My Fox server portion.
> 
> Just so I'm clear, the current design has two aspects to it:
> * A FxOS client
> * A server with it's own UI.
> 
> The device and server need to coordinate and agree upon the fact that
> the user is the correct individual. As I understand, the device could
> send the verified certificate UUID (and store it for future use).
> Likewise the server could authenticate the cert and fetch the same UUID,
> only allowing if the two match. This would prevent the need to exchange
> the certificate between the two, correct?

The user’s email and UUID will be embedded in an identity assertion.  You should verify the validity of the assertion and extract both.

>>> 1) Is the certificate sensitive information (should I protect it from
>>> inadvertent exposure or is it encrypted such that it's not an issue)?
>> 
>> Yes it is, but the certificate itself should never leave the client
>> device, so the server shouldn't need to worry about it.  Only signed
>> identity assertions are seen by the server.
> 
> Ah, so possibly a confusion in terminology on my part. I thought that
> "certificate" was the new name for the old BrowserID "assertion". If the
> previous understanding is correct, however, I need not send the signed
> assertion to the server at all.

I think you do need to send assertions to your server to establish a session.  The assertion identifies and authenticates the user to your service.  Allowing authentication to occur via the assertion means you don’t need any other mechanism for authing the user.

From an “RP” (your server's) perspective, support of FxOS with FxA inside (tm) is almost completely analogous to how persona works today.  You get an assertion, validate the assertion, get the user’s email address (and uuid with fxa), and create a session.

is this confusing, or clarifying?

lloyd





More information about the Dev-fxacct mailing list