What is HTTP Authentication?

Authentication is a protocol used in HTTP communication to verify a client’s identity before granting access to a specific resource on the web. It’s a security measure within the HTTP protocol designed to protect users and businesses in the online environment. When authentication is performed at the edge, it significantly enhances both the speed and security of the process, ultimately increasing a company’s credibility and revenue.

HTTP Authentication

Authentication is an access control process that verifies a client’s identity before granting access to a specific resource on the web. As a result, authentication serves as an additional security layer in HTTP communications.

A client’s initial request is typically anonymous, meaning it lacks any identifying information to confirm the client’s identity. This can be risky, especially for sensitive resources such as banking details, as unrestricted access could be granted to any user. This is where authentication comes in: to regulate access, the server denies anonymous requests and indicates that client authentication is required. The authentication information exchanged between the server and client is transmitted via headers.

Image with HTTP authentication flow

The basic principles of authentication are outlined above, but since different types of resources require different levels of security, the complexity of authentication also varies. We will explore this further in the section on authentication schemes.

How Does HTTP Authentication Work?

RFC7235 describes how the HTTP protocol provides a general framework for access control and authentication. It supports a diverse set of challenge-response authentication schemes that allow a server to challenge a client request and enable the client to provide authentication credentials.

What Is Challenge-Response Authentication?

In challenge-response authentication, the server issues a request—known as a challenge—and the client must provide a valid response to be authenticated. A common example of challenge-response authentication is password authentication, where the challenge from the server is a password request, and the valid response from the client is the correct password.

Authentication Headers

Headers are used either by the server to define the authentication method (response headers) or by the client to provide authentication credentials (request headers). Let’s explore how they work:

Response Headers

There are two headers that the server can send: WWW-Authenticate and Proxy-Authenticate.

Both define the authentication method that must be used for the client to gain access to a resource. They must specify which authentication scheme to use so that the client desiring authorization knows how to provide the credentials.

WWW-Authenticate

The WWW-Authenticate header indicates the authentication scheme and parameters applicable to the target resource.

Syntax: WWW-Authenticate: type realm=<realm>

Where:

type: is the type of authentication requested.
realm: is the scope of protection, the area to be protected.

Example of WWW-Authenticate header:

WWW-Authenticate: Basic realm="Access to the internal site"

Proxy-Authenticate

The Proxy-Authenticate header defines the authentication method that should be used to gain access to a resource that is behind a proxy server. This header consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy server.

Syntax: Proxy-Authenticate: <type> realm=<realm>

Example of WWW-Authenticate header:

Proxy-Authenticate: Basic realm="Access to the internal site"

Request Headers

The client can send two headers: Authorization and Proxy-Authorization.

Both contain the credentials to authenticate the client with an origin server or a proxy server. Credentials can be encoded or encrypted, depending on the authentication scheme used.

Authorization

The Authorization header allows the client to authenticate with an origin server usually after receiving a 401 Unauthorized response from the server. This header contains credentials with information for client authentication for the area of the resource being requested.

Syntax: Authorization: <type> <credentials>

Where:

credentials: is the information for the authentication. It consists of the username, followed by a colon (:) and the user’s password. This sequence is then encoded with the base64 encoding method.

Note: Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format, converting it to a radix-64 representation.

Example:

If the browser uses Azion as username and edgecomputing as password, the field value is the base64 encoding of Azion:edgecomputing, that is QXppb246ZWRnZWNvbXB1dGluZw== . So the Authorization header will be:

Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Proxy-Authorization

The Proxy-Authorization header allows the client to authenticate to a proxy usually after the server responds with a status of 407 Proxy Authentication Required. This header contains credentials with information for client authentication to the proxy and/or the area of the resource that is being requested.

Syntax: Proxy-Authorization: <type> <credentials>

Example of Proxy-Authorization header:

Proxy-Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Authentication Schemes

Basic

As shown earlier, the server asks for a username and password in a request to authenticate a user in a basic authentication scheme. This information is encoded using base64 encoding.

A disadvantage of basic authentication is that it’s not secure, so it must use HTTPS/TLS security protocols for this communication. When the information is confidential or valuable, it’s necessary to use a more secure authentication scheme.

Bearer

Bearer authentication uses security tokens called bearer tokens. In this scheme, access is given to the token holder.

The token is an encrypted string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when requesting access to protected resources.

Syntax: Authorization: Bearer <token>

Digest

Digest authentication is also based on the challenge-response mechanism. The challenge the server sends to the client is a nonce value, a random number that can only be used once. The response from the client must contain a hash with the username, password, nonce value, HTTP method, and requested URL. This data hash format is more complex and makes it difficult to have user information stolen and reused, and it was developed as an alternative to replacing basic authentication, which is not a secure scheme.

