What is CAS? The Central Authentication Service, explained

CAS (Central Authentication Service) is a single sign-on protocol: users log in once at a central server, and every application that trusts that server lets them in without asking for a password again. It was created at Yale University in the early 2000s, is now maintained by the Apereo Foundation, and is still everywhere in higher education: course systems, library portals and campus intranets.

"CAS" can mean two things:

• The CAS protocol, a small, ticket-based SSO protocol over HTTP.
• Apereo CAS, the best-known open-source server that implements it (and also SAML, OIDC and more).

Other identity providers, such as Casdoor, also speak the CAS protocol, so a CAS application can sign in against them without changes.

How a CAS login works

1. A user opens an application (a CAS "service"), for example https://app.example.edu/.
2. The app has no session, so it redirects the browser to the CAS server: https://cas.example.edu/login?service=https://app.example.edu/.
3. The user logs in at the CAS server (or already has an SSO session there, so nothing is shown).
4. The CAS server redirects back to the service with a one-time service ticket: https://app.example.edu/?ticket=ST-1-abc....
5. The app calls the CAS server directly to validate the ticket: /serviceValidate?service=...&ticket=ST-1-abc....
6. The CAS server answers with XML (or JSON) containing the username, and in CAS 3.0, the user's attributes. The app creates its own session.

Service tickets are single-use and short-lived, and the app never sees the user's password.

CAS 1.0 vs 2.0 vs 3.0

There's also /samlValidate, which validates a ticket with a SAML 1.1 message, used by some older clients.

CAS vs SAML vs OIDC

If you're building something new, use OIDC. CAS matters when you have applications that already speak it, which in a university can be dozens, and you want them on the same identity provider as everything else.

CAS clients

Most stacks have a maintained client:

• Java: the Apereo Java CAS client, and Spring Security's CAS module.
• Apache httpd: mod_auth_cas, to protect any site behind Apache.
• PHP: phpCAS, used by Moodle, WordPress plugins and many campus apps.
• Python, Node.js, .NET: community libraries such as python-cas.

NGINX has no CAS module of its own. The usual setups are to put Apache with mod_auth_cas in front, or to use an auth proxy that talks to the identity provider over OIDC.

CAS servers

• Apereo CAS: Apache-2.0, Java and Spring Boot. Very complete and very configurable; you build and run your own overlay.
• Casdoor: Apache-2.0, a single Go binary with an admin console. It's a CAS server for CAS 1.0, 2.0 and 3.0 (/validate, /serviceValidate, /proxyValidate, /proxy, /p3/* and /samlValidate), and the same users also sign in over OIDC, SAML, LDAP and RADIUS. Each application gets its own CAS prefix, https://<casdoor>/cas/<organization>/<application>, and only issues tickets to the service URLs you allow.

Moving a CAS app to Casdoor is usually just changing the CAS server URL prefix in the client's configuration. If you'd rather not run the server, Casdoor Cloud is a managed instance from $24/month billed yearly.

FAQ

Is CAS the same as SAML? No. They are different protocols, although CAS servers often support both, and CAS 2.0 tickets can be validated with a SAML 1.1 message at /samlValidate.

Is CAS still used? Yes, mostly in education and in older enterprise apps. New apps should use OIDC, but a CAS-capable identity provider lets you keep the existing apps while you migrate.

Is CAS secure? Over HTTPS, with single-use, short-lived tickets and an allowlist of service URLs, yes. The most common mistake is a CAS server that issues tickets to any service URL, which lets an attacker collect tickets; Casdoor refuses services that aren't in the application's allowed list.