Next on the technological horizon: ‘The Internet Of Things’. A world where things from toasters to wrist watches demand access to ‘everything from anywhere’. Naturally the relationship between a client and the data residing on a server needs to be a private, highly guarded one. This may prove to be challenge. According to the Symantec 2014 Security Report, a 91% increase in attacks occurred in 2013 and a 62% increase in security breaches. In light of this it makes sense to reexamine how we protect the client-server relationship of our systems. The purpose of this article is provide a closer look at two prevalent approaches for performing web api security authentication: cookie-based authentication and token-based authentication.
HTTP and REST
Before we get started, let’s review two Application Layer protocols relevant for the discussion: HTTP (Hypertext Transfer Protocol) and REST (REpresentational State Transfer).
HTTP consists of a request/response pair between client and server using verbs such as GET, POST, PUT, DELETE to define the actions to be performed. After an exchange, the two parties do not ‘remember’ anything about their previous conversation. That is what makes HTTP a stateless protocol.
REST is a popular protocol that defines the manner in which the client accesses data on the server using the same HTTP verbs. For example, ‘GET http://yourserver.com/productions/product_id’ represents a way to retrieve information about a specific product from the server. REST is also stateless.
So how would we for example implement Restful API authentication? Without a way to track authentication state or a meaningful way to authenticate a client, a web service using HTTP and REST is simply reduced to a request and response system.
What is Cookie-Based Authentication
Cookies provide a way to create stateful sessions between client and server and are described in RFC 2109 by the Internet Engineering Taskforce (IETF).
In this approach the client passes user credentials to the server as part of a HTTP POST request. The server then validates the credentials and issues a session id to the client. The client then sets the cookie – a small text file which is nothing more than a tiny dictionary of key/value pairs – in the persistent or in-memory cache of the browser. For consequent requests to access restricted endpoints, the cookie session id is passed to the server every time.
One of the major limitations of the cookie-based approach is that is primarily designed for web browsers and not for other types of clients such as native mobile applications or desktop programs. Other limitations include cookie size (about 4KB depending on the browser), the fact that the user may disable, modify or erase cookies at any time and that cookies can be exploited by hackers.
When using the cookie-based authentication approach we suggest the following security measures:
- Implement SSL to encrypt network traffic and avoid eavesdropping and man-in-the-middle attacks.
- Set the ‘Secure Flag’ and ‘HTTP-Only flags’ on every set-cookie request.
- Avoid storing plain text user credentials inside the cookie. Instead, use a session id.
- Ensure that the cookie expiration period is set to a reasonably small time period.
- Enable cookie encryption when available and change the default cookie encryption key when using an off-the-shelf web application or CMS product.
What is Token-based Authentication?
The main idea behind token-based authentication is that the server provides the client with token which can then be used to access a data resource. Just like a movie ticket stub, the token only provides access for a limited time. A number of protocols exist that implement the token-based approach: oAuth 2.0 (used by Google APIs ), xAuth (used by Twitter ), or other implementations (e.g. Amazon Signature). While this approach also provides a mechanism for authentication and stateful sessions, some token-based protocols like oAuth have additional advantages:
- Since these protocols do not rely on cookies, they can be implemented by all types of clients.
- oAuth supports content sharing scenarios in which a resource owner can dynamically share access to a resource with a third party without having to provide the user’s credentials.
- Security features such as signature, nonce and timestamp help to prevent a variety of attacks.
In token-based authentication the client passes user credentials to the server – normally as part of the URL string or inside the HTTP header. The server then validates the credentials and issues a token to the client. The access token is generally stored in the client’s memory and passed to the server with every consequent request.
- The oAuth protocol itself does not provide the encryption of message and relies on SSL to provide this level of protection.
- Due to implementation complexity the oAuth 2.0 specification drop signatures which were used to verify that client requests have not been altered. However, this opens the door to man-in-the-middle attacks.
- The protocol doesn’t actually verify the identity of the server to the client and vice versa as it is done with certificate authentication.
- Use token-based authentication only in combination with SSL
- Use a standard protocol like oAuth, instead inventing your own.
- Use validated client and server libraries to implement the selected protocol (e.g. oAuth).