Trust is one of the most important values that an individual places in a company when using any product, and it’s no different when it comes to software. The Google+ API breach and Facebook’s recent exposure reminds us of how data breaches not only bring about multi-billion dollar fines, but also severely jeopardize trust between app developers and their users. Unfortunately for Facebook, the revocation of approximately 90 million access tokens presents app users with a big opportunity to stop using their Facebook account to re-authenticate.
So how do you ensure that the tokens you’re using stays safe, data stays secure, and—in the event of a breach—the damage is minimal?
Keeping Tokens Safe
By being proactive, you can prevent the exposure of data by ensuring that our tokens are never exposed or stolen in the first place. Some steps you can take are to:
- Avoid sharing privileged information, such as Client Secrets or API Keys, on the client side.
- Encrypt token data both in transit and at rest.
- Tie Bearer tokens to user accounts to ensure the authenticated user is authorized to use a token.
- Ensure OAuth Redirect URIs point to specific URLs, instead of wildcard patterns that malicious users could potentially control.
- As an API provider, it’s best practice to either allow tokens to expire or provide a mechanism to revoke them. The client then uses a separate refresh token to request new tokens. This helps to prevent new users from using old rogue tokens.
Ensure Request Confidence
In addition to protecting the token itself, it’s often important to ensure the trustworthiness of requests and to neutralize threats before damage is done. Some helpful techniques include:
- Fingerprinting the client device or browser to increase confidence that requests are coming from the same trusted device/browser the token was first issued to.
- Setting up IP or role-based whitelists for accessing decrypted token data and performing API requests where appropriate.
- Set rate limits and alerts to guard against malicious attackers using compromised tokens to siphon large amounts of data. These circuit breakers are sometimes the first indication of a threat.
Minimize Damage from a Data Breach
In the event of a breach of a user’s account due to either party, you can take steps to ensure that the overall amount of data lost or the sensitivity of the data exposed is low.
You can use the same concept of using one token to provision another to issue lower-scoped tokens that limit the level of access allowed:
- As an API provider, you can support token exchanges to allow clients to exchange a privileged token for a more appropriately scoped one with lower privileges. Check out Kloudless’ authentication to see how it works.
- As an API consumer that is consuming a service that allows token exchanges, you can exchange tokens for lower scopes or request minimal scopes incrementally as required.
However, in the scenario the upstream API doesn’t support downscoped tokens, one solution would be to set up an internal token provider that acts as an API gateway to the upstream service and issues its own tokens with granular levels of access. This has similar benefits to using an intermediary like the Kloudless API or Kloudless Docker container.
How Kloudless Helps Ensure Your Data’s Security
Kloudless customers that authenticate across our supported third-party services receive security best practices out of the box with our Universal API Platform. Not only do we provide a unified OAuth 2.0 flow for all services, but this also extends to services that do not provide an OAuth 2.0 flow of their own. We encrypt all sensitive data asymmetrically at rest with 2048-bit RSA keys. This approach lets the web tier handle the OAuth flow and store encrypted tokens, while allowing privileged backend servers to access decrypted tokens to handle upstream API requests.
Kloudless also supports token exchanges (as detailed above) as an additional safeguard. You can find a comprehensive list of threats and security considerations related to providing and consuming OAuth 2.0 in RFC 6819.