Questions about using FirefoxAccount information

JR Conlin jrconlin at mozilla.com
Thu Nov 14 08:46:47 PST 2013


On 2013/11/14 12:42 AM, Lloyd Hilaiel wrote:
> 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.

Ah, I'm not really authing the user in this case. It's more a question
of providing a globally unique identifier for a given individual so that
the device and web site can coordinate. I can also easily hash the GUID
if disclosure of that info might be potentially damaging.

Authorization would be contained on the mobile device and the web
control panel, where sessioning makes more sense.
> 
> 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?
> 
It's very clarifying, thanks!
> lloyd
> 
> 




More information about the Dev-fxacct mailing list