HTTP - Authentication

HTTP provides a general framework for access control and authentication.

On this page

Introduction

RFC 7235 defines the HTTP authentication framework, which can be used by a server to challenge a client request, and by a client to provide authentication information.

Challenge

In security protocols, a challenge is some data sent to the client by the server in order to generate a different response each time. Challenge-response protocols are one way to fight against replay attacks where an attacker listens to the previous messages and resends them at a later time to get the same credentials as the original message.

Replay attack

In web security, a replay attack happens when an attacker intercepts a previously-sent message and resends it later to get the same credentials as the original message, potentially with a different payload or instruction.

Replay attacks can be prevented by including a unique, single-use identifier with each message that the receiver can use to verify the authenticity of the transmission. This identifier can take the form of a session token or “number used only once”

Challenge-response flow

The challenge and response flow work like this:

  1. The server responds to a client with a 401 (Unauthorized) response status and provides information on how to authorize with a WWW-Authenticate response header containing at least one challenge.

  2. A client that wants to authenticate itself with the server can then do so by including an Authorization request header with the credentials.

  3. Usually a client will present a password prompt to the user and will then issue the request including the correct Authorization header.

ServerClientServerClientAsk user for credentialsCheck credentialsRespond with '200 OK' ifcredentials are valid.Otherwise, send a '401Unauthorized'.GET / HTTP/1.1HTTP/1.1 401 UnauthorizedWWW-Authenticate: Basic realm="staging server"GET / HTTP/1.1Authorization: Basic a6aec62f4c5c1d...HTTP/1.1 200 OKHTTP/1.1 401 Unauthorized

The general message flow above is the same for most (if not all) authentication schemes. The actual information in the headers and the way it is encoded does change!

Caution

The “Basic” authentication scheme used in the diagram above sends the credentials encoded but not encrypted. This would be completely insecure unless the exchange was over a secure connection (HTTPS/TLS).

Character Encoding

Browsers use utf-8 encoding for usernames and passwords.

Authentication schemes

The general HTTP authentication framework is the base for a number of authentication schemes.

IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.

Some common authentication schemes include:

  • Basic. See RFC 7617, base64-encoded credentials.
  • Digest. See RFC 7616. All modern browsers support the SHA-256 algorithm. Previous versions only support MD5 hashing (not recommended).
  • Bearer. See RFC 6750, bearer tokens to access OAuth 2.0-protected resources

Basic authentication scheme

The “Basic” HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS/TLS should be used with basic authentication to prevent credential interception.

In addition, sites that use HTTP Basic Auth are particularly vulnerable to Cross-Site Request Forgery (CSRF) attacks because the user credentials are sent in all requests regardless of origin (this differs from cookie-based credential mechanisms, because cookies are commonly blocked in cross-site requests).

Sites should always use the POST requests when changing data and include CSRF tokens.

Without these security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Pending