- Software to software authentication management - in case software needs to communicate with the API-keys-enabled application, there is not need to manage sessions. If session used, then the consuming software may store a session and manage re-authentication if expires. There is another approach to consume services as well - consuming any service following login, which causes for performance issues. Thus, a session-less approach needed.
- Entropy - the definition of NIST of entropy is "an estimate of the average amount of work required to guess the password of a selected user". Since regular users don't use long passwords, hackers can execute a Rainbow Tables attack to guess the passwords. Thus, an API key generation policy can enforce the creation of long random passwords, e.g. 40 characters consist of upper case, lower case, numbers and special characters. For more information about the need for entropy, check Avi Douglen's deck form OWASP IL 2014 - "Passwords, Rehashed All Over Again".
- Password policy enforcement - many systems allowing only one password policy for all users. Such policy may contain password expiration, which requires to change passwords on all applications consuming the services from the developed application. This may cause so fails in the production, which are definitely bad for business.
- A single identity management with distinct credentials - when managing large scale applications serving other applications, the best practice recommendation for managing single user per consuming application becomes hard. It becomes even harder when permissions changes needed across the consuming applications. Thus, by managing API keys for single identity, few applications representing the same user can use distinct API keys. If permissions change needed, only single user's permission to be edited.
- Minimal exposure - API keys generated once and responded to the consuming client via simple response or a file download (more common). This approach allows API keys to be exposed only at a certain time following the generation of them.
- Accountability - Since the generation of keys requires permissions (mostly by a non-applicative user), it is easy to trace the user who generated the key. This user is accountable for the security of this key.
- Fast calculation - API keys taking the advantage of digest authentication, which performs message-based authentication by performing an HMAC function to verify user's identity.
- Distributed caching - although caching is not a specific feature of API key management, but in scalable systems, only one call can be executed to the database in order to serve multiple requests.
I decided to perform sequence diagrams for two main steps of the API authentication mechanism.
The first sequence is the registration of a consuming software using a logged in non-applicative user. This step is required in order to generate the API keys. The sequence diagram of such process illustrated below:
In the process above, the API keys are generated for a specific identity name. In order to store the keys securely without compromising the Secret Key, a Key Encryption Key (KEK) encrypts the Secret Key before storing it in the database. When the software client received the key pair, the Secret Key must be stored securely since all requests to be authenticated by this key.
Following the registration, the software client can consume any service by performing an HMAC with the Secret Key and the payload of the message. The sequence diagram illustrated below:
Although this sequence diagram looks more complex, the process considered as secure and fast since the Secret Key is not exposed in the transport at any stage, while the call to the database for getting the Encrypted Secret Key can be cached.
I think that API keys are a must for any application serving software clients due to many advantages in both security and performance domains.