API Academy

Sponsored by Layer7

A person holding keys in their hand.

API Authentication Best Practices

By Adam DuVanderPosted on

Nearly every API needs to know the identity of the application or person making a request. This foundation of API security can be used to track rate limits, ensure proper audit logs are in place, and to authorize the appropriate access for each identity. 

In this post, we’ll explore authentication methods, how to keep tokens safe, and what comes next.

Common API Authentication Methods

You may be authenticating to an existing system, an API gateway, or both. What your internal infrastructure looks like should not impact how the API is seen by clients. There are a few common patterns, which can be generalized into static and dynamic approaches. 

As you review APIs, you’ll see these various approaches:

  • Static token: Your classic API key, this identifier is a difficult-to-guess alphanumeric string. When supplied with a request (usually in a header, but other methods are possible), you can typically identify the application, if not the end user. If this static token is discovered, another party could have access until revoked.
  • Static token and secret: An alternative to the API key is to pair it with another token. The two must be used in combination. They could be sent over Basic Auth, which essentially makes them a username and password. Or, you can use the secret to cryptographically sign a request.
  • Generated access token: Lastly, you can use short-lived tokens, which are generated from static tokens. This approach is used by OAuth 2.0, for example, to provide access with less possibility of token exposure.

You can see the security tradeoffs within these methods. Yet, any authentication method can be securely implemented if both parties can keep keys or tokens protected.

Consumers and Providers Must Protect the Keys

You wouldn’t keep the keys to your house taped to your front door. Similarly, you need to keep your API keys and tokens from becoming compromised. By their nature, these are shared secrets between the API provider and consumer. That makes for additional difficulty, because there are at least two parties that need to safely store the credentials.

There are some basics that apply to both consumer and provider: don’t check secrets into code repositories, especially those that are public. Even if it’s hard to discover, security by obscurity is not a long-term strategy. In fact, some API and cloud providers routinely search public resources for private keys, so they can proactively deactivate them and alert the API consumer.

On the provider side, you’ll need a secure key store as part of your API management solution. You will use it to confirm credentials with each request and manage token expiration. It’s technically possible to run your own encrypted database for keys, but a generic solution could be difficult to maintain.

In addition to both sides storing the keys securely, you’ll need to consider situations where a key must be public. The most common example is an API request that originates from a web browser. For example, Google Maps embeds keys in JavaScript, which any end user can discover via View Source.

One solution is to include different access levels for keys. Those that must be public should be restricted to read-only and perhaps only certain resources. That brings the discussion beyond authentication to the next step, authorization.

Choose an API Auth Standard

OAuth 2.0 does not technically perform authentication. This authorization standard is used alongside authentication—and this step of determining privilege is an important part of your API security.

Perhaps the biggest mistake API providers can make with security is rolling their own approach. Use existing standards because of their advantages:

  • Tooling exists to implement them easily and correctly
  • Engineers are more likely to be familiar with them (as consumers and providers)
  • They are hardened by the scrutiny of the security community

There are multiple flavors of OAuth, which allow for the various authentication methods mentioned earlier. OAuth can be used at the application level, or be used to determine user-level access. That means end users of applications will not need to copy keys or even know the protocols used to exchange data behind the scenes. In addition, scopes allow you to restrict or expand the access level.

To take the next steps with your API authentication and authorization, you can read the OAuth Overview Series on API Academy.