• United States




When security and privacy overrule convenience

May 31, 20185 mins
APIsApplication SecurityPrivacy

Organizations can enable end-to-end API security with OAuth, OpenID Connect and ABAC.

blue padlock in circle pixels digital security padlock
Credit: Getty Images

Modern technology is constantly making our lives easier. Our phones and the applications we use make it more convenient to work, play and listen. If you need door-to-door ground transportation, you can access a ridesharing app to immediately call for a ride. If you’re deciding what to wear to work, you can quickly pull up a weather app, so you don’t end up overdressed or underdressed. The examples of modern technologies simplifying our lives are endless.

The convenience of modern technology is changing the way humans live, work and play. It’s also introduced a new level of convenience and ease. A top of mind issue getting more attention these days is the fact that these apps often contain sensitive personal information. For example, many contain financial information that you don’t want compromised or shared inappropriately.

In addition, these apps often connect to other apps or websites and share your personal information or data about you. If you utilize one app, you may be unknowingly enabling access to other connected apps or services. In fact, according to this story, 70 percent of smartphone apps share your data with third-party services. And in some cases, it’s not entirely clear what data is being collected and shared. What we do see, however, is that app developers also prioritize convenience by using third-party code libraries. When is too much convenience a bad thing?

These are examples that we, as consumers can all relate to. Applications also fuel the business economy—where the risks are the same, but on a much larger scale. Application developers must ensure sensitive information assets remain secured to safeguard that personally identifiable information (PII) is always protected, and that those parties that can see the data are authorized to do so. For business app developers, OAuth 2.0 can be the convenient third-party tool that is overly relied on in scenarios where fine grained access control is required.

What is OAuth 2.0 and how does it work?

OAuth 2.0 is a standard for token-based delegated access that can be implemented by any developer. It enables an end user’s account information to be used by a third-party service without exposing the user’s login credentials. OAuth 2.0, released in October 2012, was a vast improvement over OAuth 1.0 by incorporating field experiences and additional use case requirements. Other standards, like OpenID Connect (OIDC) are profiles built on top of OAuth 2.0.

OAuth 2.0 and OIDC provide the building blocks to define and utilize tokens that exchange information like scopes and user information across security domains. As described above, the ability to access multiple web sites using a single login credential is a powerful and convenient capability. However, OAuth 2.0 and OIDC do not define how authorization decisions are to be made.

Why is OAuth so important today?

Since its publication, OAuth 2.0 and profiles such as OIDC have seen widespread adoption for delegated access control use cases. Developers have a well-defined set of tools to incorporate OAuth 2.0 and/or OIDC into their applications. Users only have to apply a single set of login credentials to access multiple websites.

In many implementations, OAuth 2.0 is also utilized to provide microservices and APIs with enhanced security measures. Protecting an API architecture often requires an API gateway to provide internal security capabilities or integrate with an external Identity Provider that handles authentication, delegated access and other requirements. OAuth 2.0 can then compliment the API gateway by providing an access control mechanism to validate identities, manage/validate tokens and support other scenarios.

With all the convenience and capability that OAuth 2.0 provides, what could be missing?

Enhancing OAuth security with dynamic authorization to protect sensitive data exposed through APIs

OAuth 2.0 provides delegated consent authorization which allows a party that holds some authorization to delegate a subset of that authorization to another party, without requiring either party to disclose its credentials to the other.  OAuth 2.0 delegation is adequate for simple use cases, but what about more complex use cases?

By combining OAuth 2.0 with dynamic authorization, you can leverage Attribute Based Access Control (ABAC) to separate the concerns of API protection, authentication, authorization and delegation and achieve the finer grained access that has become necessary.  With ABAC, you can access any additional context like risk score, device information, location, etc. in order to make an authorization decision before sending the result back to the API gateway for enforcement—without hard coding this logic into your APIs.

This combined approach will enable your organization to implement an end-to-end API Security model. The model is capable of protecting the privacy of customers and employees, the most business-critical transactions and the most sensitive data assets across the API channel.

While OAuth 2.0 can solve some access control challenges as applications and other services share information, not all requirements can be met. When handling complex use case scenarios or dealing with regulated data, it is oftentimes prudent to go beyond the convenience of OAuth 2.0 and complement it with the extra capabilities of an ABAC solution.


Gerry Gebel is the vice president of business development at Axiomatics. He is responsible for sales, customer support, marketing, and business development for the Americas region. In addition, he contributes to product strategy and manages partner relationships.

Before joining Axiomatics, Gerry was vice president and service director for Burton Group’s identity management practice. He covered topics such as authorization, federation, identity and access governance, user provisioning and other identify management (IAM) topics. In 2007, he facilitated the first ever XACML interoperability demonstration at the Catalyst conference.

In addition, Gerry has nearly 15 years' experience in the financial services industry including architecture development, engineering, integration, and support of Internet, distributed, and mainframe systems.

The opinions expressed in this blog are those of Gerry Gebel and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.