How does it work?¶
At a high level, this is what happens when a user wants to log into a site that uses django-browserid:
- A user clicks a login button on your web page.
- If necessary, the pop-up prompts the user for additional info to authenticate them. For example, if the user enters an @mozilla.com email, the Mozilla LDAP Identity Provider will prompt them for their LDAP password.
- The backend sends the assertion to the Remote verification service, which verifies the assertion and returns the result, including the email address of the user if verification was successful.
- The backend finds a user account matching that email (creating it if one isn’t found) and logs the user in as that account.
Note that this is just an example flow. Several of these steps can be customized for your site; for example, you may not want user accounts to be created automatically. This behavior can be changed to suit whatever needs you have.
A detailed explanation of the BrowserID protocol is available on MDN.
By default, django-browserid relies on Persona, which is a set of BrowserID-related services hosted by Mozilla. It’s possible, but annoying, to use django-browserid without these dependencies.
Currently, django-browserid relies on Persona for:
- The Cross-browser API Library, which implements the
navigator.idAPI for browsers that don’t natively support BrowserID.
- The Fallback Identity Provider for emails from servers that don’t support BrowserID.
- The Remote verification service, which handles assertion verification for sites that don’t want to verify assertions themselves.
In the future, django-browserid will remove the need to depend on these Mozilla-centric services. Local verification and a self-hosted cross-browser API will greatly reduce the reliance on Mozilla’s servers for authentication.