The 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.

Last 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.

From 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.

Late in 2011, we started a series of tutorials aimed at illustrating how Layer 7’s SecureSpan Gateways can be used to implement various aspects of the OAuth 2.0 specification as a means for controlling access to enterprise APIs. In this fifth OAuth-focused tutorial, we look at how you can integrate existing CA SiteMinder Single Sign-On (SSO) sessions as part of an OAuth handshake.

For situations where a service subscriber already has an SSO experience provided by CA SiteMinder, the SecureSpan Gateway can be leveraged to enable an application to consume the API on behalf of the subscriber, using OAuth. The objective is to maintain the end user’s SSO experience during the handshake while still complying with the OAuth 2.0 specification.

Tutorial 5: Leverage a CA SiteMinder Session in an OAuth 2.0 Handshake

As promised, here’s another of my weekly tutorial videos on how Layer 7’s OAuth Toolkit can be used to leverage the many grant types and use cases supported by the OAuth 2.0 standard. I’m glad to report that there has been a lot of interest in this series of videos. We get queries about OAuth just about every day, so enterprise architects clearly see this emerging standard as a potentially powerful tool for controlling access to APIs.

For those of you who haven’t seen my previous OAuth 2.0 tutorials, I should explain that the OAuth Toolkit provides a number of OAuth template implementations that can be imported into our Gateways in order to apply OAuth. This template integrates into existing environments by connecting with identity providers and APIs.

This week, I’m explaining the OAuth 2.0 SAML grant type. This grant type is defined in an OAuth extension specification (draft-ietf-oauth-saml2-bearer-09), which defines another grant type not included in the core OAuth specification. This grant type describes how a client application uses a SAML bearer assertion to obtain an OAuth access token.

Although this specification does not describe how the client application obtains the SAML assertion in the first place, the tutorial does use a test application to provide an example in which the user is forwarded to a SAML identity provider which authenticates the user, issues a SAML assertion and redirects the user back to the application. The application then uses this redirected SAML assertion to obtain an access token from the Layer 7 Gateway’s OAuth authorization server endpoint.

Tutorial 4: The SAML Grant Type