REST API Authentication Options

There are three typical options available when addressing authentication protocols with regard to REST APls.

5 slides · 2 min read · Domain 8

Slide 1

Basic authentication with Transport Layer Security (TLS)

Basic authentication is the easiest of the | three to implement because the majority of the time, it can be implemented without additional libraries. Everything that is needed to implement basic authentication is usually included in standard framework or language library.

The problem with basic authentication is that it is basic, and it offers only the absolute lowest security options of the available common protocols, so depending on requirement, it may not be enough as there are no advanced options for using this protocol. Recommendations are that basic authentication should never be used without Transport Layer Security (TLS) (formerly known as SSL) encryption because the username and password combination can easily be deduced otherwise.

OAuth 1.0a

OAuth 1.0a is the most secure of the three common protocols. The protocol uses a cryptographic signature that is usually HMAC-SHA1 value that combines the token secret, nonce, and other request-based security information.

The great advantage of Auth 1 is that the token secret is never sent across the wire, which completely eliminates the possibility of anyone seeing the password while in transit.

This is the only one of the three protocols that can be safely used without TLS, although recommendations are always that TLS should be used based on the sensitivity of the information being transferred. However, as with any level of increased security, it usually demands a price. The price is that generating and validating signatures can become a complex process.

What needs to be used are specific algorithms and a considerable set of procedures that need to be followed. However, as levels of security have become much more needed, this issue has really disappeared as every major programming language now has a library to handle this type of activity.

OAuth 2

This is the next evolution of what was discussed, and Auth 2's current specification removes signatures so there is no requirement to use cryptographic algorithms to create, generate, and validate signatures.

All the encryption is now handled by TLS, which is a requirement. As a drawback, however, there may not be as many Auth 2 libraries as there are Auth 1a libraries, so integrating this protocol into your API may be more challenging. However, this is changing rapidly.

Digital signature and certificate management systems and protocols form a vital part of these (and other) authorization strategies; consider using Key Management Interoperability Protocol (KMIP) V1.1 client certificates or hardware security modules (HSM) for key and certificate management.

Test this domain