Mobile-friendly federated identity, Part 1 – The social login legacy

If I were to measure the success of a federated identity system, I would consider the following factors:

• End user experience (UX);
• How easy it is for a relying party to participate (frictionless);
• How well it meets security requirements.

 

I get easily frustrated when subjected to bad user experience regarding user login and SSO but I also recognize apps that get this right. In this first part of a series on the topic of mobile-friendly federated identity, I would like to identify winning patterns associated with the social login trend.

 

My friend Martin recently introduced me to a mobile app called Strava which tracks bike and run workouts. You start the app at the beginning of the workout, and it captures GPS data along the way – distance, speed, elevation, etc. Getting this app working on my smart phone was the easiest thing ever: download, start the app, login with facebook, ready to go. The login part was flawless; I tapped the Login with Facebook button and was redirected to my native facebook app on my smartphone from where I was able to express consent. This neat OAuth-ish handshake only required 3 taps of my thumb. If I had been redirected through a mobile browser, I would have had to type in email address and password. BTW, I don’t even know that password, it’s hidden in some encrypted file on my laptop somewhere, so at this point I move on to something else and that’s the end of the app for me. Starting such handshakes by redirecting the user through the native app is the right choice in the case of a native app relying on a social provider which also has its own native app.

Figure 1 – Create account by expressing consent on social provider native app

At this point my social identity is associated to the session that the Strava app has with the Strava API. Effectively, I have a Strava account without needing to establish a shared secret with this service. This is the part where federated identity comes in. Strava does not need to manage a shared secret with me and does not lose anything in federating my identity to a social provider. It still lets me create a profile on their service and saves data associated to me.

When I came home from my ride, I was able to get nice graphs and stats and once I accepted the fact that I have become old, fat and slow, decided to check strava.com on my laptop. Again, a friendly social login button enabled me to login in a flash and I can see the same information with a richer GUI. Of course on my laptop, I do have a session with my social provider on the same browser so this works great. The same service accessed from multiple devices each redirecting me to authenticate in the appropriate way for the device in use.

Now that we’ve established how fantastic the login user experience is, what about the effort needed on the relying party? Strava had to register an app on facebook. Once this is in place, a Strava app simply takes the user through the handshake and retrieves information about that user once the handshake is complete. In the case of facebook on an iOS device, the instructions on how to do this are available here. Even without a client library, all that would be required is implement an OAuth handshake and call an API with the resulting token to discover information about the user. There is no XML, there is no SAML, no digital signatures, and other things that would cause mobile developers to cringe.

Although a good user experience is critical to the adoption of an app, the reasons for Strava to leverage the social network for login go beyond simplifying user login. Strava also happens to rely on the social network to let users post their exploits. This in turn enhances visibility for their app and drives adoption as other users of the same social network discover Strava through these posts.

Although social login is not just about federated authentication, it creates expectations as to how federated authentication should function and what should be required to implement it. These expectations are not just from end users but also from a new breed of application developers who rely on lightweight, mobile-friendly mechanisms.

In the second part of this blog, I will illustrate how you can cater to such expectations and implement the same patterns for your own identities using standards like OAuth, OpenID Connect and the Layer 7 Gateway.

 

Public APIs, private APIs

When talking about API management, the first thing that comes to mind is a public API, one that is open for anybody to consume, provided a certain level of registration. Obviously, the most famous APIs are the public ones, potentially known to anybody. However, such APIs only represent a small subset of all APIs that need to be managed. Many APIs that we encounter in the field are setup in such a way that their consumption is restricted to a specific group of developers. This happens for various reasons. Some talk of public and private APIs, others use the terms open and closed to represent the same distinction.

Most of the time, even public APIs start off as private APIs as part of their development life cycle. Until an API has been fully tested and is ready to be launched, it remains private and only accessible to its internal developer base. The ability to “flick the switch” on an API to make it jump from a staging mode to a live mode is an essential feature of an API management infrastructure.

Then there are APIs that are never meant to be public in the first place. Most APIs fall under this category. Many enterprises that are moving forward with API management are exposing APIs that enable them to develop mobile applications for their workforce for example – think of tapping into the BYOD trend. Those APIs are intended to be consumed by their own developers, contractors and sometimes partners.

The Layer 7 API Developer Portal  is geared towards managing APIs that are either public or private and lets API managers control which developers are made aware of which APIs. This lets you have a single point of management for all APIs regardless of their target audience. By default, only public APIs are visible on the Layer 7 API Developer portal.

