SSO with CAS or OAuth?

问题:

I wonder if I should use the CAS protocol or OAuth + some authentication provider for single sign-on.

Example Scenario:

1. A User tries to access a protected resource, but is not authenticated.
2. The application redirects the user to the SSO server.
3. If beeing authenticated the user gets a token from the SSO server.
4. The SSO redirects to the original application.
5. The original application checks the token against the SSO server.
6. If the token is ok, access will be allowed and the application knows of the user id.
7. The user performs a log-out and is logged out from all connected application at the same time (single sign-out).

As far as I understand that is exactly what was CAS invented for. CAS clients have to implement the CAS protocol to use the authentication service. Now I'm wondering about to use CAS or OAuth at the client (consumer) site. Is OAuth a replacement for that part of CAS? Should OAuth as a new de-facto standard be preferred? Is there an easy to use (not Sun OpenSSO!) replacement for the authentication part of CAS supporting different methods like username/password, OpenID, TLS certifactes ...?

Context:

• Different applications should rely on the authentication of the SSO server and should use something session-like.
• The applications can be GUI web applications or (REST) serivces.
• The SSO server must be provide a user id, which is necessary to get more information about the user like roles, email and so on from a central user information store.
• Single Sign-out should be possible.
• Most clients are written in Java or PHP.

I've just discovered WRAP, which could become the OAuth successor. It is a new protocol specified by Microsoft, Google and Yahoo.

Addendum

I've learned that OAuth was not designed for authentication even it could be used to implement SSO, but only together with a SSO service like OpenID.

OpenID seems to me to be the "new CAS". CAS has some features OpenID misses (like single sign-out), but it should not be to hard to add the missing parts in a particular scenario. I think OpenID has broad acceptance and it is better to integrate OpenID into applications or application servers. I know that CAS also supports OpenID, but I think CAS is dispensable with OpenID.

回答1:

OpenID is not a 'successor' or 'substitute' for CAS, they're different, in intent and in implementation.

CAS centralizes authentication. Use it if you want all your (probably internal) applications to ask users to login to a single server (all applications are configured to point to a single CAS server).

OpenID decentralizes authentication. Use it if you want your application to accept users login to whatever authentication service they want (the user provides the OpenID server address - in fact, the 'username' is the server's URL).

None of the above handle authorization (without extensions and/or customization).

OAuth handles authorization, but it is not a substitute for the traditional 'USER_ROLES table' (user access). It handles authorization for third-parties.

For example, you want your application to integrate with Twitter: a user could allow it to tweet automatically when they update their data or post new content. You want to access some third-party service or resource on behalf of a user, without getting his password (which is obviously unsecure for the user). The application asks Twitter for access, the user authorizes it (through Twitter), and then the app may have access.

So, OAuth is not about Single Sign-On (nor a substitute for the CAS protocol). It is not about you controlling what the user can access. It is about letting the user to control how their resources may be accessed by third-parties. Two very different use-cases.

To the context you described, CAS is probably the right choice.

[updated]

That said, you can implement SSO with OAuth, if you consider the identity of the user as a secured resource. This is what 'Sign up with GitHub' and the likes do, basically. Probably not the original intent of the protocol, but it can be done. If you control the OAuth server, and restrict the apps to only authenticate with it, that's SSO.

No standard way to force logout, though (CAS has this feature).

回答2:

I tend to think of it this way:

Use CAS if you control/own the user authentication system and need to support a heterogenous set of servers and apps that need centralized authentication.

Use OAuth if you want to support user authentication from systems that you don't own/support (ie Google, Facebook, etc).

回答3:

OpenID is an authentication protocol, OAuth and OAuth WRAP are authorization protocols. They can be combined with the hybrid OpenID extension.

I'd strongly prefer to see people building on top of standards that have a lot of momentum (more available support, easier to get third parties involved), even if they aren't an exact fit for the application at hand. In this case, OAuth has the momentum, not CAS. You ought to be able to do all or at least nearly all of what you need to do with OAuth. At some later point in the future, OAuth WRAP should simplify things further (it makes some worthwhile trade-offs by using a bearer token and pushing encryption down to the protocol layer), but it's still in its infancy, and in the meantime, OAuth will probably do the job just fine.

Ultimately, if you choose to use OpenID and OAuth, there are more libraries for more languages available to you and to anyone else who needs to integrate with the system. You also have a lot more eyeballs looking at the protocols, making sure they really are as secure as they're supposed to be.

回答4:

Old post, but this might be useful:

CAS 3.5 will support oAuth as Client and Server. See: https://wiki.jasig.org/display/CASUM/OAuth

回答5:

To me, the real difference between SSO and OAuth is grant, not authentication because a server that implements OAuth obviously has authentication (you have to be logged in to your google, openId or facebook for OAuth to happen with the client app)

In SSO, a power user/sysadmin grants the final user access to an application beforehand on the "SSO app" In OAuth, final user grants application access to his "data" on the "OAuth app"

I don't see why OAuth protocol couldn't be used as part of an SSO server. Just take out the grant screen from the flow and let the OAuth server lookup the grant from the backing db.