[Blog] Comparison of Security Techniques for RESTful Services

There are a lot of standards for describing how security should be performed for SOAP based web-services but none when it comes to REST. Due to the lack of common standard, the developers building RESTful services are tasked with researching ways of securing them. There are plethora of options available, some more appealing than others and it is easy to get confused while choosing the right approach suited for your use-case. This blog post aims to provide a comparison of these techniques, their pros and cons and their applicability.

HTTP Basic Authentication

This is the most straightforward way of securing a REST service. The user credentials are supplied with each request in the "Authorization" header. The credential "username/password" is encoded and embedded in the HTTP header. Since it is encoded and not encrypted, for meaningful security the request should go over a secure channel using SSL.

Pros

• Simple and easy to implement.

Cons

• Must be used with SSL for meaningful security.
• Must provide username/password with each request. Requires handling of naked user credentials.
• No support for federated access using protocols such as Shibboleth,SSO, OpenID ,etc.

Adapting WS-Trust/Security to work with REST

WS-Trust/Security describes how federated authentication should be performed in web-services. A Security Token Service(STS) is responsible for issuing, validating and revoking security tokens for a client application. The client must first obtain a token from STS before requesting the web-service. STS issues a security token (SAML) after validating the client credentials. This time-sensitive token is presented by the client with each request to the web-service. The web-service validates this token by making a call to the STS. After receiving a positive response from the STS, the request is processed. The security token is embedded in the SOAP message header.

The same model can be applied to work with REST. One thing to remember though is that with REST services there are always two classes of consumers : software programs and humans with web-browsers. If software programs are the only consumers of your REST services then this way of authentication can work just like with SOAP based services. But with humans this approach is not very friendly i.e it is not practical to assume that a human will manually authenticate himself to a STS , obtain a security token and present it to the web-service every time he wishes to use it.

Pros

• Consistent Standards-based approach to secure web-service be it SOAP or REST.
• Federated Access with STS.
• Doesn't require handling of user credentials.

Cons

• Setup requires deploying a separate Security Token Service configured against an Identity Provider
• A significant overhead is involved in obtaining/validating token with each request.

API Keys

In this technique a unique API key is generated for each user. This key has a limited lifetime during which it is associated with the user and his permissions to access the service. Typically a user shall sign-up for an API-key to access the service. The system-admin reviewing the application may decide to accept or reject the applicant , and assign permissions if accepted. The key is valid until it expires.

It is possible to incorporate a federated access , by letting users sign-up for the key using their institution's credential with Shibboleth , SSO or OpenID and then assigning them a unique key. This decoupling ensures that users need to use their own credential while accessing the RESTful services , and relieving the services from handling user credentials themselves.

Pros

• Simple to implement
• Works well with Shibboleth,SSO, OpenID and other protocols for federated authentication.
• Low overhead
• More scalable than the other techniques.

Cons

• Requires out of band mechanism for generating and managing API keys. Perhaps using some sort of an user portal where they sign-up for a key and receive an email notification when their application is approved.

The best example of API keys in action is Amazon's S3 REST Security. They use a concept of secret-key( much like api-key) , linked to the user's account, that is used to digitally sign each request(parameters) and generate a code. This code is passed along with the API call. The Amazon S3's server computes the code using the same secret-key and request parameters. If they match request is accepted otherwise denied.