Travis Spencer - Securing the API Stronghold: The Ultimate Guide to API Security

Knowing who has the right to do what with your API is key to success - Andreas Krohn, Dopter

Design all API security with public access in mind- Phillipp Schne, Axway

Application Programming Interfaces or APIs are not only an extension of the social web, but continue to seriously disrupt entire industries, change how Business-to-business (B2B) communication is throttled, spark innovation, and even inspire social change. Simply put by TechCrunch, APIs fuel the software thats eating the world.

Within this vibrant and quickly expanding economy, an increasing amount of data is being funneled through systems not designed with the scale of protection that is necessary. The risk of cyber threat is now the highest it has ever been, and it wont stop anytime soon. To combat this threat we must take the smart precautions to arm our systems. We build with the assumption that even private APIs will sooner or later become exposed to the public, and embrace proper security implementation as a top concern.

API security isnt just about the API itself, but also about the security of entire organizations and mobile products when they intersect with APIs.

When developing an API, the security of the mobile device matters just as much as the security of the API. Does it have anti-virus software installed? Is it enrolled in a mobile device management solution (MDM)? Does it have mobile application management software (MAM) installed? You also need to worry about enterprise security. Are the servers secure? Do your machines have intrusion detection?

At this junction of APIs, business, and mobile, lies the individual. Only when you know who is at this core will you know what they should be accessing and how they should be accessing it.

When we start to expose high-value information and resources, we need to have high-level assurance of who is accessing them. API security is comprised of a number of protocols, which Twobo Technologies refers to as the Neo-Security stack. This standards-based cloud security suite is usually comprised of these protocols and technologies:

• OAuth 2: The open standard for secure, delegated access
• OpenID Connect: For federation which allows for the secure exchange of user authentication data
• JSON Identity Suite: The collection of JSON-based protocols for representing the identity of users
• SCIM: System for Cross-domain Identity Management for user account provisioning and deprovisioning
• U2F: Universal 2-factor authentication for asymmetrically identifying users with a high degree of confidence that they really are who they say they are
• ALFA: For defining fine-grained authorization rules in a JSON-like policy language (which compiles down into XACML)

While the Neo-Security stack creates a comprehensive security solution for mobility, it is a great challenge for API developers to manage a myriad of specifications themselves.

As the risk associated with an individuals online identity increases, we need to ask permission before exposing identity and any vulnerable resources with an API. OAuth is a framework used to build API security solutions - a framework or meta-protocol under which we create other protocols to define how tokens are handled. Despite its name, OAuth is not for authentication, federation, or even authorization; it helps delegate access, ie. giving an app access to your data or service. A benefit of using OAuth is that somebody else authenticates users.

These following factors make up OAuth2 Protocols:

• Client: The web or mobile application involved
• Authorization Server (AS): The security token service, which issues credentials and tokens that represent the resource owner
• Resource Owner (RO): Authorizes or delegates access to the RS
• Resource Server (RS): Often the API itself, a collection of libraries and web applications

How these four OAuth2 actors work together varies with each integration. Well dive into the processes behind common OAuth server flows in future chapters, but to summarize:

A three-legged OAuth process occurs when an end user specifies that he or she wants to delegate access to a third-party application for use within the client application. The client application then redirects this request to the AS, which requires authentication for identification. The AS then authorizes that client and the RO is redirected back to the web app with a single-use access code.

The single-use access code is sent back to the AS, which then converts it into an access token that the end user may use to access the server. At the same time, the AS may also send back a refresh token which will allow the end user to use the same OAuth to access more than once.

Essentially, the access token allows a user to call the API. In return, the API gains access to information about both the client and the resource owner and what path they took, what client they are using, and who is the end user. With this information, you are able to create much more complete web access control decisions that improve API security. Everything is built right into OAuth2, limiting human-designed security errors.