Top 10 Security Terms for API Developers
As a developer, you've been tasked with one of the most important jobs in helping your company increase its reach, brand awareness, and profit potential. The strategists in the conference room will make their demands, but the heavy-lifting (and let's face it, the fun stuff) falls to you. There are so many API resources available to you to help you be successful in your efforts, but we've pared down the key security issues that are most important for API developers to be aware of. This is not a definitive guide, but rather, a starting point so that you can begin to frame those things that will enable you to deliver a secure, viable and usable API.
Developer documentation abounds, and we will continue to guide you to help you become smarter about implementing various security mechanisms. The list we have provided is, admittedly, not totally conclusive, nor will it necessarily address all the issues relevant to your situation. But to begin, whether you are developing on your own, or if you need to explain to others in your organization, it is essential that you have a working knowledge of these security topics if you're going to begin using an API to extend your organization's data.
API Security Definitions
These are API security terms about which you should be knowledgeable, and this simple primer can help you hold your own when examining different API platforms and development tools:
OAuth is fast becoming the most important element of API and application authorization. Being flexible and fairly easy to implement, OAuth essentially enables an API and application to talk to one another. When used correctly, it will integrate with legacy identity systems (LDAP, Active Directory, CA SiteMinder, Oracle Access Manager, IBM TAM, RSA ClearTrust and more), and will have a management component that allows application owners the ability to change and update authorization. Private data is not communicated across the API when using OAuth, unless designated by the application owner, and only when the user allows it.
OAuth enables authorization, and from a security perspective, this is what self-managed applications are all about. Application owners need to be sensitive about both WHO access their data (and that from partners), WHAT they access (as in, what part of what piece of a data-set or database), and HOW they access it (it what part of the application, for instance). When you figure this out, you can apply OAuth as the key tool to ensure you have the management capabilities to secure all your data elements.
Enabling your apps to be usable on mobile devices presents a unique issue, and that's primarily because mobile applications access data in different ways. You can't process, nor render, the same amount of data on your Samsung Galaxy that you can on your MacBook. So it is important that measures are taken to use the same level of security for your APIs, but in a way that is unique to mobile platforms. In an ideal situation, your users won't need to use different passwords, nor should their experience be that different. For that to happen, things like SSO, digital certificates and application access need to be consistent across all instances of application usage.
REST can be difficult to explain, especially because its very nature is to enable flexibility in how services are deployed, managed and acted on as they interact among applications. REST is the quintessential software architecture for the Internet client-server relationship because it is as simple as can be while still maintaining the requisite level of sophistication for its many dynamic uses – such as scalability and uniformity in the face of customizability. It’s easy to see why this App-building platform is emerging as the top choice for Software-as-a-Service (SaaS) enterprises.
At a minimum, your solution must be able to authenticate the apps that are consuming your APIs. It should support a wide array of token types from simple HTTP headers (unsigned or signed), through x .509 certificates and highly advanced WS-Security headers.
Your API needs to provide a built-in PKI system and Certificate Authority for generating and distributing public/private key pairs and certificates. It should provide policies for specifying a wide range of different types of message signature and encryption supporting all common standards.
The solution should allow an App to use a single credential to consume many APIs, even if the APIs are offered by different companies with their own API Management platforms.
You need your API to be accessible and easy to work with, and with more applications being accessed in a cloud environment, access becomes more ubiquitous, but at the same time more potentially problematic. So developers should be able to get APIs, related documentation, and work with these tools through SSO. Keep in mind that access to the API is one thing, but to develop with it, the SSO will need to abide by guidelines through an asymmetric electronic signature that you should provide.
An additional measure is to create an API license that users will need to comply with. You can use an authentication system that provides alerts when a user is using the application beyond the scope of its use agreement. You can also encrypt your API so only validated users with a license code can access it.
The solution should be able to take the credentials provided by the app and use them to generate a whole new token as needed by your internal API. For example, it could authenticate an app using a signed HTTP header, and generate a signed WS-Security SOAP transport, or a SAML assertion for use by your internal service.
Make sure you use a centrally managed application authorization system that allows for you to do batch or individual granting of access through credential management. This is the most accurate way of tracking who has access to specific applications and data sources.
The API owner and community owner should both use a monitoring tool that operates through Java or some form of TCP/IP monitoring to discover what data is being accessed, and from what sources. This will give you insight into where your data is going.