Central Authentication Service

In Today's application architecture, any type of distributed App needs 3A support.

1. Authentication
2. Authorization
3. Auditing

Software Engineers are always called on to authenticate or authorize access to applications, systems, or apps. And if they’re not, they should be. Constantly.

The outline is roughly defined in the below 4 steps:

1. A user accesses the Audit Console with an non-authenticated request
2. The user is redirected to the CAS login server
3. After logging into the CAS, the CAS server issues a ticket for the username
4. The AuditConsole validates the ticket and loads the authenticated user from the user database

Industry Usage
There are three major standards, namely OAuth, SAML, and Open ID. Google, Amazon, Facebook, and just about any other major internet application provider supports at least one of these standards and most support all of them.

An emerging authentication technology is floating in the industry namely CAS (Central Authentication Service).

CAS is an enterprise Single Sign-On solution for web services. Single Sign-On (SSO) means a better user experience when running a multitude of web services, each with its own means of authentication. With a SSO solution, different web services may authenticate to one authorative source of trust, that the user needs to log in to, instead of requiring the end-user to log in into each separate service.

A number of out-of-the-box solutions exist to enable web services written in a specific language, or based on a framework, to use CAS. This would enable deployers to implement a SSO solution in a matter of hours.

CAS Protocol 3.0 Specification was retrieved on Jan'15. Ref: https://github.com/Jasig/cas/blob/master/cas-server-documentation/protocol/CAS-Protocol-Specification.md

Open Source licensed under Apache v2. Ref: https://github.com/Jasig/cas

In the similar line, letz catch up the other standards quickly.

SAML
OASIS started work on SAML in 2001. The common implementations use XML data passed between various subsystems to authenticate users. OpenID addresses the same problem, and experience has shown it to be a bit more scalable.

OpenID
Brad Fitzpatrick initiated OpenID in 2005, with the support for signing and strong encryption. By 2008, it had been supported by Sun Microsystems and Yahoo! for authentication and authorization.

OAuth
Blaine Cook started working on OAuth in 2006 while working on OpenID at Twitter. Designed for HTTP, OAuth uses access tokens as the basis for user authentication, a common pattern.

Enterprise Use Case
You might be little confused what to use? Answer is purely based on your application use case.

CAS centralizes authentication. If you want all your applications to ask users to login to a single server.

OpenID decentralizes authentication. If you want your application to accept users login to whatever authentication service they want.

OAuth is not about Single Sign-On. It handles authorization, which is about letting the user to control how their resources may be accessed by third-parties.

As per your application requirement & specification, the appropriate industry standard pattern/practice should be leveraged. Not other way round !!