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?

Arcuation

It's worth noting that SSO can be achieved by storing the user's profile in a c cookie. In this case, when the user is redirected to the ID Provider, the sent cookie is used to confirm the identity, so a login prompt is not required. Here're diagrams for OAuth – alex-klaus.com/transparent-auth-gateway-2 – Threesquare

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.

Bootblack

I still don't get the difference. "grant/deny access" and "grant access to api's" sound like the same thing to me. Can you give 2 examples that are more similar, so I can see the differences? E.g. why couldn't we use SAML to establish trust between your app and Twitter? Or why couldn't you use OAuth for Hertz to tell USAirways about the special deal? – Davisson

I kind of get it, but I can always do SSO with OAuth (by requesting access to an API that provides identity). Does that mean OAuth can do everyhting SAML can and more? – Theadora

@Theadora you are almost right i.e. we can get user's identity using OAuth as well like many applications ask for login via Google, Facebook,GitHub to get the user's identity and other attributes to let them get into their applications. But it is true that we can achieve more than getting identity using OAuth. – Woolridge

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.

Doom

Link updated, however the summary which was already in the answer is the same. – Doom

OpenID is built on oAuth only. oAuth doesn't support user interface by it's own. OpenId does that for us. There is no other difference between oAuth and OpenID – Ingrown

@It'satrap not true; OpenID about authentication, OAuth is about authorization, however they share a similar (browser redirect) mechanism. Neither have much to do with a UI... See this answer as well. You can also look here. You can also re-read my answer for more clarification haha. – Doom

@Doom i am not interested in reading answers of people who lack proper knowledge and answer without verifying. For your own good, i suggest you to read this microsoft article. learn.microsoft.com/en-us/azure/active-directory/develop/… – Ingrown

I also hope that you don't believe that you know more than them – Ingrown

@It'satrap You might want to look at the OpenId Spec "authentication built on top of OAuth 2.0"; and also the OAuth 2.0 Spec "The OAuth 2.0 authorization framework"... Again, one is designed for authentication, the other for authorization. Leveraging the later for the former is OK since they share a common underlying paradigm (for the 3rd or 4th time I've said it lol). All summarized in my unchanged answer. You should learn how to read bro. – Doom

Answer 3

Found Good article here

SAML (Security Assertion Markup Language) is set of standards to achieve Single Sign On (SSO), Federation and Identity Management.

Example : A user (principal) authenticates with a flight booking website, AirFlyer (identity provider) which has SSO configured via SAML with a shuttle booking website,Shuttler (service provider). Once authenticated to Flyer, the user can book shuttles on Shuttler without requiring authentication

OAuth (Open Authorization) is a standard for authorization of resources. It does not deal with authentication.

Example : A photo sharing mobile app (OAuth consumer) that allows users import photos from their Instagram account (OAuth provider) which sends a temporary access token or key to the photo sharing app that expires after some hours.

Zajac

link provided gives 404 – Macey

Answer 4

They handle a subtle use case

• SAML - Sharing credential (e.g., SSO) of a user to various service providers (e.g., web or web service)
• OAuth - A User delegating an App to access a resource on behalf of his/her

Velarde

summarized in a short and simple way. – Poliard

Answer 5

SAML has a variety of "profiles" to choose from allow other users to "log in" to your site. SAML-P or SAML Passive is very common and fairly simple to set up. WS-Trust is similar and it too allows for federation among websites.

OAuth is designed for authorization. You can read more here:

What's the difference between OpenID and OAuth?

Brann

I struggle to understand the difference between "login" and "authorize". Can you give an example illustrating the difference? – Davisson

@TimCooper "login" is loose terminology for authentication whereas "authorize" is well authorization... An example per your request – Doom

@Doom Okay, I understand that distinction. Your answer seems to imply that SAML does authentication whereas OAuth does authorization. Is that correct? Or do they both do both - (in which case I still don't know what the difference is). – Davisson

@TimCooper The protocols have some overlapping capabilities. OAuth is targeted at authorization, but it supports authentication too. SSO in a corporate context is something SAML is purpose-built for. On the flip side, SAML supports authorization too. The context is the most important factor when deciding which technology to use. Last year I wrote an extension for Expression Engine that used SimpleSAMLPhp to authenticate users against a Kerberos backend, then lookup authorization rules from an LDAP system. It's a crazy world out there! – Doom

Answer 6

SAML is for authentication - mainly used in Single Sign On scenario. OAuth is for authorization of resource representations.

JSON Web Token (JWT) is an alternative for SAML XML Tokens. JWT can be used with OAuth

A good reference is SAML vs. OAuth: Which One Should I Use?

Fullscale

#27314576 – Fullscale

Answer 7

The terms federation really means connection identities across systems. It's related to SSO but they aren't quite the same. I Found this blog post really helpful in terms of what federation really means.

Furlough