In this mode, the Buildbot UI displays a form allowing the user to specify a username and password.
When this form is submitted, the UI makes an AJAX call to /auth/login including HTTP Basic Authentication headers.
The master verifies the contents of the header and updates the server-side session to indicate a successful login or to contain a failure message.
Once the AJAX call is complete, the UI reloads the page, re-fetching /config.js, which will include the username or failure message from the session.

Subsequent access is authorized based on the information in the session; the authentication credentials are not sent again.

Buildbot's web service can be run behind an HTTP proxy.
Many such proxies can be configured to perform authentication on HTTP connections before forwarding the request to Buildbot.
In these cases, the results of the authentication are passed to Buildbot in an HTTP header.

In this mode, authentication proceeds as follows:

The web browser connects to the proxy, requesting the Buildbot home page

The proxy negotiates authentication with the browser, as configured

Once the user is authenticated, the proxy forwards the request goes to the Buildbot web service.
The request includes a header, typically Remote-User, containing the authenticated username.

Buildbot reads the header and optionally connects to another service to fetch additional user information about the user.

Buildbot stores all of the collected information in the server-side session.

The UI fetches /config.js, which includes the user information from the server-side session.

Note that in this mode, the HTTP proxy will send the header with every request, although it is only interpreted during the fetch of /config.js.

Kerberos is an authentication system which allows passwordless authentication on corporate networks.
Users authenticate once on their desktop environment, and the OS, browser, webserver, and corporate directory cooperate in a secure manner to share the authentication to a webserver.
This mechanism only takes care about the authentication problem, and no user information is shared other than the username.
The kerberos authentication is supported by a Apache front-end in mod_kerberos.

Third-party authentication involves Buildbot redirecting a user's browser to another site to establish the user's identity.
Once that is complete, that site redirects the user back to Buildbot, including a cryptographically signed assertion about the user's identity.

The most common implementation of this sort of authentication is oAuth2.
Many big internet service companies are providing oAuth2 services to identify their users.
Most oAuth2 services provide authentication and user information in the same api.

The following process is used for third-party authentication:

The web browser connects to buildbot ui

A session cookie is created, but user is not yet authenticated.
The UI adds a widget entitled LoginviaGitHub (or whatever third party is configured)

When the user clicks on the widget, the UI fetches /auth/login, which returns a bare URL on github.com.
The UI loads that URL in the browser, with an effect similar to a redirect.

GitHub authenticates the user, if necessary, and requests permission for Buildbot to access the user's information.

On success, the GitHub web page redirects back to Buildbot's /auth/login?code=.., with an authentication code.

Buildbot uses this code to request more information from GitHub, and stores the results in the server-side session.
Finally, Buildbot returns a redirect response, sending the user's browser to the root of the Buildbot UI.
The UI code will fetch /config.js, which contains the login data from the session.

Browserid/Persona: This method is very similar to oauth2, and should be implemented in a similar way (i.e. two stage redirect + token-verify)

Use the User table in db: This is a very similar to the UserPasswordAuth use cases (form + local db verification). Eventually, this method will require some work on the UI in order to populate the db, add a "register" button, verification email, etc. This has to be done in a ui plugin.