SAML vs federated login with OAuth

AuthenticationOauthSaml

Authentication Problem Overview


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?

Authentication Solutions


Solution 1 - Authentication

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.

Solution 2 - Authentication

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.

Solution 3 - Authentication

Found Good article here

enter image description 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.

Solution 4 - Authentication

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

Solution 5 - Authentication

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:

https://stackoverflow.com/questions/1087031/whats-the-difference-between-openid-and-oauth

Solution 6 - Authentication

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?

Solution 7 - Authentication

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionChung WuView Question on Stackoverflow
Solution 1 - AuthenticationNixView Answer on Stackoverflow
Solution 2 - AuthenticationquickshiftinView Answer on Stackoverflow
Solution 3 - Authenticationpk_codeView Answer on Stackoverflow
Solution 4 - AuthenticationyudisView Answer on Stackoverflow
Solution 5 - Authenticationmakerofthings7View Answer on Stackoverflow
Solution 6 - AuthenticationLCJView Answer on Stackoverflow
Solution 7 - AuthenticationJake miyazakiView Answer on Stackoverflow