Today, I found out that some of our field engineers have started getting use cases from enterprise users where OAuth is used for handling authorization to their resources. Although OAuth is an increasingly common way of authorizing access to resources hosted by an external service provider, I was wondering how long it would take for use cases to surface where the resources involved are actually controlled by the enterprise itself.
OAuth standardizes a multi-party negotiation pattern where a resource owner authorizes an application to access its resource(s) hosted by a service without sharing any credentials with this application. In version 2.0 of the OAuth specification, four roles are defined:
- Resource owner – typically the user of an application (client) that owns a resource on another service.
- Client – the application that will be accessing the resource to do something with it.
- Authorization server – the entity which receives authorization from the resource owner to let the client access its resource(s) and issues an access token for this client.
- Resource server – which lets the client access the resource, provided an appropriate access token.
OAuth fits very well within the WOA/RESTful style of architecture. After all, the focus of OAuth is the accessing of resources. Also, existing HTTP concepts are well leveraged by OAuth and tokens are transported through the standard Authorization header instead of awkward URL parameters. Note to REST purists: OAuth does involve a state at the resource authorization server and therefore violates a REST principle at that level. Although the interaction between the client and resource server is itself ‘clean’ from a REST principles perspective, the expectation is that the authorization server and the resource server roles will most often be implemented by the same entity.
OAuth 2.0 also provides additional openness and extensibility points allowing for example the use of arbitrary tokens to describe the authorization statements. For example, a SAML bearer assertion profile for OAuth binding has recently been proposed. The possibility of using SAML with OAuth creates opportunities to leverage existing enterprise infrastructure investments and raises the potential for OAuth in the enterprise in general.
Getting back to today’s use case at one of our enterprise user, our SecureSpan Gateway is used to act as the resource server, validating an incoming access token issued by another party to grant access to a resource. At the policy level, SecureSpan is configured to validate the incoming OAuth token using a specialized assertion whose properties are illustrated in the screen shot below.
Relying on enterprise gateway infrastructure to implement standards like OAuth lowers the bar for adoption. Layer 7 Technologies is committed to supporting OAuth as part of our SecureSpan Gateway and we are currently working on support for additional OAuth use cases as part of our upcoming version.
I will be very interested in monitoring the adoption of OAuth by the enterprise in the coming months. Send us your stories and use cases.