The client must send the hash in the Authorization header when requesting access to protected resources.

Syntax: Authorization: Digest username=<"username">

Digest authentication example:

The client wants to have access to a secured document via a GET request. The URI of the document is https://www.azion.com/blog/index.html. Client and server know the username for this document is Azion and the password is edgecomputing.

The first time the client requests the document, the server does not send the authorization header and responds with:

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest

realm="registered_users@azion.com"

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

opaque="5ccc069c403ebaf9f0171e9517f40e41"
The client will respond with a new request, including the following headers:

Authorization: Digest username="Azion"

realm="registered_users@example.com"

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"

uri="/blog/index.html"

qop=auth

nc=00000001

cnonce="0a4f113b"

response="6629fae49393a05397450978507c4ef1"

opaque="5ccc069c403ebaf9f0171e9517f40e41"

HTTP Origin-Bound Auth (HOBA)

HTTP Origin-Bound (HOBA) authentication is a scheme that is not password-based, but signature-based. In addition, it offers additional features such as credential management and logout system. This makes this scheme more secure as it eliminates the risk of password leakage as there’s no server-side password verification database.

Clients can authenticate to servers using the HTTP protocol or a JavaScript authentication program using public-private keys.

Syntax: Authorization: HOBA result="kid"."challenge"."nonce"."sig"

Where result is the combination of kid, challenge, nonce and sig values. Result value is a dot-separated string that includes the signature and is sent in the HTTP authorization header value using the syntax shown above. The sig value is the base64url encoded version of the binary output of the signing process. The kid, challenge and nonce values are also encoded in base64url.

HOBA Authentication Flow:

To begin with, the client determines whether it already has a public key to authenticate or must generate one.
The client then makes a connection to the server, anticipating the server to request a HOBA-based authentication, which must be done by subscribing to an information blob.
The server sends a challenge that can be confirmed in an HTTP header and the client must respond with a signature, having previously given the server the public key. The server determines the CPK (Client Public Key) using the KID (Key Identifier) to decide whether to recognize the CPK. If the CPK is recognized, the authentication process is complete.

Mutual

Mutual authentication does both client and server authentication. Since authentication occurs in both directions, this scheme is also known as bidirectional authentication. One of the characteristics of mutual authentication is that client and server must provide digital certificates through the TLS (Transport Layer Security) protocol.

Syntax:

The client sends a request to the server with:

Authorization: Mutual user="name"

kc1="..."

The server responds with:

Authorization: Mutual sid=123

vkc="..."

Where user is the user identification string, kc1 is the client-to-server verification key, sid is the section identification key, and vkc is the server-to-client verification key.

Mutual authentication flow:

The client requests a resource without any authentication attempt.
If the requested resource is protected by the Mutual authentication protocol, the server will respond with a message requesting authentication (401-INIT).
The client processes the message body and waits for the user to enter the username and password. If username and password are available, the client will send a message with authenticated key exchange (req-KEX-C1) to initiate authentication.
The server looks for user authentication information within its user database. It then creates a new session identifier (sid) that will be used to identify sets of messages that follow it, and responds with a message containing a server-authenticated key exchange value (401-KEX-S1).
Client and server calculate a shared “session secret” using the values exchanged in key exchange messages. Only when they use secret credentials generated from the same password is that the session secret values will match. This session secret will be used for access authentication of each individual request/response pair from that moment.
The client will send a request with an authentication check value (req-VFY-C) calculated from the session secret generated by the client. The server will check the validity of the check value using its own version of the session secret.
If the client’s authentication check value is correct, the client has the credential based on the expected password, that is, authentication was successful. The server will respond with a success message (200-VFY-S).

If the client’s check value is incorrect (for example, because the password provided by the user was incorrect), the server will respond with a 401-INIT message (the same message as the message used in 2).

Negotiate

Negotiate authentication is a Microsoft Windows authentication mechanism that uses Kerberos as its underlying authentication provider. Kerberos works on a ticket-granting system to authenticate users to resources and requires the use of SPNEGO GSSAPI tokens.

Syntax: Authorization: Negotiate <gssapi-data>

Negotiate authentication flow:

The client requests access to a protected document without any authentication attempt.
The server responds with:

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Negotiate
The client will obtain the user’s credentials using the SPNEGO GSSAPI mechanism to identify and generate a GSSAPI message that will be sent to the server in a new request with the authorization header:

HTTP/1.1 GET dir/index.html

Authorization: Negotiate a87421000492aa874209af8bc028
The server will decode the GSSAPI data and pass it to the SPNEGO GSSAPI engine in the gss_accept_security_context function. If the context is not complete, the server will respond with a 401 status and a WWW-Authenticate header containing the GSSAPI data:

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Negotiate 749efa7b23409c20b92356
The client will decode the GSSAPI data, pass it to gss_Init_security_context and return the new GSSAPI data to the server:

