Securing your APIs with IBM API Management
Jackie Zhu 1100007DBS email@example.com | | Tags:  security management oath authentication apim authorization api
0 Comments | 3,508 Visits
Andrew Daniel is a software engineer for IBM API Management, developing the user interface. He has been in the team for 3 years after completing a degree in Computer Science with Games Technology and has become an expert in APIs, Web Technologies and Java.
Today, more and more information is widely available over the internet for everybody to consume how they see fit, and a lot of this information is accessed via web APIs. We can find the current weather in any city, browse hundreds of photographs, and even check the schedule and status of nearly every flight happening at any moment. However, information retrieved from APIs isn’t only generic, but it can be personal. Personal information such as our email address, postal address, date of birth, even our bank information can be available through API calls. With thieves constantly attempting to access our personal information in attempt to steal our identities, security is an important factor to consider when designing and creating an API, especially when sensitive data is concerned.
It is therefore crucial that we only allow the correct users access to the information that they are authorized to consume using secure methods, so this should be key in the design of an API and its resources.
Not every API needs to be secured. Some may not contain sensitive data, but a small subsection of your APIs are likely to need security.
Security can be implemented in the many stages of an API call from client to server:
Each of these three stages of security can be handled in IBM API Management in the following ways.
Authenticating the user
A typical scenario in IBM API Management is exposing personal data for a user. The user uses a third party application to consume, process and display the data in a meaningful way. But how does the server retrieve and display only information that is relevant for the user?
IBM API Management offers two ways to authenticate a user:
For each call to the resource server, IBM API Management, the application will need to pass the user’s username and password in the Authorization header. This is a little risky, as even though the transmission will be encrypted with TSA or SSL, that information is still passing between servers each and every time an API is consumed.
Implementation of OAuth can be seen all around the web, especially in social media websites. It is a way of allowing an application to access user’s information on a resource server without seeing or knowing the user’s credentials. When the user wishes to access their personal information in the application, they are redirected to the resource server where they login and then authorize the application to interact with their data. They are then redirected back to the application, which retrieves a session token to use in subsequent calls. This method is more convoluted, but more secure as user credentials are only passed directly to IBM API Management, and only once.
Authenticating the application
APIs in IBM API Management can only be called by applications that provide a valid App ID, and in some circumstances, an App Secret too. They are generated when creating an application in the developer portal, so be sure to take note of them and keep them safe for future use. To provide the App ID with an API call, append the url with this querystring:
Encrypting the transmission
Every call to an API provided by IBM API Management is secured with HTTPS, which encrypts all packets of data using SSL or TLS, much like you’d expect when using social media websites. Encrypting the transmission means that without a special key, the data cannot be understood by any attacker who manages to capture the data.
Encrypting the data is only one part of the security. The application must be confident that the server it is communicating with is the intended server. This is done with certificates. A website certificate serves multiple purposes; most importantly it contains the key for encrypting and decrypting the transmission, but it also contains an identity which can be confirmed as trusted from a pre-established trusted sources.
Enabling all of these measures listed will ensure APIs have the full amount of security offered by IBM API Management. For details about how to apply each aspect of security to an API and its resources please read Chapter 5 “API Security” in the IBM RedBooks publication: Exposing and Managing Services with IBM API Management.
For IBM API Management related blog posts, see:
For IBM API Management Redbooks publication, see: