Mozilla's BrowserID (single sign-on for the web) is live

https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site

by waterside81 • 15 years ago

167 88 15 years ago

moonboots• 15 years ago

I'm not seeing how BrowserID differs from the standard email verification sign up. I went through the sign up process (enter email, click link in verification email, enter password, sign in with password). I also read Mozilla's 'really short version' explaining browserid (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol) and will give the longer version a shot.

RandallBrown• 15 years ago

I think you only have to do the email verification one time. After that, you'll be able to log in to any BrowserID site without entering anything.

tricolon• 15 years ago

Indeed; I believe it authenticates your browser (or perhaps only your browser session?) across all BrowserID-using sites, drastically cutting down on the number of times you'd have to type in a password.

skeptical2• 15 years ago

It doesn't aim to solve that issue. It aims to solve the issue of maintaining multiple passwords on multiple sites.

ozten2• 15 years ago

Right, this is caving cowpaths. Most sites have this flow, so if we can lift that up into the Browser and your Primary identity provider, than you can stop doing this on each new website you visit.

cpeterso• 15 years ago

What does BrowserID do that every existing OpenID provider cannot? The BrowserID FAQ says the architecture is "decentralized", but login relies on Mozilla's browserid.org server.

decentralized• 15 years ago

On the linked page it says:

"NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator."

So while it's easier to use their server, it appears it is entirely possible to implement without it. Perhaps in a few weeks, we will see some good implementations. As I understand, the main advantage over OpenID is that instead of needing a <username>@<someopenidprovider> login, people can simply use an email address as their login. If all email providers supported OpenID, there would be little difference, but that has not happened (yet).

resnamen• 15 years ago

It provides a canonical identifier for your account without compromising your identity to BrowserID-enabled services. The OpenID spec divulges who you are.

nodata• 15 years ago

How does it compare to Microsoft Passport?

How does it compare to client-side certificates?

icebraining6• 15 years ago

The OpenID spec divulges who you are.

How so? As far as I know, the only mandatory information is the OpenID identifier (the URL you need to input to authenticate). While more information can be exchanged, that's completely optional and up to the user. For example, MyOpenID always asks what "persona" - if any - you want to send when you authenticate.

BrowserID is no better: you need to input your email address.

thristian5• 15 years ago

Mozilla's browserid.org server is used for two things, currently:

- validating the signed authentication token you get back from calling the authentication function. As user "decentralized" points out, this is just a convenience; your service can do this itself if you don't mind getting your hands dirty with crypto code.

- Serving the JS shim for user-agents that don't implement navigator.id.getVerifiedEmail() natively. Once browsers implement this function themselves, and webmail systems can tell the browser that the user owns a particular email address, this won't be needed either.

jmathai5• 15 years ago

The goal is that others support the verification portion (hence it being decentralized). The browserid.org site is required today because others haven't implemented support on their backends.

Hope that changes sooner than later.

ozten2• 15 years ago

The design of BrowserID is more aligned with real user behavior in the wild. An example is users remember an email instead of a URL. The API/Protocol for an implementing website is much easier, based on implementer feedback.

tomjen3• 15 years ago

Anything that means I won't have to use yet another password is a good thing.

However I fail to see how this is useful: no sites use it, because no users use it.

Let's not muddy the waters. Use openid. No excuses.

wmf4• 15 years ago

It looks like Firefox is not going to support OpenID, so any site that wants to take advantage of browser support will have to adopt BrowserID.

unicornporn• 15 years ago

I had to create an account a couple of days ago because it was the only way to log in to openphoto.me. Are there any clear differences between BrowserID and OpenID?

thristian5• 15 years ago

OpenID requires the user to remember what sites they have accounts on that provide OpenID authentication, and requires them to remember their authentication information for those sites every time they want to log into an OpenID-using site.

In its current form, BrowserID requires the user to do the email-verification dance once for each email address they want to authenticate as, and from then on they can just pick it from a list instead of doing the dance yet again.

In its ideal form, once the BrowserID API is implemented directly in browsers and webmail systems (instead of the shim at browserid.org), the user doesn't need to remember anything: they click "sign in" on the web-page, the browser brings up its standard 'pick an email address to authenticate as' dialog (populated from all the webmail sites the user has logged into), the user selects one from the list, and off they go.

jmathai5• 15 years ago

The clearest difference in my mind is that BrowserID is much easier for a user to grasp. An email address is something users already associate with their identity.

As far as OpenPhoto, we're pushing BrowserID because we think it's a much better authentication system than something like Facebook Connect. It's open, distributed and secure. We do have FB Connect plugins for OpenPhoto but we believe that defaultly using BrowserID is the right thing to do.

