We tend to spend a lot of time talking about the wonders the Application Programming Interface (API) can do to connect our digital and mobile world, but we must also talk about the elephant in the room: API security is a real problem.

As the go-to method of building and connecting software applications continues to be via API routines, protocols and tools, the API security risk continues to grow along with API popularity. Just in the last year, API vulnerability and carelessness has attributed to cyber attacks and risks for identity theft in popular social apps like Pinterest, Instagram and Snapchat.

We know that API security (followed closely by API usability), is the top priority for API professionals. Now we’ll break down the tools and techniques necessary to limit vulnerability and strengthen security as you develop and expose your API.

Identity is at the Forefront of API Security

API security isn’t 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.

Introducing the Neo-Security Stack

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 we at Nordic APIs refer 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 or System for Cross-domain Identity Management for user account provisioning and deprovisioning
• U2F or 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. Read on for some helpful insights that will make these protocols more approachable.

OAuth Basics

As the risk associated with an individual’s online identity increases, we need to ask permission before exposing identity and any vulnerable resources with an API. OAuth 2 is the framework or meta-protocol under which we create other protocols to define how tokens are handled.

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. Below we’ll dive into the process behind a common OAuth server flow.

OAuth Web Server Flow

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 are they using and who is that 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.

Layers Beyond OAuth Within the Neo-Security Stack

Diving into OpenID Connect

OpenID Connect and its predecessor SAML focus on authentication and federation, identifying a user before information is pushed to a third-party. You can then give strategic partners similar access to make API calls.

There are even third-party organizations responsible for determining identity, often called an “identity provider” or IdP. Developers are able to use an IdP and push that access to a third-party app. This allows the IdP to act as an identity provider as well as an API provider, allowing the IdP, acting as an API, to exchange data with the app.

OpenID Connect builds on top of OAuth2 to define a federation protocol. Optimized around the user consent flows, OpenID adds identity-based information on top of OAuth into the inputs and outputs.

SCIM Identifies User and Group Schemas for Developers

SCIM defines the RESTful API protocol to manage and specify user and group schemas and the properties on them, including defining the markup for representing things like first/last name, email address, actual address, and phone number. It enables you to identify users within groups so you can easily add or remove them, without having to reinvent the API.

Different layers of the Neo-Security stack can be combined. For example, OAuth is used to secure SCIM API calls for instances like delegated access for creating and updating users. SCIM and SAML or OpenID Connect can be bound to provide just-in-time provisioning (JIT), which allows you to create, update, and delete users without tying it to an authentication event.

What Makes Up the JSON Identity Suite?

The identity-based information provided by OpenID Connect is marked up in something called Jason Web Tokens or JWTs (pronounced “Jots”.) JWTs are part of the JSON Identity Suite that the Internet Engineering Task Force (IETF) has defined. JWTs are designed to be light-weight tokens that can be easily passed in that HTTP header. They are like SAML tokens, but are less expressive, more compact, with less security options, all encoded in JSON instead of XML.

Beyond JWT, the JSON identity suite of protocols includes:

• JWK: JSON web key is a data structure that sets up the protocols for defining asymmetric and symmetric keys
• JWE: JSON web encryption is a compact web encryption format, ideal for space-constrained environments
• JWS: JSON web signatures enable multiple signatures to be applied to the same content
• JWA: JSON web algorithms register cryptographic algorithms
• ** Bearer Tokens:** An auxiliary specification used to define how to use these tokens and to put a JWT into an HTTP authorization header for an API to receive

Neo-Security Stack Protocols Increase API Security

There’s no doubt that security risk increases as more and more APIs are opened up to connect and share information. The technologies and procedures described in this article aim to decrease vulnerability. Though the IETF has outlined a set of protocols to guide API development and exposition, API providers must educate themselves on the language of security in order to avoid human error and prevent API attacks.

Want More?

Can’t wait to learn more about API security and other API-related tricks, tools and topics? Come to one of our seminars on the API lifecycle In May as we bring API developers, entrepreneurs, and engineers together in London, Seattle, Copenhagen, and Munich for our first global tour. Registration for the 2015 Spring API Tour will open soon, so stay tuned.