CAS-Server:
A stand-alone central login page where the user enters their credentials (i.e. their username and password).
CAS supports the standardized SAML 1.1 protocol primarily to support attribute release to clients and single sign-out.
(a table in a SQL database, ActiveDirectory/LDAP, Google accounts, etc.) Full compatibility with the open, multi-platform CAS protocol (CAS clients are implemented for a wide range of platforms, including PHP, various Java frameworks, .NET, Zope, etc.) Multi-language localization -- RubyCAS-Server automatically detects the user's preferred language and presents the appropriate interface.
SAML : Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML authorization is a two step process and you are expected to implement support for both.
OAuth 2.0:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
Important Note :
SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don't get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.
On the other hand, with OAuth2 you can invalidate an access token on the Authorization Server, and disable it from further access to the Resource Server.
Both approaches have nice features and both will work for SSO. We have proved out both concepts in multiple languages and various kinds of applications. At the end of the day OAuth2 seems to be a better fit for our needs (since there isn't an existing SAML infrastructure in place to utilize).
OAuth2 provides a simpler and more standardized solution which covers all of our current needs and avoids the use of workarounds for interoperability with native applications.
When should I use which?
1.If your usecase involves SSO (when at least one actor or participant is an enterprise), then useSAML.
2.If your usecase involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.
3.If you need to provide access to a partner or customer application to your portal, then use SAML.
4.If your usecase requires a centralized identity source, then use SAML (Identity provider).
5.If your usecase involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate.
