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

Last week, in the second of my tutorial videos demonstrating how Layer 7 Gateways can be used to implement OAuth, I talked about the authorization code grant type and showed how it could be adapted to suit specific needs. This week, in my third tutorial, I’ll be doing the same for the implicit grant type.

As you may remember, I previously gave an overview of the flow for the authorization code grant type. To help you compare and contrast, here’s the implicit grant type flow:

• The resource owner is redirected by the client application to the OAuth authorization server, to express authorization
• The OAuth authorization server redirects the resource owner back to the client application along with an access token
• The client application uses the access token to call the service on behalf of the resource owner
• The implicit grant type does not include refresh tokens since the client application is not authenticated

The response we’ve already had to these tutorials is evidence of the ever-growing interest in all things OAuth – and the fact that there’s still a lot to learn about this emerging standard. If you’re finding this content useful – and I certainly hope you are – don’t worry: there’s plenty more to come!

Tutorial 3: The Implicit Grant Type

Last week, I introduced my new series of video tutorials designed to demonstrate how Layer 7 Gateways can be used to implement OAuth. For the second tutorial in the series, I tackle how the authorization code grant type is used and how it can be adapted to suit your own requirements.

To give you a general idea of what we’re dealing with in this tutorial, here’s a quick overview of how the authorization code grant type works:

• The resource owner is redirected by the client application to the OAuth authorization server, to express authorization (authorization endpoint)
• The OAuth authorization server redirects the resource owner back to the client application, along with an authorization code
• The client application  presents this code to the OAuth authorization server (token endpoint), along with its credentials, and gets an OAuth access token
• The client uses the access token to call the service on behalf of the resource owner (optionally the client can use a refresh token to extend the session)

For more information on the workings of the authorization grant type, watch my tutorial video below. Next week, we’ll be looking at the implicit grant type. In the mean time, for broader insight into how Layer 7’s SecureSpan and CloudSpan Gateways enable OAuth, read up on the Layer 7 OAuth Toolkit.

Tutorial 2: The Authorization Code Grant Type

OAuth is fast becoming the most widely recognized standard for access control with REST and Web APIs. And OAuth 2.0 – the latest version of the protocol – is impressively rich, with many grant types addressing many use cases (two-legged, three-legged, with or without redirection etc).

I recently launched a series of video tutorials in which I provide practical instructions on using OAuth with Layer 7’s SecureSpan and CloudSpan Gateways. Layer 7’s OAuth 2.0 template implementation provides a standard-compliant OAuth solution to which you integrate your API, identity providers, API keys and so forth.

The Layer 7 OAuth Toolkit also includes client applications for testing each grant type defined by the specification. This is very similar to what Google provides with the Google OAuth Playground. You can test the OAuth handshake and test calling an API using the access token provided by the handshake. You can also test token revocation and token refresh.

Embedded below, the first tutorial in the series – Incorporate an Existing API & Identity Provider – shows how our template allows you to leverage existing resources in an OAuth deployment.  Over the coming weeks I’ll be posting all the tutorials in the series. In the meantime, for more information on how our Gateways enable OAuth, download the OAuth Toolkit data sheet.

OAuth 2.0 with Layer 7 Gateways, Tutorial 1: Incorporate an Existing API & Identity Provider

This week’s pick from the Layer 7 Resource Library archive addresses two issues that are critical to our technologies: Web services and identity federation. One of Layer 7’s ongoing goals is to help companies realize the value Web services offer to the enterprise – and identity federation is one of the keys to Web services success.

Our white paper Identity Federation in Web Services explains exactly why federation is such an issue with Web services. It explores federation problems commonly associated with reusing application logic across diverse business processes that traverse multiple security domains with independent preferences, capabilities and requirements.

It also outlines the requirements for a solution that will simply, effectively and securely bridge application identities across security domains. Our experience with customers – along with the fact that this has consistently been one of our most downloaded resources – continues to reinforce our belief in the value this type of solution offers to today’s extended enterprise

Read the white paper: Identity Federation in Web Services >>