HTTP+HTML Form based authentication

HTTP+HTML Form based authentication, typically presently colloquially referred to as simply Form based authentication (which in actuality is ambiguous, see form based authentication for further explanation), 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 wielded by a user.

Interaction Summary

The salient steps in this technique are:

• An unauthenticated user agent requests a webpage from a website, via the HTTP protocol.

• The website returns an HTML web page to the unauthenticated user agent. Said webpage is minimally crafted using a HTML-based web form to prompt the user for username and password, and to present a button typically labeled "login" or "submit".

• The user causes the webform to be filled in with username and password, and then causes the submit button to be invoked.

• The user agent conveys the web form data, i.e. username and password, to the web server.

• The website implementation, running on the web server, then typically performs some verification and validation operations on the conveyed web form data, resulting in the user (or, more properly, the user agent), being authenticated, from the website's perspective, if said operations were successful.

Adoption Considerations

HTTP+HTML Form-based Authentication is arguably the most prevalent user authentication technique employed on the Web today. It is the approach of choice for essentially all wikis, forums, banking/financial websites, ecommerce websites, Web search engines, Web portals, etc.

The overarching reason for this is apparently that the websites, whether by dint of simple implementation (e.g. the default configuration of website software, e.g. mediawiki, phpbb, drupal, wordpress, and commercial alternatives, etc.), or by corporate desires, e.g. branding, wish to have fine-grained control over the presentation and behavior of the solicitation for user credentials -- and the default popup dialog boxes provided by web browsers when HTTP Basic access authentication or Digest access authentication are employed (presently) don't allow for such tailoring on the part of the website provider.

Note that this -- the credence given to "user experience", not to mention branding, what the less charitable would term "simply eye candy" -- is done in the face of the security considerations enumerated below.

Security Considerations

• The user credentials are conveyed in the clear to the website, unless steps such as employment of Transport Layer Security (TLS) are taken.

• The technique is essentially ad-hoc in that effectively none of the interactions between the user agent and the webserver, 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. This is a major, pragmatic, consideration given the present-day prevalence of phishing.

See also

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