HTTP+HTML Form based authentication

HTTP

Persistence · Compression · HTTP Secure

Headers

ETag · Cookie · Referrer · Location

Status codes

301 Moved permanently

302 Found

303 See Other

403 Forbidden

404 Not Found

HTML
File:HTML.svg
HTML and HTML5 Dynamic HTML XHTML XHTML Mobile Profile and C-HTML Character encodings Font family HTML editor HTML element HTML scripting Layout engine Quirks mode Style sheets Unicode and HTML W3C Web colors Comparison of document markup languages web browsers layout engines for HTML HTML5 Non-standard HTML XHTML

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.

Interaction Summary

The steps of the 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. The webpage 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 (i.e. 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 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