Adding OAuth support into Firefox?
Matthew 'lilmatt' Willis
both REST APIs and regular web services. I can forsee a time when
each toolbar and extension needs to rewrite the handshaking and
signing code required by OAuth, which would make me sad.
I'd like opinions on whether including OAuth support in Firefox would
be of interest, and how folks would like to be able to access it.
I know that both Flock and MozLabs have each created JS OAuth
implementations, so there is at least a starting place, but I would
want input on interface design, need for XPCOM, as well as where it
should live, etc.
-lilmatt
Chris
wrote:
Big +1.
I've seen a lot of interest lately around OAuth/OpenID in the browser
(yes they are separate). But making it easier and less costly for
folks to "do the right thing" in terms of managing access to user data
is a good thing for the open web and for Firefox.
And, I think that Weave is going to be using OAuth anyway?
Chris
Britt Selvitelle
and would love to see this.
me at work
> We at Twitter will be using OAuth as our primary form of token auth,
> and would love to see this.
>
Will that be before or after you re-enable IM usage, accept more
Jabber PubSub requests, achieve 99.9% uptime, remove deleted accounts
automatically from following/followed, and bring back Track?
Matthew 'lilmatt' Willis
> Will that be before or after you ...
Please don't hijack the thread.
Thanks
-lilmatt
Mike Beltzner
> I've seen a lot of interest lately around OAuth/OpenID in the browser
> (yes they are separate). But making it easier and less costly for
And for the purposes of this conversation, I'd suggest we leave them
as separate so that we don't conflate this discussion (which is well
scoped to OAuth).
> And, I think that Weave is going to be using OAuth anyway?
Yeah, I think that's what lilmatt meant when he said that Mozilla Labs
had worked up a version.
What's involved in baking it into the product?
cheers,
mike
Matthew 'lilmatt' Willis
> And, I think that Weave is going to be using OAuth anyway?
According to cbeard's and thunder's presentation at the Mozilla
Summit, Weave is already using OAuth. So we've already written this
in JS twice so far. :)
Flock's implementation is at:
http://lxr.flock.com/source/flock/mozilla/flock/modules/FlockOAuthLib.jsm
Matthew 'lilmatt' Willis
> What's involved in baking it into the product?
The implementation Flock wrote is a generalized .jsm, but it was
written for one service's authentication at this point, so it may not
be generalized enough. For example I believe there are other signing
algorithms in use at this point. I also seem to remember some crypto/
hash helpers recently landing that we're obviously not using.
I wanted to learn about other use cases such as extensions, and if
there was a need for XPCOM interfaces for it. I wonder also if there
is a need to expose it to the user at this point or not. If so
there's UI to design and debate.
-lilmatt
Daniel Mills
http://hg.mozilla.org/labs/weave/index.cgi/file/tip/modules/oauth.js
Which landed as part of this patch:
http://hg.mozilla.org/labs/weave/index.cgi/rev/d5e462bd195e
Some things to note:
* We have to do some crypto work after the user authorizes the data
sharing, so we intercept the redirect and do it there. That means the
user can only share on a Weave-enabled browser (Firefox 3 + Weave).
* We decided to just implement the auth locally in XUL (see oauth.xul).
* This is not production code.
Dan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Johnathan Nightingale
seen much about what "built in to the browser" would look like. I
understand the value we could offer by saving 1 million sites from
independently re-inventing the same crypto and protocol bugs, but
OAuth doesn't seem to envision this, so I'm wondering what you think
it would look like. A new API exposed to JS, sort of like a new XHR?
A mozilla-specific one, or something generic? Do both end-points have
to be aware of the API, or can it be invisible to one of them? Do we
know whether the OAuth gang are interested in this kind of integration?
I know you're mostly just throwing an idea out there to see if it
sticks, and I hope this doesn't sound like I'm stomping on it because
that's not at all my intent. It's just hard to assess whether it's a
good idea or not without a little more concrete sense of what the idea
*is*.
I wonder, as well, how amenable this kind of thing would be to
implementation in an add-on as a testing ground. I could see a way
forward that went:
- Talk with the OAuth folks about what the low-impact JS API would
be here
- Build out an add-on and get a couple of OAuth-using sites to use
it, when available (obviously this is an easier sell if it is at least
partially transparent)
- Iterate with an eye towards standardization and uplift
I don't think we'd need to gate our implementation on getting a
standard carved in stone, but it seems silly to not be thinking
standardization for something that is, at the end of the day, an
interop technology.
I'm sure you've already thought about all of this, but it's Monday, so
I need it spelled out a little more clearly. :)
Cheers,
Johnathan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Eddy Nigg
> I don't think we'd need to gate our implementation on getting a standard
> carved in stone, but it seems silly to not be thinking standardization
> for something that is, at the end of the day, an interop technology.
>
Johnathan, have also a look at this: http://code.google.com/p/idib/
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Matthew 'lilmatt' Willis
wrote:
> I'm pretty sure I understand OAuth's token exchange, but I haven't
> seen much about what "built in to the browser" would look like. I
> understand the value we could offer by saving 1 million sites from
> independently re-inventing the same crypto and protocol bugs, but
> OAuth doesn't seem to envision this, so I'm wondering what you think
> it would look like. A new API exposed to JS, sort of like a new XHR?
and C++ can access if necessary) with the basic mechanics of the token
exchange. If each extension (toolbar, Weave, etc.) needs to rewrite
those steps, it seems valuable to have it standardized.
> A mozilla-specific one, or something generic?
to create "a new XHR" great, but we're not there yet.
> Do both end-points have to be aware of the API, or can it be invisible to one of them?
Invisible to the remote endpoint.
> Do we know whether the OAuth gang are interested in this kind of integration?
They're interested in initiatives that help increase the penetration
of OAuth, so yes.
I could also envision a unified authz revocation panel where you can
prevent Myspace from talking to Flickr on your behalf, etc. That
would require more protocol work however, as there is no canonical
repository of all the authz you have or have not granted across the
entire internet. We could cache what we know about via your browsing
sessions, but that is not guaranteed to be unstale nor complete.
I'm more interested in the small gains for many folks approach first.
-lilmatt