Basic access authentication: Difference between revisions

Revision as of 12:37, 5 March 2007

Latest revision as of 20:05, 24 August 2025

(749 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Access control method for the HTTP network communication protocol}}

In the context of an [[HTTP]] transaction, the '''basic authentication scheme''' is a method designed to allow a [[web browser]], or other client program, to provide credentials – in the form of a [[user name]] and [[password]] – when making a request. Although the scheme is easily implemented, it relies on the assumption that the connection between the client and server computers is secure and can be trusted. Specifically, the credentials are passed as [[plaintext]] and could be intercepted easily. The scheme also provides no protection for the information passed back from the server.

{{HTTP}}

In the context of an [[HTTP]] transaction, '''basic access authentication''' is a method for an [[User Agent Profiling|HTTP user agent]] (e.g. a [[web browser]]) to provide a [[user name]] and [[password]] when making a request. In basic HTTP authentication, a request contains a header field in the form of <code>Authorization: Basic &lt;credentials></code>, where <code>&lt;credentials></code> is the [[Base64]] encoding of ID and password joined by a single colon <code>:</code>.

It was originally implemented by [[Ari Luotonen]] at [[CERN]] in 1993<ref>{{cite mailing list |url=http://1997.webhistory.org/www.lists/www-talk.1993q3/0882.html |title=Announcing Access Authorization Documentation |date=10 September 2022 |access-date=7 February 2022 |mailing-list=[e-mail] |last=Luotonen |first=Ari}}</ref> and defined in the HTTP 1.0 specification in 1996.<ref>{{cite web |url=https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA |title=Hypertext Transfer Protocol -- HTTP/1.0 |date=19 February 1996 |website=www.w3.org |publisher=W3C |access-date=7 February 2022}}</ref>

To prevent the user name and password being read directly by a person, they are encoded as a sequence of [[Base64|base-64]] characters before transmission. For example, the user name <tt>"Aladdin"</tt> and password <tt>"open sesame"</tt> would be combined as <tt>"Aladdin:open sesame"</tt> &ndash; which is equivalent to <tt>QWxhZGRpbjpvcGVuIHNlc2FtZQ==</tt> when encoded in base-64. Little effort is required to translate the encoded string back into the user name and password, and many popular security tools will decode the strings "on the fly", so an [[encryption|encrypted]] connection should always be used to prevent interception.

It is specified in {{IETF RFC|7617}} from 2015, which obsoletes {{IETF RFC|2617}} from 1999.

== Features ==

One advantage of the basic authentication scheme is that it is supported by almost all popular web browsers. It is rarely used on normal [[Internet]] [[Website|web sites]] but may sometimes be used by small, private systems. A later mechanism, [[digest access authentication]], was developed in order to replace the basic authentication scheme and enable credentials to be passed in a relatively secure manner over an otherwise insecure channel.

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing [[access controls]] to web resources because it does not require [[HTTP cookie|cookies]], session identifiers, or login pages; rather, HTTP Basic authentication uses standard fields in the [[HTTP header]].

== Security ==

The basic authentication scheme was originally defined by RFC 1945 (''Hypertext Transfer Protocol &ndash; HTTP/1.0'') although further information regarding security issues may be found in RFC 2616 (''Hypertext Transfer Protocol &ndash; HTTP/1.1'') and RFC 2617 (''HTTP Authentication: Basic and Digest Access Authentication'').

The BA mechanism does not provide [[information security#Confidentiality|confidentiality]] protection for the transmitted credentials. They are merely encoded with [[Base64]] in transit and not [[encryption|encrypted]] or [[cryptographic hash|hashed]] in any way. Therefore, basic authentication is typically used in conjunction with [[HTTPS]] to provide confidentiality.

Because the BA field has to be sent in the header of each HTTP request, the web browser needs to [[Cache (computing)|cache]] credentials for a reasonable period of time to avoid constantly prompting the user for their username and password. Caching policy differs between browsers.

== Example ==

HTTP does not provide a method for a web server to instruct the client to "log out" the user. However, there are a number of methods to clear cached credentials in certain web browsers. One of them is redirecting the user to a URL on the same ___domain, using credentials that are intentionally incorrect. However, this behavior is inconsistent between various browsers and browser versions.<ref name=":0">{{cite web | url=https://stackoverflow.com/questions/31326/is-there-a-browser-equivalent-to-ies-clearauthenticationcache | title=Is there a browser equivalent to IE's ClearAuthenticationCache? | publisher=StackOverflow | access-date=March 15, 2013}}</ref>{{Better source needed|reason=The current source is user-generated and is insufficiently reliable ([[WP:NOTRS]]).|date=March 2025}} [[Internet Explorer|Microsoft Internet Explorer]] offers a dedicated JavaScript method to clear cached credentials:<ref>{{cite web | url=https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/hh801226(v=vs.85)#idmclearauthenticationcache | title=<code>IDM_CLEARAUTHENTICATIONCACHE</code> command identifier | publisher=Microsoft | access-date=March 15, 2013}}</ref>

Here is a typical transaction between an HTTP client and an HTTP server running on the local machine (localhost). It is comprised of the following steps.

<syntaxhighlight lang="html">

* The client asks for a page that requires authentication but does not provide a user name and password. Typically this is because the user simply entered the address or followed a [[hyperlink|link]] to the page.

<script>document.execCommand('');</script>

* The server responds with the 401 response code and provides the authentication realm.

</syntaxhighlight>

* At this point, the client will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a user name and password. The user may decide to cancel at this point.

* Once a user name and password have been supplied, the client re-sends the same request but includes the authentication header.

* In this example, the server accepts the authentication and the page is returned. If the user name is invalid or the password incorrect, the server might return the 401 response code and the client would prompt the user again.

In modern browsers, cached credentials for basic authentication are typically cleared when clearing browsing history. Most browsers allow users to specifically clear only credentials, though the option may be hard to find, and typically clears credentials for all visited sites.<ref>{{Cite web|title=540516 - Usability: Allow users to clear HTTP Basic authentication details ('Logout')|url=https://bugzilla.mozilla.org/show_bug.cgi?id=540516|access-date=2020-08-06|website=bugzilla.mozilla.org|language=en|quote=Clear Recent History->Active Logins (in the details) is used to clear the authentication.}}</ref><ref>{{Cite web|title=Clear browsing data - Computer - Google Chrome Help|url=https://support.google.com/chrome/answer/2392709?co=GENIE.Platform=Desktop&hl=en|access-date=2020-08-06|website=support.google.com|quote=Data that can be deleted[...]Passwords: Records of passwords you saved are deleted.}}</ref>

'''Note:''' A client may pre-emptively send the authentication header in its first request, with no user interaction required.

Brute forcing credentials is not actively prevented or detected (unless a server-side mechanism is used).

----

== Protocol ==

'''Client request (no authentication)''':

<pre>

GET /private/index.html HTTP/1.0

Host: localhost

</pre>

=== Server side ===

(followed by a [[Newline|new line]], in the form of a [[carriage return]] followed by a [[line feed]]).

When the server wants the user agent to authenticate itself towards the server after receiving an unauthenticated request, it must send a response with a ''HTTP 401 Unauthorized'' status line<ref>{{cite IETF|rfc= 1945 |section =11|title=Access Authentication||access-date=3 February 2017|page=46|date=May 1996 |publisher = [[Internet Engineering Task Force]]}}</ref> and a ''WWW-Authenticate'' header field.<ref>{{cite IETF|rfc=1945|section=10.16|title=Hypertext Transfer Protocol -- HTTP/1.0|last1=Fielding|first1=Roy T.|last2=Berners-Lee|first2=Tim|first3=Frystyk|last3=Henrik|author-link1=Roy Fielding|author-link2=Tim Berners-Lee|publisher = Internet Engineering Task Force}}</ref>

The ''WWW-Authenticate'' header field for basic authentication is constructed as following:

'''Server response''':

<pre>

HTTP/1.0 401 Unauthorised

Server: SokEvo/1.0

Date: Sat, 27 Nov 2004 10:18:15 GMT

WWW-Authenticate: Basic realm="SokEvo"

Content-Type: text/html

Content-Length: 311

<code>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

WWW-Authenticate: Basic realm="User Visible Realm"

"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

<HTML/code>

<HEAD>

<TITLE>Error</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">

</HEAD>

<BODY><H1>401 Unauthorised.</H1></BODY>

</HTML>

</pre>

The server may choose to include the ''charset'' parameter from {{IETF RFC|7617}}:<ref name=":0" />

'''Client request (user name "Aladdin", password "open sesame")''':

<pre>

GET /private/index.html HTTP/1.0

Host: localhost

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

</pre>

<code>

(followed by a blank line, as before).

WWW-Authenticate: Basic realm="User Visible Realm", charset="UTF-8"

</code>

This parameter indicates that the server expects the client to use UTF-8 for encoding username and password (see below).

'''Server response''':

<pre>

HTTP/1.0 200 OK

Server: SokEvo/1.0

Date: Sat, 27 Nov 2004 10:19:07 GMT

Content-Type: text/html

Content-Length: 10476

</pre>

=== Client side ===

(followed by a blank line and HTML text comprising of the restricted page).

When the user agent wants to send authentication credentials to the server, it may use the ''Authorization'' header field.

The ''Authorization'' header field is constructed as follows:<ref name="RFC7617">{{cite IETF|rfc=7617|section=2.1|title=The 'Basic' HTTP Authentication Scheme|first=Julian|last=Reschke|publisher = Internet Engineering Task Force}}</ref>

[[Category:HTTP]]

# The username and password are combined with a single colon ({{code|:}}). This means that the username itself cannot contain a colon.

[[fr:HTTP Authentification]]

# The resulting string is encoded into an octet sequence. The character set to use for this encoding is by default unspecified, as long as it is compatible with US-ASCII, but the server may suggest the use of UTF-8 by sending the ''charset'' parameter.<ref name="RFC7617" />

[[ja:Basic認証]]

# The resulting string is encoded using a variant of Base64 (+/ and with padding).

# The authorization method and a space character (e.g. "Basic ") is then prepended to the encoded string.

For example, if the browser uses ''Aladdin'' as the username and ''open sesame'' as the password, then the field's value is the Base64 encoding of ''Aladdin:open sesame'', or ''QWxhZGRpbjpvcGVuIHNlc2FtZQ==''. Then the ''Authorization'' header field will appear as:

==In practice==

<code>

The Basic authentication scheme is supported by most [[HTTP]] [[web servers]] but limitations can be involved. Authenticating users against your own database requires you to use customized modules.

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

</code>

<syntaxhighlight lang="python">

For instance, when using [[IIS]] web server, the basic authentication scheme will only use the Windows local or [[active directory]] user accounts to authenticate. If you wish to use your own user database accounts, you need to write or choose a custom authentication package. [http://www.visionalyse.co.uk/ Visionalyse] offers a ready-to-use solution called [http://www.visionalyse.co.uk/products/XHTTP-Authenticator/overview/ XHTTP Authenticator.NET] which handles both Basic and Digest HTTP Authentication without Active Directory. This product is designed for ASP.NET applications and runs as a [[HTTP Module]].

'Basic ' + base64.b64encode(f"{<clientid>}:{<client secret key>}".encode()).decode()

</syntaxhighlight>

== See also ==

XHTTP Authenticator.NET offers many features such as:

* [[Digest access authentication]]

* [[HTTP header]]

* [[TLS-SRP]], an alternative if one wants to avoid transmitting a password-equivalent to the server (even encrypted, like with TLS).

== References and notes ==

* Basic HTTP Authentication Mode

{{reflist}}

* Digest HTTP Authentication Mode

* Caching Capability

* Realm Name Configuration

* Support for Role-based Authentication

* Implement your own authentication logic

* Built-in authentication logic with user credentials stored in web.config

* Passwords Encryption

==SeeExternal alsolinks==

*{{cite IETF|title=The 'Basic' HTTP Authentication Scheme|rfc=7617|date=September 2015|publisher=[[Internet Engineering Task Force]]}}

*[[Digest access authentication]]

[[Category:HTTPHypertext Transfer Protocol]]

[[Category:Computer access control protocols]]