How the web works — Authentication using cookies

Authentication is a method of verifying the identity of a user. HTTP protocol provides a general framework for access control and authentication. Authentication methods can be used by a server to challenge a client request, and by a client to provide authentication information. This article provides an overview of authentication using cookies.

This scheme of authentication in its simplest form uses a HTML form, a storage (either database or in-memory) and a key-value pair called a cookie that is exchanged between the client and server.

Let us see how these work together to achieve authentication.

• A user fills a form similar to the one above, the browser sends their username and password as a HTTP POST method.
• The HTTP request is then encrypted using any of the TLS protocols (TLS 1.2 or TLS 1.3) to secure the user’s data.
• The server examines the HTTP request to check for the presence of any authentication cookies. If none are present, it authenticates the user using an authentication provider. Once the user is authenticated, it generates an authentication cookie. If the user cannot be authenticated, the request fails.
• The authentication cookie holds information to indicate user’s authentication has proceed successfully. The cookie is set to a session identifier generated using an algorithm that the backend application implements. The backend application may use the session identifier as an index into the database store or in-memory cache that holds information about the user’s data such as the username and password, among other things.
• The back-end application returns a HTTP header called Set-Cookie as part of its response and sets the cookie to the session identifier generated in the previous step. The cookie is assigned a name which is also sometimes referred to as the key portion of the cookie. The session identifier is the value portion of the cookie.

set-cookie: JSESSIONID=1:WaV0AOduouNLdyAVF8xRJ0L9Ndkk5g:TLUeTlQVetUvnpfU

• The browser returns this cookie in every request it sends back to the backend by setting the Cookie request header.
• Multiple cookies can be sent. They are separated by a ‘,’ (comma) when sent in the Set-Cookie header. They are separated by “;” when sent in the Cookie header.
• Set-Cookie header allows setting of various attributes that add security. These are
  - expires: This attribute holds the date when the cookie becomes invalid. The server re-authenticates the user if the cookie has expired.
  - samesite: When set to strict, the cookie must be sent from a page that matches the domain attribute. If the domain attribute is missing, the cookie must originate from the same site to which it is being sent to.
  - httponly: If the cookie holds the httponly attribute, it cannot be accessed via JavaScript that runs on the user’s browser. Secure: The cookie can be sent only on a https connection.
• Using cookie based authentication scheme requires session replication or session affinity (also called session persistence) if the back end application is deployed on multiple servers in a cluster.
• Session replication and session affinity are techniques that help the solve the following problem — a user may be authenticated by a server (say S1) when the first request is made. However, the load balancer may send the second request to any of the servers in the cluster based on the load balancing algorithm (say S2). In such a situation, all the servers must share the session information via session persistence to ensure that the saved session can be retrieved by any of the servers receiving the subsequent requests. If the session information is not replicated, the user’s session information saved by server S1 will not be available to the next server (S2) that receives the subsequent requests from the client. If session replication cannot be implemented due to scaling complexities, the load balancer must support session affinity or sticky sessions. If the load balancer supports session affinity, it remembers the server that served the first request for a given client and ensures to send all further requests from the same client to the same server. Session persistence has the drawback of not being to distribute requests evenly.
• Session persistence is implemented in the application server to which the backend application is deployed to. Session affinity is implemented in the load balancer or reverse proxy that is responsible for distributing requests to the backend application.

Conclusion

This post introduces how cookies are used for authentication and also brings up the issue of session persistence/affinity that must be addressed in multi-server environments.