REST and authentication

When we are designing a REST (Representational State Transfer) style Web service API, there is a problem that we often need to consider, that is, how to design a user authentication system (Authentication).

 

The more traditional approach is to first have a login API, and then the server returns a session ID. The client must carry this session ID for subsequent operations, but in this way, the service becomes stateful, which does not conform to the REST style. in principle. In addition, due to the existence of load balancing, there must be a public storage to save the user's session, which also increases the complexity of the system.

 

Therefore, it is better to pass the authentication information every time, so that the system is stateless. Of course, since authentication is required every time, it will inevitably reduce some efficiency. When necessary, consider caching user information on the server side.

 

A few things to note:

 

1. Passwords cannot be propagated

 

A relatively low-level mistake is that during communication, the user name and password are passed from the client to the server for authentication, which can easily be hacked and cause password leakage.

 

The standard practice is to use HMAC (Hash-based Message Authentication Code), the idea is not to propagate password, but to propagate the mixed hash value of content and password. Let's take a look at how Amazon S3 is authenticated.

 

Amazon has an AWSAccessKeyId and an AWSSecretAccessKey for each user, and each HTTP request requires an Id and an Authentication information. for example:

 

GET /photos/puppy.jpg HTTP/1.1
Host: johnsmith.s3.amazonaws.com
Date: Tue, 27 Mar 2007 19:36:42 +0000 Authorization: AWS 0PN5J17HBGZHT7JJ3X82: xXjDGYUmKxnwqr5KXNPGldn5LbA=

 The Authorization header is generated as follows: Where YourSecretAccessKeyID is AWSSecretAccessKey.

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;

Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );

StringToSign = HTTP-Verb + "n" +
	Content-MD5 + "n" +
	Content-Type + "n" +
	Date + "n" +
	CanonicalizedAmzHeaders +
	CanonicalizedResource;

CanonicalizedResource = [ "/" + Bucket ] +
	<HTTP-Request-URI, from the protocol name up to the query string> +
	[ sub-resource, if present. For example "?acl", "?location", "?logging", or "?torrent"];

CanonicalizedAmzHeaders = <described below>

 In this way, the server can easily verify whether the information is correct or not based on the user information.

 

2. Location of verification information

 

Authentication information can be placed in the HTTP HEADER or in the HTTP URL, like this:

GET /photos/puppy.jpg
?AWSAccessKeyId=0PN5J17HBGZHT7JJ3X82&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1
Host: johnsmith.s3.amazonaws.com
Date: Mon, 26 Mar 2007 19:37:58 +0000

 The advantage of putting it in the HTTP HEADER is that the URL is relatively clean and tidy, and it is suitable for sharing with others on the internet, while putting it in the URL is beneficial for publishing private access rights to third parties.

 

3. How to prevent Replay attack?

 

In theory, a hacker could steal your communication and resend it to pass the authentication. There are several possible solutions.

 

a. The client applies for a random number from the server, and this random number is used as the key for the next communication. Once it is used, it will become invalid immediately, which is the so-called "one-time pad". The advantage of this method is that it is very secure, but it increases the traffic, and because of the existence of load balancing, there must be a public store to save the key.

 

b. The server saves the used authentication information, and refuses to use it again as long as it is used. This approach does not require client support, but requires a common space to keep history.

 

c. Use timestamps. The practice is to include time information in the authentication information, so that the server side can reject requests with too long time intervals and consider them to have expired. This practice requires some form of time synchronization between the server and the client.

 

4. Do you want to use HTTPS?

 

If the security requirements are very high or the API is aimed at the Internet, HTTPS should undoubtedly be used to avoid the possibility of content being stolen.

 

If you are only in the LAN range or in a trusted computing environment, use HTTP to improve a little efficiency.