Authentication for API operators
SaaS APIs tend to have one of two access mechanisms
Direct Access from application clients
Access restricted to application backends
The most important variable determining the suitable access mechanism for an API is the cost incurred by the operator to fight spam. I'll cover the basics of access, authentication, key rotation, quota enforcement and developer experience for these mechanisms .
Backend-only access
[Access]: Customers must strictly call these APIs from their application backends. Examples:
[Authentication]: Typically, authenticating to these APIs involves producing a secret shared with the API operator. This secret is not suitable for use on app clients.
[Key rotation]: If this secret were to be compromised, a new one could be regenerated and redeployed onto your application backends relatively quickly.
[Use cases]: This mechanism is most used when the API operator's cost of absorbing spam is very high. The backend-to-backend communication is the simplest trust model to build around.
[Quotas]: Per client application
[DevX challenges]:
Serverless apps will need to stand up a backend, resulting in the sacrifice of a strongly emerging customer segment
Strictly more tedious than integrating into clients.
Direct access using client secrets
[Access]: Customers can directly invoke these APIs from client applications (mobile and web).
[Authentication]: API operators generate a secret embeddable directly into client applications.
[Key rotation]: For all practical purposes, these client secrets are considered compromised at launch. They serve as a mechanism to (at best) identify the calling application on the API backend, making key rotation somewhat futile. In any case, rotating a key requires rebuilding and redistributing the applications, which may take weeks for mobile apps.
[Use cases]:
This mechanism is sufficient when the cost of absorbing spam is low. Often, this mechanism is an incremental step to more secure authentication.
Apps not accessible from the public Internet or run behind a VPN.
[Quotas]: Per client application
[DevX challenges]
This secret is easily reverse-engineered.
Unless the API operator can detect and is willing to absorb the cost of spam, this can be business-threatening for client apps.
Direct access using ephemeral keys
[Access]: Customers can directly invoke these APIs from client applications (mobile and web).
[Authentication]: APIs operators share a secret to be used on application backends to generate "ephemeral keys" that application clients can use to speak to the SaaS API backends directly. This mechanism forces even serverless applications to stand up an application backend.
[Key rotation]: If this secret were to be compromised, a new one could be regenerated and redeployed onto your application backends relatively quickly. Clients would, from that point, receive ephemeral keys generated with the new server key.
[Use cases]
This mechanism is most used when the API operator's cost of absorbing spam is high, and their APIs naturally involve parameters that originate on the client side. Example: Algolia search APIs
Another case is when regulations prevent app developers from being able to perform actions that only the API operator is legally allowed to perform. Example: Stripe Payments.
[Quotas]: Per ephemeral key/client instance.
[DevX challenges]
Like backend-only access APIs, serverless apps are forced to stand up a backend.
Without user authentication, this mechanism is really a way to offload the cost of fighting spam onto the application developer. Side rant, I find it frustrating how little API operators have done to improve the developer experience with this predominant access pattern.
Direct access using user authentication
[Access]: Customers can directly invoke these APIs from client applications (mobile and web).
[Authentication]: API operators directly verify the identity of the end users by either integrating with different identity providers or verifying that user auth tokens are signed by app backends.
[Key rotation]: Not relevant
[Use cases]:
These flows are best suited when application flows require users to be logged in.
As the most reliable of all auth mechanisms listed here, this mechanism is very well suited when API operators must impose quotas more reliably than per app or per instance impositions.
[Quotas]: Per user.
[DevX challenges]:
Users need to be logged in, creating friction in end-user experiences.
API operators will need to be configured with parameters needed to verify end-user access tokens as written above, requiring effort on the developer's part (and involving implementation costs for the operator).