HTTP/1.1 GET dir/index.html

Authorization: Negotiate 89a8742aa8729a8b028
This cycle can continue until the security context is complete. When the return value from the gss_accept_security_context function indicates that the security context is complete, it can provide authentication data to be returned to the client. If the server has more GSSAPI data to send to the client to complete the context, it will be sent in a WWW-Authenticate header with the final response containing the HTTP body:

HTTP/1.1 200 Success

WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca
The client will decode the GSSAPI data and provide it to gss_init_security_context using the context for this server. If the status is successful in the final gss_init_security_context, the response can be used by the application.

OAuth

OAuth (short for Open Authorization) authentication is an open-standard authorization protocol that allows unrelated servers and services to allow third-party access to the resource using access tokens rather than sharing their credentials. This process is also known as “delegated secure access”.

A very simple example of this authentication scheme is when a user logs into a website (the third party) and the website offers to log in using accounts from other websites/services, such as Google or Facebook – which means you don’t need to enter your passwords. When you click on the button linked to the other site, the other site authenticates you and the site you were originally connecting to logs in using the permission obtained from the second site.

In this scheme, the following agents participate:

Resource owner: entity capable of granting access to a protected resource. When the resource owner is a person, it’s called end-user.
Resource server: The server that hosts the protected resources. Access to it is done through tokens.
Client: application that requests protected resources, through the owner’s authorization.
Authorization server: server that issues access tokens to the client, after it has been authenticated and authorized.

Syntax: Authorization: OAuth realm="Example",

oauth_consumer_key="C_KEY",

oauth_token="TOKEN",

oauth_signature_method="HMAC-SHA1",

oauth_signature="SIGNATURE",

oauth_timestamp="TS",

oauth_nonce="NONCE",

oauth_version="1.0"

OAuth authentication flow:

The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown in the image above), or preferably indirectly through the authorization of the server as an intermediary.
The client receives an authorization grant, which is a credential that represents the resource owner’s authorization, expressed using one of the four grant types defined in the specification, or using an extension grant type. The type of authorization grant depends on the method used by the client to request authorization and the types supported by the authorization server.
The client requests an access token when authenticating with the authorization server and presenting the authorization grant.
The authorization server authenticates the client and validates the authorization grant and, if valid, issues an access token.
The client requests the protected resource from the resource server and authenticates by presenting the access token.
The resource server validates the access token and, if valid, accept the request.

VAPID

VAPID (Voluntary Application Server Identification) authentication is designed to allow sites to authenticate with push servers independently. Websites can send push notifications without knowing which browser it’s running in. This is a significant improvement over implementing a different push protocol for each platform.

It’s possible that the client includes his identity in a signed token with the requests he makes. Subscription can be used by the push service to restrict the use of a push subscription to a single application server.

Syntax: Authorization: vapid

t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczov L3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1h aWx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_ HLGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,

k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs

Where t is a JWT (JSON Web Token) token generated by the client and k is the private key (base64url-encoded) that signs this token.

What is JSON Web Token?

There are currently many techniques that can be implemented to control access to online resources. One of the most common is the use of some type of access token, generated by applications to ensure that only authenticated users are allowed to use certain resources, such as APIs or media files. And one of those modern solutions is the JSON Web Token (JWT).

JWTs are cryptographically protected from tampering. Furthermore, with them, instead of storing the token state in the database, it’s possible to encode this state directly in the token ID and send it to the client. For example, you can serialize the token fields in a JSON object, encode it with base64url to create a string that can be used as the token ID. When the token is presented back to the API, all you need to do is decode the token and parse the JSON to retrieve the session attributes.

Enhancing Security for Restricted Content with JWT

Protecting restricted content from unauthorized access can be achieved through JSON Web Tokens (JWTs), which provide a scalable and efficient method for access control. JWT technology enables secure authentication for APIs and private content such as videos, online courses, and images.

JWTs operate without the need for database validation, making them well-suited for high-performance applications. However, because JWTs are typically larger than session IDs, they can impact network performance when included in every request. Running authentication processes at the edge helps mitigate this issue by handling validation closer to users, reducing latency, and ensuring efficient access control.

Additional security measures can further enhance JWT-based authentication, such as defining expiration times for keys and managing permissions through a combination of Key IDs and secrets. By processing authentication requests at the edge, validation occurs before reaching the origin infrastructure, eliminating the need for a centralized authentication server and improving both security and performance.

This approach ensures that restricted content remains protected while maintaining fast and reliable access for authorized users.