A series of tutorial videos for our API Developer Portal product has recently been posted to our youtube channel. One such video is How to manage a private API with the Layer 7 Developer Portal at this link.

Beyond OAuth – Emerging standards for API access control

OAuth 2.0 seems to be on everybody’s mind these days. I can’t remember an emerging standard picking up interest so fast. The Layer 7 OAuth toolkit evolved through three stages over the last couple years and I’m proud to say that I was involved right from the beginning. It was first developed out of necessity using existing elements of the Layer 7 Gateway solution – a testament to the flexibility of the platform. Then, leveraging precious feedback from numerous architects applying OAuth with our gateway, the OTK matured, became a product of its own. Today, we’re witnessing the 3^rd evolution phase: OAuth is making its way to the very core of the Layer 7 Gateway platform.

I mention these different evolution phases because I noticed how different engineers working at these different levels, and in some cases isolated from each other (I travel a lot), identified very similar patterns relating to implementing API access control using OAuth. I’m talking about interaction patterns between various components involved including for example a token issuer, an api consumer, a policy enforcement point, etc. These parties need to discover information at runtime relating to tokens and identities, tokens need to be stored somewhere and managed. It just seems logical that this information would be exchanged via open APIs themselves. Integrating these logical components via APIs means that you can easily separate them as needed and manage their mutual trust. For example, implement the OAuth protocol in a DMZ perimeter zone but store tokens and associated state in the trusted network. API based integration between these different logical components also facilitates the integration of existing IT assets into a new OAuth enabled system.

I recognize many of these patterns in emerging standards building on top of OAuth 2.0 such as OpenID Connect and User Mediated Access (UMA). Coincidence? Obviously not. I expect these emerging standards to become one of the new focuses while building the next generation API management infrastructure.

API Management Deployment Models

The CEO of competitor API Management provider Mashery recently mentioned a post I wrote discussing tradeoffs of infrastructure vs service based solutions when it comes to API management. Unintentionally, my original post has apparently hit a nerve.

Oren suggests that a “true” cloud solution can only be SaaS-based. While Amazon Web Services among others may take umbrage at that definition I am also a little confused by Oren’s statement since by most definitions Mashery is not a SaaS. Typically, a SaaS provides self-enrollment and self-service aspects. Mashery may let you manage your APIs in the cloud like Layer 7 or Apigee but it doesn’t do this without help from engagement consultants. In that way they are more akin to IBM than Salesforce.

In the end, our customers don’t get too caught up in cloud semantics. Some of our customers want to own a solution, others “rent”. Some want a solution in their datacenter, others on a public cloud. We understand that different deployment models are needed to accommodate different needs. If a cloud deployment is what you are after, try several vendors, verify what you get and compare each solution’s strenghts.

Which grant, which identities – Back from RSA

Last week, I had the pleasure of discussing REST access control patterns with Enterprise Architects and partnering technology folks. I also had the opportunity to present on this topic and one of the questions that came up afterwards was from a security architect who was unsure whether OAuth would be a good fit for some existing APIs that they have because those APIs happen to be consumed from two very different sources:

1. from the inside, by internal applications that do not act on behalf of a particular subscriber but from the provider’s perspective
2. from the outside, by applications that act on behalf of individual subscribers

OAuth 2.0 provides 4 core grant types that address different situations. In the case of the example described above, you could use the client creds grant type for the first type of access. It should be possible to permit different scopes to different client ids. The internal client ids would be allowed to request wider scopes. For the second type of consumption, the external one, any of the other 3 grant types could be applicable.

Hope to see you at RSA next year,

-fl

OAuth Token Management

Tokens are at the center of API access control in the Enterprise. Token management, the process through which the lifecycle of these tokens is governed emerges as an important aspect of Enterprise API Management.

OAuth access tokens, for example, can have a lot of session information associated to them:

• scope;
• client id;
• subscriber id;
• grant type;
• associated refresh token;
• a saml assertion or other token the oauth token was mapped from;
• how often it’s been used, from where.

While some of this information is created during OAuth handshakes, some of it continues to evolve throughout the lifespan of the token. Token management is used during handshakes to capture all relevant information pertaining to granting access to an API and makes this information available to other relevant API management components at runtime.

During runtime API access, applications present OAuth access tokens issued during a handshake. The resource server component of your API management infrastructure, the gateway controlling access to your APIs, consults the Token management system to assess whether or not the token is still valid and to retrieve information associated to it which is essential to deciding whether or not access should be granted. A valid token in itself is not sufficient, does the scope associated to it grant access to the particular API being invoked? Does the identity (sometimes identities) associated with it also grant access to the particular resource requested? The Token management system also updates the runtime token usage for later reporting and monitoring purposes.

