SSO with CAS or OAuth?

security oauth single-sign-on cas

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

Example Scenario:

A User tries to access a protected resource, but is not authenticated. The application redirects the user to the SSO server. If beeing authenticated the user gets a token from the SSO server. The SSO redirects to the original application. The original application checks the token against the SSO server. If the token is ok, access will be allowed and the application knows of the user id. 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.

Single sign-out is an anti-feature. All of the user studies I'm aware of that have covered it have indicated that it's anywhere from mildly to extremely confusing to novice and power users alike. I personally have to use a system that makes use of single sign-out on a daily basis, and I find it incredibly irritating. It's almost never the behavior I want.

Don't agree that single sign-out is an antifeature. It all depends on the applications in question. For web applications that somehow relate to eachother, i.e. google mail and google calendar, it makes sense that if you loggout explicitly out of one, that you logout of the other. In cases with apps where there is no apparent "relationship", I do agree with Bob.

Note that this question was originally asked before OAuth 2.0 had been introduced, so the information related to OAuth may no longer be correct.

tetsuo

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).

Although OAuth is mainly about authorization, it can be used as if its a central authentication server. Like the way Google OAuth account is used by many sites (including SO) for authentication, without actually using any service from the OAuth provider.

Moreover, as said in Bertl reply CAS now provides OAuth both as client or server.

Is this answer still relevant now that OAuth 2.0 exists? How has your opinion changed with OAuth 2.0?

OAuth 2.0 is still an authorization protocol and not an authentication protocol but one can build on top of OAuth 2.0 to create an authentication protocol, which is what Facebook/LinkedIn etc. have done; the only standardized extension of OAuth 2.0 that provides authentication is OpenID Connect, which is the designated successor of OpenID

@Whimusical This answer was written some time ago, so I wasn't thinking about microservices yet. The context then was about multiple web applications using a single server to authenticate the user, not internal microservices. I don't currently have enough knowledge to recommend anything about that, sorry.

Lance Weber

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).

OpenID is an authentication protocol, OAuth is an authorization protocol.

Bob Aman

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.

redben

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.

Bertl

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

For people viewing this and maybe confused, the CAS mentioned here is the CAS server instead of the CAS protocol .

SSO with CAS or OAuth?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US