SAML vs federated login with OAuth

Question

What's the difference between SAML and federated login with OAuth? Which solution makes more sense, if a company wants to use a third-party webapp, and but also wants single sign-on and be the authentication authority?

Answer 1

They solve different problems.

SAML is a set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication.

OAuth is more about delegating access to something. You are basically allowing someone to "act" as you. Its most commonly used to grant access api's that can do something on your behalf.

They are two completely different things.

---

Some examples that might help out.

OAuth think of an twitter. Lets say you are using Google Buzz and Twitter, and you want to write an app to be able to keep the two synchronised. You basically can establish trust between your app and twitter. First time you go to link the app to twitter, you do the classic prompt to log into twitter, and then that confirmation box pops up and asks "Would you like to grant access to «your app name»?" once you click "yes", the trust has been established, and now your app can act as you on Twitter. It can read your posts, as well as make new ones.

SAML - For SAML think of some type of "agreement" between two unrelated membership systems. In our case we can use US Airways and Hertz. There is no shared set of credentials that can take you from one site to another, but lets say Hertz wants to offer a "deal" to US Airways. (Granted I know this is an extreme example, but bear with me). After buying a flight, they will offer a free rental car to its Chairman members. US Airways and Hertz would setup some form of trust, and some way to identify the user. In our case our "federated id" would be the email address, and it would be a one way set of trust Hertz trusts that US Airways identity provider will deliver a token that is accurate and in a secure manner. After booking the flight US Airways identity provider would generate a token and populate how they have authenticated the user, as well as "attributes" about the person in our case the most important attribute would be his status level in US Airways. Once the token has been populated it passes it via some type of reference, or encoded in a url and once we get to Hertz, it looks at the token, validates it and now can allow for the free rental car.

The problem with this SAML example is it's only one specialized use case out of many. SAML is a standard and there are almost too many ways that you can implement it.

---

Alternatively, if you dont care about authorization, you could almost argue that asserting authentication via SAML and OpenID.

Answer 2

Have a look at this simple explanation summarized here:

Many people are confused about the differences between SAML, OpenID and OAuth, but it’s actually very simple. Although there is some overlap, here is a very simple way of distinguishing between the three.

OpenID – single sign-on for consumers

SAML – single sign-on for enterprise users

OAuth – API authorization between applications

For folks comfortable with OO design patterns, I think there's a nice corollary to wrapper patterns. Think of Facade, Decorator and Proxy patterns. Fundamentally these are all the same, they're just wrappers... The difference is the intention of each pattern.

Similarly, SAML, OAuth and OpenID all facilitate different intentions via a common underlying mechanism, which is redirection to a service provider/identity authority for some private interaction, followed by redirection to the originating third party app.

Looking around on the net you will find overlap between the protocols' capabilities. Authentication via OAuth is perfectly reasonable. SSO over OAuth may not make a lot of sense though as SAML and OpenID are specifically geared towards federated identity.

To the question itself, in a corporate context SAML sounds more appropriate than OAuth for SSO. I'd bet if you look at the third party apps you'd like to integrate with your corporate identities, you'll find they're already designed to integrate with SAML/LDAP/Radius etc. IMO OAuth is more appropriate for Internet interaction between applications or perhaps applications comprising a Service Oriented Architecture in a large corporate environment.

Authorization rules may be specified in a corporate environment in other ways too. LDAP is a common tool for this. Organizing users into groups and associating application privileges against group membership is a widespread approach. Just so happens LDAP can be used for authentication too. Active Directory is a great example, though I prefer OpenLDAP.