The ability to consult live tokens is important not only to API providers but also to owners of applications to which they are assigned. A Token management system must be able to deliver live token information such as statistics to external systems. An open API based integration is necessary for maximum flexibility. For example, an application developer may access this information through an API Developer Portal whereas a API publisher may get this information through a BI system or ops type console. Feeding such information into a BI system also opens the possibility of detecting potential threats from unusual token usage (frequency, location-based, etc). Monitoring and BI around tokens therefore relates to token revocation.

As one of the main drivers of API consumption in the enterprise is mobile applications, the ability to easily revoke a token when, for example, a mobile device is lost or compromised is crucial to the enterprise. The challenge around providing token revocation for an enterprise API comes from the fact that it can be triggered from so many sources. Obviously, the API provider itself needs to be able to easily revoke any tokens if a suspicious usage is detected or if it is made aware of an application being compromised. Application providers may need the ability to revoke access from their side and, obviously, service subscribers need the ability to do so as well. The instruction to revoke a token may come from Enterprise governance solutions, developer portals, subscriber portals, etc.

Finally, the revocation information is essential at runtime. The resource server authorizing access to APIs needs to be aware of whether or not a token has been revoked.

The management of API access tokens is an essential component of Enterprise API management. This token management must integrate with other key enterprise assets, ideally through open APIs. At the same time, token data must be protected and its access secured.

API management – Infrastructure VS SaaS

The Enterprise is buzzing with API initiatives these days. APIs not only serve mobile applications, they are increasingly redefining how the enterprise does B2B and integration in general. API management as a category follows different models. On one hand, certain technology vendors offer specialized infrastructure to handle the many aspects of API management. On the other, an increasing number of SaaS vendors offer a service which you subscribe to, providing a pre-installed, hosted, basic API management system. Hybrid models are emerging, but that’s a topic for a future post.

Before opting for a pure SaaS-based API management solution offering, consider these below.

The Cloud Advantage
One can realize the benefits of cloud computing from an API management solution without losing the ability to control its underlying infrastructure. For example, IaaS solutions let you host your own API management infrastructure. Private clouds are also ideal to host API management infrastructure and provide the added benefit of running ‘closer’ to key enterprise it assets. Through any of these SaaS alternatives, an API management infrastructure optimizes computing resources utilization. IaaS and private cloud based API management infrastructure also provide elasticity and can scale on-demand. Look for API management solutions that offer a virtual appliance form factor to maximize the benefits of cloud.

Return on investment
The advantage of a lower initial investment from SaaS delivered API management solutions quickly becomes irrelevant when the ongoing cost of a per-hit billing structure increases exponentially. With your own API management infrastructure in place, you leverage an initial investment over as many APIs as you want to deliver, no matter how popular the APIs become. Many early adopters, which originally opted for the SaaS model, (notably the more successful APIs) are currently making the switch to the infrastructure model in order to remedy a monthly cost that has grown to unmanageable levels. Unfortunately, such transitions are sometimes proving more costly than any initial costs savings.

Agility, Integration
SaaS solutions provide easy-to-use system isolated in their own silo. This isolation from the rest of your enterprise IT assets creates a challenge when you attempt to integrate the API management solution with other key systems. Do you have an existing web portal? How about existing identity, business intelligence, billing systems? If your API management solution is infrastructure based, you have access to all the low level controls and tooling that are required to integrate all these systems together. Integrating your API management with existing identity infrastructure can be important to achieve runtime access control. Integrating with billing systems is crucial to monetize your APIs. Feeding metrics from an API management infrastructure into an existing BI infrastructure provides better visibility, etc.

Security
Depending on the audience for your APIs, various regulations and security standards may apply. Sensitive information travelling through a SaaS is outside of your control. Are any of your APIs potentially dealing with cardholder information? Does PCI-DSS certification matter? If so, a SaaS-based API management solution is likely to be problematic. In addition to the off-premise security issue, SaaS based API management solutions offer limited security and access control options. For example, the ability to decide which versions of OAuth you choose to implement matters if you need to cater to a specific breed of developers.

Performance
Detours increase latency. By routing API traffic through a hosted system before getting to the source of the data, you introduce detours. By contrast, if you architect an API management infrastructure in such a way that the runtime controls happen in direct path of transaction, you minimize latencies. For example, using the infrastructure approach, you can deploy everything in a DMZ. Also, by owning the infrastructure, you have complete control over the computing resources allocated to it.