Jump to content

Basic access authentication: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Yksnyn (talk | contribs)
No edit summary
Tags: Reverted Mobile edit Mobile web edit
Added template
 
(13 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Short description|Access control method for the HTTP network communication protocol}}
{{Short description|Access control method for the HTTP network communication protocol}}
{{HTTP}}
In the context of an [[HTTP]{{WikiProject banner shell|class=C|
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>.
{{WikiProject Computing|importance=}}
}}] 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 <credentials></code>, where <code><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=www-talk@w3.org |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>
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=www-talk@w3.org |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>
Line 28: Line 27:


=== Server side ===
=== Server side ===
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 web|title=RFC 1945 Section 11. Access Authentication|url=https://tools.ietf.org/html/rfc1945#section-11|publisher=IETF|access-date=3 February 2017|page=46|date=May 1996}}</ref> and a ''WWW-Authenticate'' header field.<ref>{{cite web|url=http://tools.ietf.org/html/rfc1945#section-10.16|title=Hypertext Transfer Protocol -- HTTP/1.0|last1=Fielding|first1=Roy T.|last2=Berners-Lee|first2=Tim|first3=Frystyk|last3=Henrik|website=tools.ietf.org|author-link1=Roy Fielding|author-link2=Tim Berners-Lee}}</ref>
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:
The ''WWW-Authenticate'' header field for basic authentication is constructed as following:
Line 47: Line 46:
When the user agent wants to send authentication credentials to the server, it may use the ''Authorization'' header field.
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 web|url=https://tools.ietf.org/html/rfc7617#section-2.1|title=The 'Basic' HTTP Authentication Scheme|first=Julian|last=Reschke|website=tools.ietf.org}}</ref>
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>


# The username and password are combined with a single colon (:). This means that the username itself cannot contain a colon.
# The username and password are combined with a single colon ({{code|:}}). This means that the username itself cannot contain a colon.
# 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" />
# 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" />
# The resulting string is encoded using a variant of Base64 (+/ and with padding).
# The resulting string is encoded using a variant of Base64 (+/ and with padding).
Line 69: Line 68:


==External links==
==External links==
*{{cite web|title=RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication|url=https://tools.ietf.org/html/rfc7235|publisher=Internet Engineering Task Force (IETF)|date=June 2014}}
*{{cite IETF|title=The 'Basic' HTTP Authentication Scheme|rfc=7617|date=September 2015|publisher=[[Internet Engineering Task Force]]}}


[[Category:Hypertext Transfer Protocol]].
[[Category:Hypertext Transfer Protocol]]
[[Category:Computer access control protocols]]
[[Category:Computer access control protocols]]

Latest revision as of 13:23, 1 December 2024

In the context of an HTTP transaction, basic access authentication is a method for an 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 Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.

It was originally implemented by Ari Luotonen at CERN in 1993[1] and defined in the HTTP 1.0 specification in 1996.[2] It is specified in RFC 7617 from 2015, which obsoletes RFC 2617 from 1999.

Features

[edit]

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

Security

[edit]

The BA mechanism does not provide confidentiality protection for the transmitted credentials. They are merely encoded with Base64 in transit and not encrypted or 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 credentials for a reasonable period of time to avoid constantly prompting the user for their username and password. Caching policy differs between browsers.

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.[3] Microsoft Internet Explorer offers a dedicated JavaScript method to clear cached credentials:[4]

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

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.[5][6]

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

Protocol

[edit]

Server side

[edit]

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[7] and a WWW-Authenticate header field.[8]

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

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

The server may choose to include the charset parameter from RFC 7617:[3]

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

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

Client side

[edit]

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:[9]

  1. The username and password are combined with a single colon (:). This means that the username itself cannot contain a colon.
  2. 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.[9]
  3. The resulting string is encoded using a variant of Base64 (+/ and with padding).
  4. 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:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

See also

[edit]

References and notes

[edit]
  1. ^ Luotonen, Ari (10 September 2022). "Announcing Access Authorization Documentation". www-talk@w3.org (Mailing list). Retrieved 7 February 2022.
  2. ^ "Hypertext Transfer Protocol -- HTTP/1.0". www.w3.org. W3C. 19 February 1996. Retrieved 7 February 2022.
  3. ^ a b "Is there a browser equivalent to IE's ClearAuthenticationCache?". StackOverflow. Retrieved March 15, 2013.
  4. ^ "IDM_CLEARAUTHENTICATIONCACHE command identifier". Microsoft. Retrieved March 15, 2013.
  5. ^ "540516 - Usability: Allow users to clear HTTP Basic authentication details ('Logout')". bugzilla.mozilla.org. Retrieved 2020-08-06. Clear Recent History->Active Logins (in the details) is used to clear the authentication.
  6. ^ "Clear browsing data - Computer - Google Chrome Help". support.google.com. Retrieved 2020-08-06. Data that can be deleted[...]Passwords: Records of passwords you saved are deleted.
  7. ^ Access Authentication. Internet Engineering Task Force. May 1996. p. 46. sec. 11. doi:10.17487/RFC1945. RFC 1945. Retrieved 3 February 2017.
  8. ^ Fielding, Roy T.; Berners-Lee, Tim; Henrik, Frystyk. Hypertext Transfer Protocol -- HTTP/1.0. Internet Engineering Task Force. sec. 10.16. doi:10.17487/RFC1945. RFC 1945.
  9. ^ a b Reschke, Julian. The 'Basic' HTTP Authentication Scheme. Internet Engineering Task Force. sec. 2.1. doi:10.17487/RFC7617. RFC 7617.
[edit]