HTTP+HTML form-based authentication

HTTP+HTML form-based authentication, typically presently colloquially referred to as simply form-based authentication, is a technique whereby a website uses a web form to collect, and subsequently authenticate, credential information from a user agent, typically a web browser. (Note that the phrase "form-based authentication" is ambiguous. See form-based authentication for further explanation.)

A screenshot of the English Wikipedia login form

Interaction summary

The steps of the technique are:

• An unauthenticated user agent requests a web page from a website, via the HTTP protocol.
• The website returns an HTML web page to the unauthenticated user agent. The web page consists minimally of an HTML-based web form which prompts the user for their username and password, along with a button labeled "login" or "submit".
• The user fills in his username and password, and then presses the submit button.
• The user agent sends the web form data (which includes the username and password) to the web server.
• The website implementation, running on the web server, performs some verification and validation operations on the web-form data. If successful, the website considers the user agent to be authenticated.

Adoption considerations

HTTP+HTML form-based authentication is arguably the most prevalent user-authentication technique employed on the World Wide Web today. It is the approach of choice for essentially all wikis, forums, banking/financial websites, e-commerce websites, Web search engines, Web portals, and other common web-server applications.

This popularity is apparently due to webmasters or their employers wanting fine-grained control over the presentation and behavior of the solicitation for user credentials, while the default pop-up dialog boxes (for HTTP basic access authentication or digest access authentication) that many web browsers provide do not allow precise tailoring. The desired precision may be motivated by corporate requirements (like branding) or implementation issues (e.g., the default configuration of web applications like MediaWiki, phpBB, Drupal, WordPress). Regardless of rationale, any corporate branding or user-experience adjustments must not distract from several security considerations of this authentication process.

Security considerations

• The user credentials are conveyed in the clear to the web site, unless steps such as employment of HTTPS are taken.
• The technique is essentially ad hoc in that effectively none of the interactions between the user agent and the web server, other than HTTP and HTML themselves, are standardized. The actual authentication mechanism employed by the website is, by default, unknown to the user and the user agent. The form itself, including the number of editable fields, and desired content thereof, are entirely implementation- and deployment-dependent.
• This technique is inherently phishable, or vulnerable to criminals masquerading as a trusted party in the authentication process. This is because it relies upon the end user to accurately validate that they are accessing the correct URL each time to prevent sending their password to an untrusted server. Users often fail to do this, which is why Phishing has become the most common form of security breach.

Code

<form method="POST" action="/login">
  <label>username: <input type="text" name="username" autocomplete="username" required></label>
  <label>password: <input type="password" name="password" autocomplete="current-password" required></label>
  <button type="submit">Login</button>
</form>

See also

• Authentication
• Basic access authentication
• Digest access authentication
• Form-based authentication
• Login

External links

• security - The definitive guide to form-based website authentication - Stack Overflow