http://blog.theopenphotoproject.org/post/13914931003/the-int...

huhtenberg• 15 years ago

Am I the only one who has a dozen of OpenIDs, none of which I remember?

skeptical2• 15 years ago

Yes you are. Because others use the same openid in every openid enabled site where you open yet another openid account.

zerostar072• 15 years ago

This is a more pragmatic approach than openid. Most users have a secondary email for logins anyway, and browserid makes switching a snap. I think it will catch on, mainly because there s nothing new for users to learn, and everyone has an email addr

Perceptes• 15 years ago

Most users have a secondary email for logins anyway

It seems to me the opposite is true. What is your source for this?

skrebbel• 15 years ago

Maybe I'm stupid, but the linked article gives me the idea that JavaScript is requirement to be enabled to allow log-in. Is this true?

I know, I know, it's 2011, but still I feel it's unnecessarily limiting.

jmathai5• 15 years ago

At the moment the BrowserID team provides a Javascript shim but the goal is that it will be supported natively in the browsers. The shim if a fallback (which applies for all browsers atm).

thristian5• 15 years ago

Even if the API is supported natively in the browser, it's still a JavaScript API, so you still need to allow the website to run JavaScript so that it can call that native method.

Ecio78• 15 years ago

I'm working on a webapp that will be used by not-so-tech-savvy working people and this could be an interesting way to subscribe to the service without implementing generic openid (i think most of them wont understand it) or facebook/twitter etc.. login (it's a service for businessman). I must check if it's more difficult to implement than an all-internal email subscription and verification process.

jmathai5• 15 years ago

BrowserID is super easy to implement. It's 8 lines of Javascript and about 8 lines of code on the backend to verify that a user owns an email address.

I've implemented it on OpenPhoto and absolutely love it.

StavrosK2• 15 years ago

Can you give me an invite code? I'd love to try BrowserID out and openphoto looks interesting! My email is in my profile, if you need it.

riffraff• 15 years ago

>>> Error encountered trying to complete registration. >>> Thank you for signing up with BrowserID.

Quite a bit too experimental for me to register I'm afraid

philikon3• 15 years ago

A lot of questions here revolve around how this is different from OpenID and single sign-on solutions like Google Accounts or Facebook Connect. Here's a rough list (may be incomplete or inaccurate by now; while I work for Mozilla, I'm not involved in this project):

* federated (like OpenID)

* open standard (like OpenID)

* no passwords / no typing / no memorizing (e.g. like FB Connect)

* possibility of browsers providing an integrated experience (technically possible with previous solutions, but no browser has done this so far -- in the case of OpenID for a very good reason IMHO)

* anonymity/choice of identities (like OpenID, definitely unlike e.g. FB Connect)

* no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)

Check out Dan and Ben giving a nice demo of the BrowserID user experience: http://www.youtube.com/watch?v=6x45Nt1fOMM. No passwords, no typing, and anonymity where desired.

If you're interested in the nitty gritty details, Lloyd explains the cryptographic assertions that actually let sites verify your identity: http://lloyd.io/how-browserid-works

(EDIT: format bullet points)

m_eiman• 15 years ago

no exposure to identity provider

That's not quite true, is it? The documentation says I need to verify the user's identity by calling e.g. browserid.org/verify…

thristian5• 15 years ago

The documentation also says "NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator."

sandeepshetty• 15 years ago

- https://github.com/mozilla/browserid/wiki/How-to-Use-Browser...

gwillen• 15 years ago

Can you explain briefly what the good reason is for no browser to integrate OpenID?

badida• 15 years ago

In earlier identity experiments at Mozilla, we tried. It never felt good as a user experience, in large part because OpenID was designed to not include the browser.

MatthewPhillips4• 15 years ago

> no passwords / no typing / no memorizing (e.g. like FB Connect)

FB Connect requires you to memorize your Facebook password. It also requires you to have a Facebook account. BrowserID requires neither an "account" or a password.

zobzu3• 15 years ago

this post should be on browserid.org i find it difficult to find what it does, how its different, etc.. well until your post that is

philikon3• 15 years ago

Yes, I already spoke to the team and they're going to put up a FAQ. Thanks!

dholbert• 15 years ago

> * no passwords / no typing / no memorizing (e.g. like FB Connect)

Technically there's 1 password (your BrowserID login password), not "no passwords". :)

(Though of course you can have multiple identities (email addresses) all associated with the same BrowserID account, so as you increase the number of identities, I suppose your passwords-per-identity approaches zero... ;) )

ranit8• 15 years ago

> no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)

Unfortunately that might be what prevents this or http://webid.info/ from getting traction. The big guys wouldn't like losing that data, and OpenID/OAuth already do the job well enough for them.

