That code would make the verifier error, stating wrong scheme. It's https.
I'm submitting the assertion to the verifier we host, can't recall the URL,
in case you want to see the response I receive with your assertion.
On May 22, 2014 1:57 PM, "JR Conlin" <[email protected]> wrote:
>
> 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.eyJmeGEtZ2VuZXJhdGlvbiI6MTQwMDE5NDA0OTY5MiwiZnhhLWxhc3RBdXRoQXQiOjE0MDA3MTA5NzYsImZ4YS12ZXJpZmllZEVtYWlsIjoidGVzdCtiMmdAdW5pdGVkaGVyb2VzLm5ldCIsInB1YmxpYy1rZXkiOnsiYWxnb3JpdGhtIjoiRFMiLCJ5IjoiYWIxZGY4YTkxMzRmY2YzYWEwZGQ1OTJlZDg5MDNjMTAzZjA0YzQxMGYxMmQ5OGFiMGU1NjY4MDc0NDAzZjU1ZTZiM2NkOTRmN2EzNTA1MTI4ZDRiZmUyNWVhZGJlYjM0MzdkNmY0YTU5Y2ZiYjIzYTNiYTVlZjMxMmMzZDJlNWJlNDZjODAzMWQxMGY5NTQ0ZDNlMzhiOGZhOThjYmRjODQ1MmRmZjZiMDlkMjViMTU3ZWQ0ZDM1N2ZiNmU1MjU5OTM0YjI0Mjk0Y2E5MmU2NzZjZjFmZDUxNjdkMDg2ZTQyMDc3MjFjNzU3NTRlZWJiNTBiNjVhN2I4NDEzYWEzYSIsInAiOiJmZjYwMDQ4M2RiNmFiZmM1YjQ1ZWFiNzg1OTRiMzUzM2Q1NTBkOWYxYmYyYTk5MmE3YThkYWE2ZGMzNGY4MDQ1YWQ0ZTZlMGM0MjlkMzM0ZWVlYWFlZmQ3ZTIzZDQ4MTBiZTAwZTRjYzE0OTJjYmEzMjViYTgxZmYyZDVhNWIzMDVhOGQxN2ViM2JmNGEwNmEzNDlkMzkyZTAwZDMyOTc0NGE1MTc5MzgwMzQ0ZTgyYTE4YzQ3OTMzNDM4Zjg5MWUyMmFlZWY4MTJkNjljOGY3NWUzMjZjYjcwZWEwMDBjM2Y3NzZkZmRiZDYwNDYzOGMyZWY3MTdmYzI2ZDAyZTE3IiwicSI6ImUyMWUwNGY5MTFkMWVkNzk5MTAwOGVjYWFiM2JmNzc1OTg0MzA5YzMiLCJnIj
> o
> >> iYzUyY
> >>>
>
> TRhMGZmM2I3ZTYxZmRmMTg2N2NlODQxMzgzNjlhNjE1NGY0YWZhOTI5NjZlM2M4MjdlMjVjZmE2Y2Y1MDhiOTBlNWRlNDE5ZTEzMzdlMDdhMmU5ZTJhM2NkNWRlYTcwNGQxNzVmOGViZjZhZjM5N2Q2OWUxMTBiOTZhZmIxN2M3YTAzMjU5MzI5ZTQ4MjliMGQwM2JiYzc4OTZiMTViNGFkZTUzZTEzMDg1OGNjMzRkOTYyNjlhYTg5MDQxZjQwOTEzNmM3MjQyYTM4ODk1YzlkNWJjY2FkNGYzODlhZjFkN2E0YmQxMzk4YmQwNzJkZmZhODk2MjMzMzk3YSJ9LCJwcmluY2lwYWwiOnsiZW1haWwiOiIyOTY1OTU4Yjc3MmI0YjhiOGZhYzU0NWM1YmY3MWU1ZkBhcGkuYWNjb3VudHMuZmlyZWZveC5jb20ifSwiaWF0IjoxNDAwNzEwOTY4MTYxLCJleHAiOjE0MDA3MzI1NzgxNjEsImlzcyI6ImFwaS5hY2NvdW50cy5maXJlZm94LmNvbSJ9.CfzEQEJSBhfPyn7gzMpYIdGljUq1Hi8WaOOrfKs41Y1Zx0m9Tn2WciqgjYl6QhFvH7dXsHHfghxNYPCewt7l3pfCLuDhVdV1030L5dFtrebAsSJepXF5xkWpT0QgXCdMdkwk_hZYxdJZHufbtoBJCPozrwzl5PrelgYsne-8F_kCRk5LkKFqBKVh28aUiSOANPSA8-NZoADe0zIJ2iv_zUgX2pNYTZGJ5WxYCzI2QWSFR0xanGbtejRx8qBdjk9qBJ2sR9h8n2d87ITwiF8E4smFV4htfopkGrQsGBUWy91Tqc4LUVNlk55VHyOCwwWaPpVE7pgAAENjHM_K0eoUKA~eyJhbGciOiJEUzEyOCJ9.eyJleHAiOjIxODkxMTEzNDA1OTMsImF1ZCI6Imh0dHA6Ly9hcGkuYWNjb3VudHMuZmlyZWZveC5jb2
> 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
