REST API can we get rid of Basic Auth?

Every application either exposes REST API or is consuming REST API. I am still amazed HTTP Basic Auth is the most commonly used authentication method to access REST API. What is wrong with that..? Its simply because you don’t have control over how your API will be used.

REST API with Basic Auth = Insecure clients

Most common misuse of basic auth for REST API is the hard coding of credentials in JavaScript or Mobile applications. Both of them are code running in a hostile environment and anyone can gain access to the credentials, with little to no effort.

Its much easier to claim that your API is secure because it has HTTPS (lets not even go whether or not its TLS 1.0 /1.1/1.2) and requires username and password.

Basic Auth as easy option / band aid “Bolt On” security

I am still surprised to see REST API that is part of a platform, software ( closed or open source), etc. tend to start with username and password and other options are usually hidden or have to be customized.

Username and Password used to be okay when the deployments used to within your own data center. You no longer have the “Firewall” or “someone” to blame, as more and more services are deployed or consumed in the cloud. The client applications have to encrypt and still retrieve the passwords in plain text. ( Its worse when its in JavaScript or Mobile app) and manage the keys. Last thing you want to see is a report on how you are hardcoding the passwords in source code.


So how can we fix this? To start with every API that is exposed should support some type of Token. ( I am intentionally keeping it open to support various methods other than password). Client applications should exchange credential with a “Separate” endpoint (Token issuing end point) to obtain the token. If we force this design, then JavaScript or Mobile applications can be designed to have the tokens generated on server side and will remove the need to have hardcoded passwords.

If you are asking the question of why should API support Tokens as default mechanism, answer is very simple — can you control how your API will be used? One has to think about how any API that is exposed will be consumed by the clients. When you ( i.e. you or your organization) don’t have control over the client applications, it is time to step back and think how can you secure the end points with “Tokens”.

Any open source software that exposes REST API should by default accept token and have a plugin mechanism to support various token formats.

Let’s not hide behind Firewall or documentation:

Any other recommendation such as Firewall, Reverse Proxy, Application Gateway are practically non starters as it involves someone other than development team. Consumers will continue to user username and passwords hardcoded in JavaScript or elsewhere as long as service supports Basic Auth.

Its not my responsibility :

Yes it is true that it is not the responsibility of the service provider to ensure client applications follow the security best practices. I often hear answers from engineers such as “Service only supports Basic Auth” or “Password is stored in JS file…” or “We capture the password on the client and is encrypted”. The later part is usually followed by “ is encrypted and encryption key is hardcoded in the code”.

Building Security Within:

Secure software starts with having constraints within software to force security best practices. Let’s try to stop writing documents on how to secure and rather have security best practices as default. One can jump through hoops to build insecure applications if they decide to. Would love to hear your thoughts on this.