Sounds absolutely reasonable. The problem I'm having is that sending the
assertion from the device fails to validate on the server. On the
client, we're using
navigator.mozId.watch({
wantIssuer: "firefox-accounts",
audience: "http://oauth.dev.lcip.org";,
... })
On the server, I'm currently using
POST https://oauth.dev.lcip.org/v1/authorization
{client_id: ... , assertion: ... , state: ... }
Should I be using the browserid validation endpoint on the server instead?
On 2014/5/22 10:01 AM, Chris Karlof wrote:
> +dev-fxacct
>
> Oauth isn't supported natively on device at the moment. It's a web only flow.
> I'd suggest that for 2.0, the FxOS apps rely on getting BiD assertions from
> navigator.mozId and submit those to our BiD verifier on the backend to get
> the logged in user. We can improve/unify these in the future.
>
> -chris
>
>
> On May 22, 2014, at 8:49 AM, JR Conlin <[email protected]> wrote:
>
>> I have set the audience on the code in the FxOS emulator to
>> oauth.dev.lcip.org and still fail to validate the assertion (400/104).
>>
>>
>>
>> On 2014/5/21 5:34 PM, Sean McArthur wrote:
>>> The audience needs to match the oauth server, so in this case,
>>> oauth.dev.lcip.org <http://oauth.dev.lcip.org>.
>>>
>>> Roping in Karlof, cause I'm not sure about the flow. I imagine we'd want
>>> FxOS to also go through the content server, but what do I know.
>>>
>>> On May 21, 2014 7:19 PM, "JR Conlin" <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Having talked with ggp, I think I kinda agree that WebApps should stick
>>> with using navigator.mozId for some of this, rather than fall back to a
>>> complicated set of iframes and postmessage hooks[1].
>>>
>>> That leads me back to trying to validate the passed assertion using
>>> POST https://oauth.dev.lcip.org/v1/authorization
>>>
>>> https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1authorization
>>>
>>> This is currently failing for me:
>>>
>>> {"assertion":"eyJhbGciOiJSUzI1NiJ9.eyJmeGEtZ2VuZXJhdGlvbiI6MTQwMDE5NDA0OTY5MiwiZnhhLWxhc3RBdXRoQXQiOjE0MDA3MTA5NzYsImZ4YS12ZXJpZmllZEVtYWlsIjoidGVzdCtiMmdAdW5pdGVkaGVyb2VzLm5ldCIsInB1YmxpYy1rZXkiOnsiYWxnb3JpdGhtIjoiRFMiLCJ5IjoiYWIxZGY4YTkxMzRmY2YzYWEwZGQ1OTJlZDg5MDNjMTAzZjA0YzQxMGYxMmQ5OGFiMGU1NjY4MDc0NDAzZjU1ZTZiM2NkOTRmN2EzNTA1MTI4ZDRiZmUyNWVhZGJlYjM0MzdkNmY0YTU5Y2ZiYjIzYTNiYTVlZjMxMmMzZDJlNWJlNDZjODAzMWQxMGY5NTQ0ZDNlMzhiOGZhOThjYmRjODQ1MmRmZjZiMDlkMjViMTU3ZWQ0ZDM1N2ZiNmU1MjU5OTM0YjI0Mjk0Y2E5MmU2NzZjZjFmZDUxNjdkMDg2ZTQyMDc3MjFjNzU3NTRlZWJiNTBiNjVhN2I4NDEzYWEzYSIsInAiOiJmZjYwMDQ4M2RiNmFiZmM1YjQ1ZWFiNzg1OTRiMzUzM2Q1NTBkOWYxYmYyYTk5MmE3YThkYWE2ZGMzNGY4MDQ1YWQ0ZTZlMGM0MjlkMzM0ZWVlYWFlZmQ3ZTIzZDQ4MTBiZTAwZTRjYzE0OTJjYmEzMjViYTgxZmYyZDVhNWIzMDVhOGQxN2ViM2JmNGEwNmEzNDlkMzkyZTAwZDMyOTc0NGE1MTc5MzgwMzQ0ZTgyYTE4YzQ3OTMzNDM4Zjg5MWUyMmFlZWY4MTJkNjljOGY3NWUzMjZjYjcwZWEwMDBjM2Y3NzZkZmRiZDYwNDYzOGMyZWY3MTdmYzI2ZDAyZTE3IiwicSI6ImUyMWUwNGY5MTFkMWVkNzk5MTAwOGVjYWFiM2JmNzc1OTg0MzA5YzM
iLCJnIj
o
>> iYzUyY
>>>
>>> TRhMGZmM2I3ZTYxZmRmMTg2N2NlODQxMzgzNjlhNjE1NGY0YWZhOTI5NjZlM2M4MjdlMjVjZmE2Y2Y1MDhiOTBlNWRlNDE5ZTEzMzdlMDdhMmU5ZTJhM2NkNWRlYTcwNGQxNzVmOGViZjZhZjM5N2Q2OWUxMTBiOTZhZmIxN2M3YTAzMjU5MzI5ZTQ4MjliMGQwM2JiYzc4OTZiMTViNGFkZTUzZTEzMDg1OGNjMzRkOTYyNjlhYTg5MDQxZjQwOTEzNmM3MjQyYTM4ODk1YzlkNWJjY2FkNGYzODlhZjFkN2E0YmQxMzk4YmQwNzJkZmZhODk2MjMzMzk3YSJ9LCJwcmluY2lwYWwiOnsiZW1haWwiOiIyOTY1OTU4Yjc3MmI0YjhiOGZhYzU0NWM1YmY3MWU1ZkBhcGkuYWNjb3VudHMuZmlyZWZveC5jb20ifSwiaWF0IjoxNDAwNzEwOTY4MTYxLCJleHAiOjE0MDA3MzI1NzgxNjEsImlzcyI6ImFwaS5hY2NvdW50cy5maXJlZm94LmNvbSJ9.CfzEQEJSBhfPyn7gzMpYIdGljUq1Hi8WaOOrfKs41Y1Zx0m9Tn2WciqgjYl6QhFvH7dXsHHfghxNYPCewt7l3pfCLuDhVdV1030L5dFtrebAsSJepXF5xkWpT0QgXCdMdkwk_hZYxdJZHufbtoBJCPozrwzl5PrelgYsne-8F_kCRk5LkKFqBKVh28aUiSOANPSA8-NZoADe0zIJ2iv_zUgX2pNYTZGJ5WxYCzI2QWSFR0xanGbtejRx8qBdjk9qBJ2sR9h8n2d87ITwiF8E4smFV4htfopkGrQsGBUWy91Tqc4LUVNlk55VHyOCwwWaPpVE7pgAAENjHM_K0eoUKA~eyJhbGciOiJEUzEyOCJ9.eyJleHAiOjIxODkxMTEzNDA1OTMsImF1ZCI6Imh0dHA6Ly9hcGkuYWNjb3VudHMuZmlyZWZ
veC5jb2
0
>> ifQ==.q
>>>
>>> yvgrkEr2eipB2EKvd3q9OZqw54NtoEHKoteZ7VZTR7V1yv6lZJhTQ==","client_id":"344e8ade775e8b15","state":"state"}
>>> ### parseBody: {"code":400,"errno":104,"error":"Bad
>>> Request","message":"Invalid assertion"}
>>>
>>> The assertion decompiles from base64 correctly (the body is:
>>>
>>> {"fxa-generation":1400194049692,"fxa-lastAuthAt":1400696318,"fxa-verifiedEmail":"[email protected]
>>>
>>> <mailto:test%[email protected]>","public-key":{"algorithm":"DS","y":"93c626d9e10c2f38cad40a9c8d10469da5e412b1f06f2410ec7a07d9b7081a9d839bbd8b4c29a4d385626efae8e8234dfecb6098d6bce1433eed6eb99381f0888d2e7bcfc2e8138e62ebe584f50c9e8e197ff77bc3aec30170b7e1a05ceb5b6c9cbd34d0b82c9cf8d3d5da553837a5a1405e05c0b1e15b8bc4c715572c81c9e0","p":"ff600483db6abfc5b45eab78594b3533d550d9f1bf2a992a7a8daa6dc34f8045ad4e6e0c429d334eeeaaefd7e23d4810be00e4cc1492cba325ba81ff2d5a5b305a8d17eb3bf4a06a349d392e00d329744a5179380344e82a18c47933438f891e22aeef812d69c8f75e326cb70ea000c3f776dfdbd604638c2ef717fc26d02e17","q":"e21e04f911d1ed7991008ecaab3bf775984309c3","g":"c52a4a0ff3b7e61fdf1867ce84138369a6154f4afa92966e3c827e25cfa6cf508b90e5de419e1337e07a2e9e2a3cd5dea704d175f8ebf6af397d69e110b96afb17c7a03259329e4829b0d03bbc7896b15b4ade53e130858cc34d96269aa89041f409136c7242a38895c9d5bccad4f389af1d7a4bd1398bd072dffa896233397a"},"principal":{"email":
>>> "[email protected]
>>>
>>> <mailto:[email protected]>"},"iat":1400696310447,"exp":1400717920447,"iss":"api.accounts.firefox.com
>>> <http://api.accounts.firefox.com>"}'
>>> which has the correct verifiedEmail in it.
>>>
>>> I'm currently setting the audience to the oauth host
>>> "https://accounts.dev.lcip.org";, however I've tried just about every
>>> other audience target I can think of and none of the assertions are
>>> validating. Am I misunderstanding what the flow should be?
>>>
>>> [1] the original app contract is to use mozId, mostly because then you
>>> get the joy of the event handlers for login/logout, etc. While it's
>>> possible to do that as well as do the iframe based login, it seems
>>> redundant and requires significant reworking of the client code to get
>>> this right. The docs provide a means for the server to get the
>>> information using an assertion. Frankly, all I really care about is
>>> validating the damn assertion and I'll rip the <expletive>
>>> "fxa-verifiedemail" out of it myself.
>>>
>>>
>>> On 2014/5/20 4:23 PM, Sean McArthur wrote:
>>>> Feels better to talk about Weapons of Mass Destruction...
>>>>
>>>> Here's the validation that Hapi does before I ever get to touch the
>>>> request:
>>>
>>> https://github.com/mozilla/fxa-oauth-server/blob/master/lib/routes/authorization.js#L35-L40
>>>>
>>>> The assertions I'm generating in the test suite pass, so what's
>>> different?
>>>>>
>>>>> On 5/20/2014 4:13:56 PM, Jed Parsons <[email protected]
>>> <mailto:[email protected]>>wrote:
>>>>>
>>>>>
>>>>> Flan of Mass Destruction?
>>>>>
>>>>> Flamingoes of Mass Diversity?
>>>>> Fresnel lenses of Mass Defocus?
>>>>>
>>>>>
>>>>> On Tue, May 20, 2014 at 4:09 PM, JR Conlin <[email protected]
>>> <mailto:[email protected]>
>>>>> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>>>>
>>>>> Well, technically, it's now Find My Device.
>>>>>
>>>>> So, you know, FMD.
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Jed Parsons" <[email protected]
>>> <mailto:[email protected]> <mailto:[email protected]
>>> <mailto:[email protected]>>>
>>>>> To: "Sean McArthur" <[email protected]
>>> <mailto:[email protected]>
>>>>> <mailto:[email protected] <mailto:[email protected]>>>
>>>>> Cc: "JR Conlin" <[email protected]
>>> <mailto:[email protected]> <mailto:[email protected]
>>> <mailto:[email protected]>>>
>>>>> Sent: Tuesday, May 20, 2014 4:08:51 PM
>>>>> Subject: Re: FxA and assertions from mobile devices
>>>>>
>>>>> Is our group the only one that calls this thing WMD? Because I
>>>>> love that.
>>>>>
>>>>>
>>>>> On Tue, May 20, 2014 at 4:04 PM, Sean McArthur
>>>>> <[email protected] <mailto:[email protected]>
>>> <mailto:[email protected] <mailto:[email protected]>>>wrote:
>>>>>
>>>>>> The `client_id` is the unique id I gave you for WMD. The OAuth
>>>>> server
>>>>>> needs to get this back, so it knows what application will
>>> be getting
>>>>>> permission to view a user's data.
>>>>>>
>>>>>> On 5/20/2014 4:02:46 PM, Jed Parsons <[email protected]
>>> <mailto:[email protected]>
>>>>> <mailto:[email protected] <mailto:[email protected]>>>wrote:
>>>>>>
>>>>>> Oh this is the oauth stuff! Ok. Welp, I really want to learn
>>>>> more about
>>>>>> this, too. I'm not sure how this is done on client, or will be
>>>>> done. I
>>>>>> would guess that, on desktop, this is all in the jelly
>>>>> somewhere? But we
>>>>>> don't have this on fxos, as far as I know.
>>>>>>
>>>>>> Seanmonstar, do you know more about what bits are where?
>>>>>>
>>>>>> Thanks
>>>>>> j
>>>>>>
>>>>>>
>>>>>> On Tue, May 20, 2014 at 3:13 PM, JR Conlin
>>> <[email protected] <mailto:[email protected]>
>>>>> <mailto:[email protected] <mailto:[email protected]>>>
>>> wrote:
>>>>>>
>>>>>>> Thanks, I'll dig into that.
>>>>>>>
>>>>>>> The client_id is a parameter specified in the docs:
>>>>>>>
>>>>>>>
>>>>>
>>>
>>> https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1authorization
>>>>>>>
>>>>>>> If I don't pass a client_id in the object, the assertion
>>> returns an
>>>>>>> error pointing to the assertion field. (my apologies, but I've
>>>>> had to
>>>>>>> switch branches due to a time constraint.)
>>>>>>>
>>>>>>> On 2014/5/20 2:34 PM, Jed Parsons wrote:
>>>>>>>>
>>>>>>>> This is where the RP's onlogin() method gets called, so you
>>>>> could start
>>>>>>>> monkey-patching here:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> https://mxr.mozilla.org/mozilla-central/source/dom/identity/nsDOMIdentity.js#482
>>>>>>>>
>>>>>>>> But what is this client_id of which you speak? Do you
>>> mean a
>>>>> unique
>>>>>>>> device id? Or FxAccounts user id?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 20, 2014 at 2:25 PM, JR Conlin
>>>>> <[email protected] <mailto:[email protected]>
>>> <mailto:[email protected] <mailto:[email protected]>>
>>>>>>>> <mailto:[email protected]
>>> <mailto:[email protected]> <mailto:[email protected]
>>> <mailto:[email protected]>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Sorry if this is obvious, but I'm not at all clear
>>> on the
>>>>> flow, and
>>>>>>> I'm
>>>>>>>> trying to piece things together as best I can.
>>>>>>>>
>>>>>>>> On FxOS, a webapp watches firefox-accounts and binds a
>>>>> function to
>>>>>>>> onlogin. That function gets an assertion record as
>>> it's only
>>>>>>> argument,
>>>>>>>> which is then passed to it's server for login purposes.
>>>>>>>>
>>>>>
>>> https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md
>>>>>>>>
>>>>>>>> The server can then call POST /v1/authorization
>>> passing the
>>>>>>> assertion.
>>>>>>>> I'm not sure how the server knows the client_id of the
>>>>> request. (I'm
>>>>>>>> trying to dig into it using the emulator, and I lack
>>>>> knowledge of
>>>>>>> the
>>>>>>>> space.)
>>>>>>>>
>>>>>>>> Is this correct? If not, can you point me to the docs
>>>>> that might
>>>>>>> show
>>>>>>>> the app flow so I can try to chicken wire in the
>>>>> client_id to get
>>>>>>> passed
>>>>>>>> down to the server?
>>>>>>>>
>>>>>>>> thanks!
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