A comparison WebID/BrowserID can be found here: http://security.stackexchange.com/questions/5406/what-are-th...

MattBearman• 15 years ago

I like the idea of this, seems like a much better solution than Open ID, and I've never been a fan of sign in with Facebook/Twitter/Google/etc.

However I'm a little disappointed that they tell you to add it as a blocking (synchronous) JavaScript include in the head of your document.

lloydhilaiel2• 15 years ago

the include file is about 4.7k minified and compressed. You don't need to include it in head, that's lame. we'll update the docs.

lloyd

ww520• 15 years ago

This looks interesting, simple UX for user and simple to implement for developers. I'll give it a try in my next project.

vlasta2• 15 years ago

Maybe I do not understand the system well enough, but isn't there too much room for fake accounts? The web site implementing BrowserID must trust the browser or the 3rd party validation service that the user really owns the specified email, right? Wouldn't it be super-easy for a hacker to simply return bogus values from navigator.id.getVerifiedEmail() when that gets implemented in browsers? (more specifically, what is the verification procedure of the "Primary Identity Authorities" and what stops a hacker to create a fake one?)

I am all for simple log-in procedures, but as a web site owner, I want to be really sure, the email at least exists to prevent a bit of spam or low-quality content.

thristian5• 15 years ago

As I understand it, the authentication token you get back from BrowserID is signed by the entity that verified that the email address is real; at the moment, only browserid.org is signing tokens, but presumably there'll be some scheme where you say "I have a token for foo@example.com, so I'll request the public key of example.com and validate the signature on this token".

I guess it's possible for somebody to set up a website that will sign absolutely any token anybody offers them, but (a) as a website operator, you can tell that the token "foo@example.com signed by example.com" is different from "foo@example.com signed by evil.com" and (b) you could always have a blacklist/whitelist of entities you trust to verify BrowserIDs.

Newky• 15 years ago

It would be interesting for this to get some exposure from a large web-service. Being realistic, Facebook nor Google would be interested in replacing their own system. But I think it is an interesting idea which now is no longer just theory.

stephank2• 15 years ago

Well, Google wouldn't replace their login process because they are the BrowserID primary. If you have a gmail account, BrowserID expects you to be logged in with it, which essentially means you're logged in to Google. (They could add it for non-gmail Google accounts, I guess.)

But Facebook could benefit from this. Maybe not at this early stage, but the way you log into Facebook is using your email account. That's exactly the step BrowserID wants to make easier.

kogir• 15 years ago

I'm pretty sure I understand how this works, but please correct me if I'm wrong.

As currently implemented, it appears that if the Primary Identity Authority or Secondary Identity Authority keys are compromised, then all accounts for which that authority is trusted are also compromised. This enables accounts to be compromised en masse, rather than individually. It would seem that by de-centralizing authentication, browserid centralizes security.

Ok, so revoke the compromised certificate. If you "trust" browserid.org and do assertion verification on your own servers, how are you notified of the compromise and key change? Conversely, if you offload assertion checking to browserid.org and they go down, will users really understand why they can't log in and your site is "broken"? You could use CRLs and OSCP, but now you have another thing to get wrong in individual sites' assertion verification implementations.

Another interesting side effect of PIA or SIA key compromise is that an attacker could now create accounts and impersonate users, not just access existing ones.

It would also appear that due to the omission of a nonce, assertions are vulnerable to replay within the validity window.

I think that authentication is broken, and commend attempts to fix it. I'm just not sure that all the added complexity of browserid really buys us anything, and instead enables new attacks that previously weren't feasible.

stephank2• 15 years ago

I think the intention is for the primary to be your email provider. So if they become compromised to that extent, then I wouldn't feel very safe about my email account in the first place. Pretty much all of my credentials everywhere depend on that.

Until secondaries go away, Mozilla seems like a very competent and trustworthy organization to have in charge of browserid.org, IMHO. Much better than even Google. It's great to see that even the branding on browserid.org is minimal.

My guess is that, concerning nonces and revocation, they didn't consider the current situation (OpenID, OAuth for login, etc.) any better. BrowserID doesn't seem to do away with the strong advice to run HTTPS for such sites.

dhx• 15 years ago

Why?

Firefox already stores passwords in a local database and it wouldn't be that hard to automatically log users into sites.

The method they describe here requires every web site be changed and requires cross-domain JavaScript to be enabled such that browserid.org will know which websites you visit. You _could_ place include.js on your local domain to avoid this issue. However history has shown that sites will tend to just cross-domain link to googleapis or yahooapis.

Additionally, this is yet another web authentication method that should probably be handled at a lower level in the stack -- either the HTTP protocol, transport layer (TLS) or perhaps in the future, by using IPSec.

