Problems with Basic Authentication for REST services

Authentication has been in the HTTP spec since 1995 when the first draft of RFC 1945 was published. Initially, only Basic Authentication was standardized, later to be supplemented with Digest Authentication, e.g. in RFC 2069, in an attempt to mitigate the obvious insecurity of sending username and password in cleartext. Given that it relies on MD5 hashes, it is unclear that it affords much better security. Digest Authentication never gained a lot of traction, but Basic Authentication became very popular. HTTPS mitigates the most glaring security problem of Basic Authentication.

While using Basic Authentication to control access to REST APIs seems straightforward, designers need to be aware of following limitations:

• In order to let a client make a REST call on their behalf, users must hand over their credentials. Such client could, for example, be a mobile application. In effect, the client has been given unlimited scope to impersonate the user. In other words, the user has granted all access rights to all resources in the authentication realm forever, or at least until the password is changed.
• Basic Authentication does not provide a mechanism for logging the user out. Credentials are cached in the browser and re-submitted with subsequent requests.
• Basic Authentication is inherently tied to passwords. While passwords are convenient and cheap, they are unsuitable as the sole means of authenticating to gain access to high-value resources. Introducing a second factor to complement Basic Authentication is probably technically doable, but is unlikely to lead to an elegant or secure design.
• Before users can make use of an API, they must be registered with the service. This is at odds with casual use.

Digest Authentication suffers from the same drawbacks.

Basic and Digest Authentication are therefore not suitable authentication mechanisms except for the simplest, standalone, low-value REST API that provides services to a well-defined, stable community. For anything else, authN/Z technologies should at least

• limit the scope of access rights granted to the client,
• limit access rights in time,
• avoid exposing user credentials to the client,
• support multi-factor authentication.

Modern protocols such as OAuth and OpenID Connect address these concerns.