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.
A typical scenario goes much like this.
|OAuth2 with SAML|
- Alice (resource owner) accesses a corporate travel booking application.
- In order to log into the corporate travel application, Alice is redirected to her employer's Identity Provider to obtain a SAML Authentication Assertion.
- 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".
- 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.
- 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.
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.
Note: this post cross-posted from the OracleIDM blog.