Authentication is a protocol used in HTTP communication to verify that a client is who they say they are before providing the client access to a certain resource on the web. This is another security procedure in the HTTP protocol to protect users and businesses in the online environment. When authentication is done at the edge, there is a significant increase in the speed and security of the process and, consequently, in the companies’ credibility and revenue.
HTTP Authentication
Authentication can be defined as an access control process, in which the identity of a client is verified in order to release their access to a certain resource on the web. Authentication therefore acts as another security measure in HTTP communications.
A customer’s initial request is usually anonymous, so it doesn’t have any information to confirm that the customer is who they say they are. This can be dangerous if the resource is more sensitive, such as bank details for example, as access would be granted to any user. This is where authentication comes in: to filter access, the server denies the anonymous request and indicates that client authentication is required. The authentication information between server and client is sent through headers.
What we described above are the basic principles of authentication, but as there are different types of resources to be accessed, the complexity of authentication also varies, as we will see later in the description of authentication schemes.
How Does HTTP Authentication Work?
RFC7235 describes that the HTTP protocol provides a general framework for access control and authentication through a diverse set of challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide authentication information.
What Is Challenge-Response Authentication?
In challenge-response authentication, the server makes a request – the challenge – and the client must send a valid response to be authenticated. A very common example of challenge-response authentication is password authentication, where the challenge made by the server is to request the password and the valid response from the client is the correct password.
Authentication Headers
The headers can be used by the server to define the authentication method (response headers) or for the client to give the credentials to be authenticated (request headers). Let’s see 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 UnauthorizedWWW-Authenticate: Digestrealm="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=authnc=00000001cnonce="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 is 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 UnauthorizedWWW-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.htmlAuthorization: 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 UnauthorizedWWW-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.htmlAuthorization: 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 SuccessWWW-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 is 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.eyJhdWQiOiJodHRwczovL3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1haWx0bzpwdXNoQGV4YW1wbGUuY29tIn0.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.
Do you want more security to protect restricted content from unauthorized access?
This is possible with Azion JWT, Azion’s access token solution.
With Azion JWT, you provide more security for your content and APIs. Since it runs directly at the edge of the network, this is a robust and effective solution for access control and closed or personalized content, such as videos, classes, images or APIs.
In this process, Azion uses JSON Web Tokens (JWTs), a type of token that can be validated without having to consult a database, facilitating the scalability of services. However, often the size of a JWT exceeds that of a session ID, which can affect network performance, as it must be included in every request. But as our solution is in edge computing, in addition to solving this problem, we added additional security features, such as providing and revoking permissions through the combination of Key IDs and secrets, in addition to determining expiration time for these keys.
Furthermore, by running inside Azion’s edge nodes, closer to users, Azion JWT validates the authenticity of requests even before they reach your infrastructure, without the need to consult a specific authentication server to validate the token’s credentials passed in the requests, providing more speed to the process and security for your business.
Do you want the best protection for your content and your customers? Talk to one of our experts here.
