Standards Corner: Is OAuth the End of SAML? Or a New Opportunity?
By Tanu Sood-Oracle on Feb 13, 2013
Author: Phil Hunt
I mentioned in my year in review post that rather then spell the end of SAML, OAuth2 might in fact greatly expand SAML's adoption. Why is that?
The OAuth2 Working Group is nearing completion on the OAuth2 SAML Bearer draft which defines how SAML Bearer assertions can be used with OAuth2 essentially replacing less secure user-id and passwords with more secure federated assertions.
Before I describe how this works, here is some quick terminology:
* Resource Service - A service offering access to resources, some or all of which may be "owned" or "controlled by" users known as "Resource Owners".
* Resource Owner - An end user, who is authorizing delegated scoped access by a client to resources offered by a Resource Service
* Client - An application (e.g. mobile app, or web site) that wants to access resources on a Resource Service on behalf of a Resource Owner.
* Authorization Service - A service authorized to issue access tokens to Clients on behalf of a resource server.
While the resource service and the authorization service may be authenticated by means of TLS domain name certificate, both the client application and the end-user often need to be authenticated. In "classic" OAuth, you can use simple user-id's and passwords for both. The SAML2 Bearer draft describes how federated SAML assertions can be used instead.
A typical scenario goes much like this.
1. Alice (resource owner) accesses a corporate travel booking application.
2. In order to log into the corporate travel application, Alice is redirected to her employer's Identity Provider to obtain a SAML Authentication Assertion.
3. Upon logging in to the Corporate Travel Application, Alice wishes to update her seat preferences with her selected airline. In order to do this, the corporate travel application goes to the authorization server for the airline. The travel application provides two SAML authentication assertions: 1) An assertion representing the identity of the client application, and 2) an assertion representing Alice. The scope requested is "readProfile seat".
4. Upon verifying the SAML assertions and delegated authority requested, the authorization server issues an access token enabling the corporate travel application to act on behalf of Alice.
5. Upon receiving the access token, the corporate travel app is then able to access the frequent flyer account web resource by passing the token in the header of the HTTP Request. The Access token, acts as a session token that encapsulates the fact that the travel app is acting for Alice with scope read & seat update.
This SAML Bearer flow is actually very similar to the classic OAuth 3-leg flow. However instead of redirecting the user's browser to the authorization server in the first leg, the corporate travel app works with the user's IDP to obtain a delegation (or simple authentication) assertion direct from the IDP. Instead of swapping a code in the second leg, the client app now swaps a SAML Bearer assertion for the user.
OAuth2's ability to leverage different authentication systems makes it possible for SAML to enhance OAuth2 security going even further to eliminate the propagation of dreaded user-ids and passwords in much the same way SAML did for classic federate web sign-on. Rather than making SAML redundant, OAuth2 has in fact increased SAML's utility.
About the Writer:
Phil Hunt joined Oracle as part of the November 2005 acquisition of OctetString Inc. where he headed software development for what is now Oracle Virtual Directory. Since joining Oracle, Phil works as CMTS in the Identity Standards group at Oracle where he developed the Kantara Identify Governance Framework and provided significant input to JSR 351. Phil participates in several standards development organizations such as IETF and OASIS working on federation, authorization (OAuth), and provisioning (SCIM) standards. Phil blogs at www.independentid.com and a Twitter handle of @independentid.
2012: No Time to REST for the Holidays
Standards Corner: A Look at OAuth2
A Look at OAuth2 - A Follow-Up to the Reader's Comments