This platform has a RESTful HTTP-based API, just like a growing number of other applications.
With development frameworks like JAX-RS, it’s relatively easy to build such APIs.
It is not, however, easy to build them right.
Issues With Building HTTP-based APIs
The problem isn’t so much in getting the functionality out there. We know how to develop software and the available REST/HTTP frameworks and libraries make it easy to expose the functionality.
I’ll be talking more about how to help developers meet all the constraints of the REST architectural style in future posts.
Today I want to focus on another non-functional aspect of APIs: security.
Security of HTTP-based APIs
Availability of web services is not dramatically different from that of web applications, which is relatively well understood. We have our clusters, load balancers, and what not, and usually we are in good shape.
Confidentiality and integrity, on the other hand, both require proper authentication, and here matters get more interesting.
Authentication of HTTP-based APIs
For authentication in an HTTP world, it makes sense to look at HTTP Authentication.
This RFC describes Basic and Digest authentication. Both have their weaknesses, which is why you see many APIs use alternatives.
Luckily, these alternatives can use the same basic machinery defined in the RFC. This machinery includes status code
401 Unauthorized, and the
Authorization headers. Note that the
Authorization header is unfortunately misnamed, since it’s used for authentication, not authorization.
Authentication of HTTP-based APIs Using Signatures
It is therefore good to see that a new IETF draft has been proposed to standardize the use of signatures in HTTP-based APIs.
Standardization enables the construction of frameworks and libraries, which will drive down the cost of implementing authentication and will make it easier to build more secure APIs.