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.
4 comments:
Great article!
Just a question about how the new SAML assertions get generated.
I understand that the corporate travel application has access to a SAML assertion from back when Alice first logged in. However I believe that you are saying that that assertion can't be exchanged directly for an access token - instead, a new assertion has to be generated.
This sounds like pretty heavy lifting for a simple web application, given how complex SAML is. Am I understanding this correctly? Would the corporate travel app rely on the services of some other (expensive) piece of identity software to do this? Or is it a lot simpler than I am thinking?
Andrew,
Remember that there are two modes. When you have a user who wants to log in via the browser, then normal federation is fine.
OAuth 2.0 is really for the case where a client wants to act on the user's behalf. OAuth supports SAML in two ways, the client obtains a SAML authorization through some means (outside of OAuth) and exchanges it for an access token. The act of exchanging the authorization for an access token is required because during that process the client SHOULD authenticate itself.
The second way SAML can be used in OAuth 2.0 is a client can use a SAML Authn assertion as its method to authenticate to the token server.
That said, it looks like the new JSON based versions of SAML called JWT's are going to quickly replace SAML. So the underlying SAML tech is there, they are just formed in JSON rather than XML.
Hey Phil,
JWT! 3 days of googling the world of identity and I've never ran across it. Thanks for the heads up!
The reason for the questions is I'm trying to understand how to best handle our use case.
We have a "sea of resource servers" that have all been approved by a corporate admin person, i.e. they're all trusted.
The user experience we are seeking is that the end user SSOs into a web app (using SAML), and after that, the web app is able to make (OAuth-protected) API calls to any of the resource servers. In my simplistic worldview, this should be seamless, since (a) the user has been authenticated using SAML, and (b) all of the resource servers are trusted.
So (again, in my simplistic worldview), the actual mechanics of how this would happen are that the the client (i.e. the web app) would keep the SAML assertion that it got at login time. Then, whenever it wanted to make an API call to a resource server (say, resource server A), and it found it did not have an access token for that resource server, it would exchange the SAML assertion from login for an access token valid for that resource server.
Some time later on, when the web app needed to call an API at resource server B, it would do the same thing, still using the SAML assertion it received at SSO login time, but this time receiving an access token valid for resource server B.
However I am starting to understand that this is not how the SAML assertion bearer for OAuth works.
That SAML assertion seems to have "special" requirements (like the need for a specific "Audience" section), and so I don't think that the web app could just reuse the same SAML assertion that it received at SSO login time.
Hence a question - how would my web app exchange the SAML assertion that it got at login time for the SAML assertion needed to obtain an OAuth access token to a resource server?
Depending on how you set your policy, the web app could use the sso token from the user agent plus its client credential to obtain an access token scoped for the resource from the oauth token server. The idea is to be able to track what apps were workinf on behalf of whom.
Post a Comment