mattmanser• 15 years ago

local database

That's why.

icebraining6• 15 years ago

Uh, from the "How BrowserID works" page:

    The user stores the keypair and certificate locally.

gcp• 15 years ago

Because you don't need to create an account on each and every site you visited (together with decoding a similar number of CAPTCHA's, etc)

icebraining6• 15 years ago

And more importantly than decoding Captchas - with B-ID there's no need to verify the damn email each time you register.

alexchamberlain3• 15 years ago

Why has this been developed? I would have like to have seen a way for clients to generated client-based SSL certificates and submitting them to a server for signing automatically. This would be little new technology and proven cryptographically.

gizzlon2• 15 years ago

Probably because client-based SSL certificates have been around forever, but no-one uses them.

Probably not a coincidence either, my bank used to rely on client side certificates but gave up after, I guess, an insane amount of support calls.

alexchamberlain3• 15 years ago

They are brilliant, but they need to be more accessible. Hmmmmm... maybe I should provide a patch for Chromium/Firefox.

deno• 15 years ago

Does BrowserID addresses in any way authorization? Is it compatible with OAuth2?

extension2• 15 years ago

Hmm.. so if my browser has integrated support, then any site I visit can add itself to my list of primarity authorities as evil-username@evil-domain. And I will be asked to choose one of these authorities to log in to other sites. And a rogue authority can impersonate me on the sites where I use it. Is this correct?

I can see a slight potential to trick the user into using a rogue authority. Imagine the evil email address is somehow tailored to a site the user is expected to log in to, in a way that makes it look like the "right" selection for that site, in the BrowserID dialog. I can't think of an explicit example right now, but when you allow untrusted parties to inject text into trusted dialogs, there are often many possibilities for trickery.

icebraining6• 15 years ago

I'm not sure if "any site I visit can add itself to my list of primarity authorities as evil-username@evil-domain", but I do know that the login to the authority is done using Public Key authentication, which unlike passwords isn't subject to phishing. There's no risk in logging in to a rogue authority, since the key never actually leaves your machine.

extension2• 15 years ago

I don't mean logging into an evil authority, I mean tricking the user into using an evil authority to log in to a relying party. There evidently is or will be a way for web sites to tell your browser that they can serve as a primary authority for some particular email address at their domain. When you visit the evil site, it would register some misleading email address, which your browser would then show in the list of identities whenever you log in to a relying party.

At best, we will still need some way of filtering out junk from the identity list.

MatthewPhillips4• 15 years ago

>Include the BrowserID include.js library in your site by adding the following script tag to your pages <head> tag <script src="https://browserid.org/include.js type="text/javascript"></script>

Not minified. Come on Mozilla, you did the same thing with the (rather large) Open Web Apps library. Minification is required. You are Mozilla, you should know this. YUI Compressor takes a few seconds at most.

MatthewPhillips4• 15 years ago

Looks like I was either wrong or they've fixed it. Apologies.

lloydhilaiel2• 15 years ago

Hi MatthewPhillips,

That's just the license header that's not stripped. I agree, that's a bit draconian. lemme see if I can fix that for you.

lloyd

MatthewPhillips4• 15 years ago

Actually I went to the Documentation and clicked the link there, which actually takes you to the github source. Completely my bad, having a license header is not abnormal. I jumped the gun because the Open Web Apps shim wasn't minified for quite a while.

romaniv• 15 years ago

I was hopeful about this protocol, but now I'm kind of disappointed. It uses email and is built into the browser, so why does it require JavaScript on the user side and a complicated verification server on the server side? I was a hoping for something simpler.

lisper• 15 years ago

For an even simpler alternative to BrowserID see: http://dswi.net/

jaredhanson2• 15 years ago

For anyone interested in using BrowserID authentication from a Node.js app, Passport (which I developed) has a BrowserID module: https://github.com/jaredhanson/passport-browserid

Just drop in a few lines of code and you have single sign-on.

vthunder• 15 years ago

Very cool! I didn't know you'd added that.

Let us (the BrowserID team) know if you have any feedback on the experience.

jaredhanson2• 15 years ago

I'd say the experience is quite easy, especially when using browserid.org/verify for verification.

My biggest criticism is the lack of a concretely defined spec for how the Verified Email Protocol works, if one wanted to implement it directly, rather than relying on browserid.org.

Based on the code in the repository, the protocol seems relatively straightforward. But, as it currently stands, it'd be difficult to implement it based on the paper spec alone.

Anyway, nice work on BrowserID. I'm excited to see where its headed.

Mozilla's BrowserID (single sign-on for the web) is live

Related Stories