Application programming interfaces (APIs) are synonymous with mobile programming—they make everything in the mobile space possible. In this respect, while securing an API is just one part of a holistic approach to protecting data and networks in a mobile-driven market, it’s the most important building block of an API’s strategy itself.
API security comes with its own set of challenges. Whenever you’re creating entries to your server and network, you’ve got to be certain you’re not exposing anything sensitive or private to unauthorized user, and you’re not creating vulnerabilities in your infrastructure. APIs funnel data between applications, the cloud, and a multitude of different API users, all of whom need to be verified and authorized to access that data.
Here’s a look at some of the basics of API security—and mobile security as a whole.
Security first: Why API security measures should be a priority.
There are many phases to building an API strategy—from establishing assets and a use case to monetizing the API and turning it into its own viable line of business. When planning an API’s architecture, however, one of the very first things that needs to be established is the security of that API.
There are three main security measures in an API security stack: identification, authentication, and authorization. Other types of standards-based security measures can tackle delegation, which gives authorized users limited access and rights to an API and lets an app function on a user’s behalf, and federation, which is a next-level security measure that separates key resources from users, often with encryption measures.
Identification
Identification is the first line of defense and answers the question: “Who are you?” This is typically done through API keys, unique codes that developers are given and can use to access your API. API keys are randomized, unique identifiers so there’s no need to mess with passwords. Think of them just like a key: they unlock a lock and let you in. In the same vein, SCIM (simple cloud identity management) allows you to create and manage users.
Your entry-level approach to API security probably includes API keys, but these shouldn’t be treated as the end-all-be-all of your API security plan. There are inherent issues with API keys, mainly surrounding the fact that keys are like passwords—they can be compromised, duplicated, and stolen. Also, the API key provider has little to no oversight into who is using those keys.
Why You Should Use API Keys
- An API key can give you the ability to monitor use and metrics.
- They’re incredibly easy to use and give you built-in analytics—a big bonus.
- API keys make it a cinch to shut off access to your API if someone is breaching terms of use or a glitch is causing too many calls into your API. For example, the spam filter plugin Akismet that’s commonly used on WordPress blogs can shut down access by an API key if it detects that the blog using that key is breaking its terms of use policy.
Why You Shouldn’t Use API Keys Without Other Security Measures
API keys are important, but they aren’t enough. Why? Keys to locks can be lost or stolen.
- API keys carry many of the same security concerns as passwords: they can be stolen, lost or compromised, and they give the API key provider no oversight into who is actually using that key.
- API keys aren’t encrypted, so don’t think of them as the last and final word in security.
Bottom line: API keys can grant someone access to an API, but they can’t prove who that someone is. That’s what the authentication is for.
Authentication
If API keys have certain vulnerabilities and there’s no oversight into who is using the key, what’s a good solution? Authentication answers the question, “How can I determine that you are who you say you are?” By implementing things like usernames and passwords, you get the next level of security. Authentication can also affect throttling, allowing an application to make more or fewer calls to the API based on authentication method. Examples include HTTP Basic Authentication and third-party authentication services like Google.
Authorization: Tokens & 2-Factor Authorization
Just because you’re authenticated to use an API doesn’t mean you can do just anything with it. While authentication lets an API know who someone is, authorization answers the question “What can you do with the API?” It does this with tokens, 2-factor authorizations, and one-time use codes. It also authorizes an app to do things like collect data in the background, use your profile information from one app in another app, or allow an app to post things on your behalf.
Delegation & Token Handling with OAuth2
OAuth2 is a standardized protocol for managing the exchange of tokens that makes secure API connections possible. OAuth is designed to bypass the need for a user to enter their username and password, using tokens instead of passwords makes APIs less susceptible to security issues*.
OAuth deals with four points along the API flow of information: clients (the mobile or web apps using them), the authorization server, the API (and the resources it shares), and the API owner who’s authorizing and delegating users. OAuth is really just a framework that resides on the authorization server, granting user permission via tokens that are generated for one-time use between the client and end user. It does this by collecting a credential, like a 2-factor SMS question sent to a mobile device. OAuth tokens are more secure than API keys alone because access is delegated to a specific user. That access can also be taken away—something you can’t easily do with keys.
*Note that OAuth is not an out-of-the-box solution and needs to be customized to your API to best suit your specific use case, permissions, and scope.
For encrypted HTTPS web connections, JSON web tokens (JWTs) are more lightweight option for user identity that are ideal for mobile API security. They’re also widely used in APIs in microservices environments.
OpenID Connect
OpenID Connect is all about making things easier on your users, allowing them to use their same credentials so don’t have to register and sign in at multiple domains. It’s an example of a federation protocol that’s specifically designed for mobile use.
Encrypting API Traffic with SSL
Encryption should go hand in hand with any API design that’s granting access to sensitive information. Using an SSL (Secure Sockets Layer) or TLS connection is another level of security that keeps API keys secure. It can be more complicated to set up, but is very important given most of this data is being transferred over wireless networks, which can be more vulnerable.
This is a just quick intro to API security measures, which is only one part of the bigger mobile security field as a whole. Consult an OAuth security professional when building your own API or building an app that’s based on an API to make sure you’ve covered rights management, authorization, authentication, and data security from all angles. To learn more about the power of APIs and how to plug your business into the thriving API economy, download Upwork’s free ebook, The API Economy.
Read more: Ensure Speed & Quality to API Users
Comments on this article are closed.