February 13th, 2012

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 with 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 it 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 with it, which is essential to deciding whether or not access should be granted. A valid token is not in itself sufficient. Does the scope associated with 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 an API publisher may get this information through a BI system or ops-type console. Feeding such information into a BI system also opens up 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 mobile applications represent one of the main drivers of API consumption in the enterprise, 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.

February 3rd, 2012

New White Paper: Federated Identity & Single Sign-On Using Layer 7

Written by

Identity Federation White PaperIncreasingly, enterprise IT is characterized by SaaS, Cloud, SOA and all sorts of other technologies that bridge organizational boundaries and – consequently – identity domains. When users from various domains have diverse collections of credentials for systems spanning the extended enterprise and Cloud, management and security concerns inevitably arise.

Identity federation is the key to addressing these concerns. A lot of people assume identity federation is the same thing as Single Sign-On (SSO), where a single identity is used to authenticate a user across multiple services, applications and platforms. In fact, SSO is just one piece of the identity federation puzzle, albeit an important one.

Our new white paper, Federated Identity & Single Sign-On Using Layer 7, examines all the key pieces of this puzzle. It takes a detailed overview of the technologies that can be used to merge separate “identity silos” into a centralized, authoritative identity store (SAML, STS, OAuth etc.) It also explains how our products can be used to implement these technologies.

For more information, read Federated Identity & Single Sign-On Using Layer 7

January 30th, 2012

Your One-Stop Shop for OAuth Tutorials

OAuth TutorialsThe ongoing explosion in the amount of online information generated by enterprises has created a need for open, distributed access – a way to get at online content that doesn’t require private user credentials to flow freely over the Internet. The OAuth specification has rapidly emerged as the key standard that enables this kind of delegated access.

At Layer 7, we’ve responded with the creation of our OAuth Toolkit, as well as a series of tutorial videos that explain how enterprises can use the Toolkit to simplify OAuth implementation. Now, in response to the overwhelmingly positive response we’ve received to these tutorials, we’ve decided to give them their own section on our Web site.

This section features all of Francois Lascelles’ popular OAuth 2.0 with Layer 7 Gateways series, with expanded notes and commentary. It also includes one or two of my own tutorials. Over time we’ll be adding demonstrations of how Layer 7 enables connectivity to commonly used OAuth implementations at various social and business networks, including Twitter and LinkedIn.

January 23rd, 2012

OAuth Tutorial: Modifying a Layer 7 OAuth 1.0a Implementation to Support Custom Requirements

Written by

Modifying OAuth for Custom RequirementsLast week, I posted a video tutorial demonstrating how Layer 7’s OAuth Toolkit makes it possible to use a SecureSpan or CloudSpan Gateway as an OAuth 1.0/1.0a Server and Client. Today, I’m going to follow that up with a tutorial on how a Layer 7 OAuth implementation can be modified to support custom requirements.

The tutorial demonstrates this thorough the addition of a new parameter, which is extracted from transaction metadata and then used to tweak the implementation. Specifically, I create a policy in which the authorization token’s lifespan is shortened if the user comes in from the browser of a mobile device.

The scenarios I’ve presented in these tutorials represent the two biggest strengths of the OAuth Toolkit – adherence to the specification when you need it and flexibility when you need that.  Our customers have taught us that every OAuth implementation is slightly different and our aim is to give them the tools they need to adapt.

January 16th, 2012

New OAuth Tutorial: Using Layer 7 as an OAuth 1.0/1.0a Server & Client

Written by

Using Layer 7 as an OAuth 1.0 ServerFrom a technical perspective, rapid adoption of the OAuth standard has resulted in something of a moving target. As the specification evolves, one company may implement OAuth 1.0a, another 2.0, while a third might go with OAuth WRAP. In addition, vague requirements in the spec often result in incompatible implementations, even of the same version.

My colleague Francois Lascelles recently launched a series of tutorial videos demonstrating how Layer 7’s OAuth Toolkit allows enterprises to use OAuth 2.0 to create some really interesting, powerful interaction scenarios.  However, the OAuth 2.0 specification isn’t 100% stable yet, so a real-world implementation must also be able to deal with 1.0a and OAuth WRAP.

For this reason, I’ve come up with a couple of additional tutorials that will demonstrate how our solution can be customized to meet changing requirements. My first tutorial, below, demonstrates a sample application using OAuth 1.0a, which exposes an interface that allows consuming applications to request access tokens and enables users to authorize those apps.

Watch this space for my second video, which will demonstrate how the OAuth Toolkit can be used to customize your implementation.