Apereo CAS login source in authentik: setup guide

Apereo CAS as a login source in authentik: what the connection does

A university or public body running Apereo CAS often wants authentik for application single sign-on without rebuilding every login flow that already works. authentik has no native CAS protocol source, so CAS cannot talk to authentik using CAS service tickets and validation. The supported path is the OpenID Connect provider from the cas-server-support-oidc module, which must be included in the CAS deployment. With that module in place, CAS acts as an OpenID Connect identity provider that authentik consumes as an OAuth-based source, and authentik does not interpret CAS protocol messages directly. From the user's side, the change is limited to the login page. A user opening an authentik-protected application is sent to authentik, which offers the Apereo CAS source as a sign-in option. The browser then moves to the CAS login screen, where the user authenticates with existing CAS methods such as the password and any second factor CAS already enforces. CAS returns the user to authentik with an OpenID Connect response, and authentik creates or matches a local user and issues its own session for the downstream applications. Those applications still see authentik as their identity provider, so their configurations do not need to change. The decisions to settle before configuration are which CAS attributes authentik will receive, which of them become the stable user identifier, and whether CAS remains the place where credentials and MFA are enforced. Confirm with your CAS administrators that the module version and its OpenID Connect endpoints match your CAS release, and check the exact endpoint paths, client registration and claim names against the authentik Apereo CAS source documentation before you build the source. Attribute mapping choices are covered in the sections that follow.

What the CAS server and authentik need before you start

Connecting authentik to Apereo CAS depends on a CAS server that exposes OpenID Connect, a running authentik instance, open network paths between the two, and a certificate both sides trust. Confirm each of these before you configure the source, because a gap in any one shows up as a login failure that looks like a configuration error.

CAS with the OIDC module

authentik has no native CAS protocol source, so the connection runs through the OpenID Connect provider that the cas-server-support-oidc module adds to CAS. Without that module compiled into your CAS overlay, there is no OIDC endpoint for authentik to call. Confirm the exact CAS and module versions against the module's own documentation, and check that your CAS build includes the module before you plan any further work.

A running authentik instance

The source is created inside an authentik instance that already serves login for at least one test application. Confirm that you can sign in locally, that the admin account works, and that the instance runs a release still receiving security fixes. A working baseline lets you tell whether a later failure comes from the CAS connection or from authentik itself.

Network paths in both directions

The browser must reach the CAS login and OIDC endpoints, and authentik's server must reach the CAS discovery and token endpoints directly. Users are redirected through the browser, but the token exchange happens server to server, so a firewall that allows only browser traffic will pass the login page and then fail. Ask your network team to confirm outbound access from the authentik container or host to the CAS hostname.

TLS trusted by both sides

CAS and authentik must each trust the certificate the other presents. If CAS uses an internal certificate authority, add that root to the authentik server's trust store and confirm the chain is complete, including intermediates. Expired or self-signed certificates are a common cause of token exchange errors, so check validity dates and hostnames before you start.

Attributes and identifiers agreed

Decide which CAS claims will serve as the stable user identifier and which will supply email, name and group values before you map them in authentik. Confirm with the CAS administrator which attributes the OIDC module releases for your service definitions, since authentik can only map claims that CAS actually sends. Agree the identifier now, because changing it later can create duplicate accounts.

Change and rollback ownership

Name the person who owns the CAS server, the module version and the authentik source, and agree who approves changes to the service definitions and redirect URIs. Plan a way back to local authentik login if the source misbehaves. Keep a record of the client ID and secret issued for authentik so that rotating them later does not require guesswork.

Configure the CAS OIDC module and the authentik source

This sequence turns a CAS server into an OpenID Connect identity provider for authentik, then registers that provider as an OAuth source so existing CAS users can sign in to authentik. Each step ends with a check that confirms the handoff works before the next one starts.

Confirm the CAS deployment includes the OIDC module
Before changing anything, confirm that the CAS deployment includes the cas-server-support-oidc module, because authentik has no native CAS protocol source and relies on CAS acting as an OpenID Connect provider. Your CAS build and overlay ownership decide who makes this change, usually the team that already maintains the CAS war overlay. Check the module version against your CAS release using the module's own documentation, since the authentik guide does not pin a version for you. The step is done when the build artifact that will run in production contains the OIDC provider classes and you can name the CAS version it targets.
Enable and configure the OIDC module on CAS
Enable the OIDC protocol in the CAS configuration and set the issuer, which must be the public HTTPS base URL that authentik will use to reach CAS. Define a registered service for authentik with its client identifier, client secret and the exact redirect URI that authentik generates for the source, and restrict the service to the attributes you intend to release. Store the client secret in your secrets manager rather than in a plain properties file. The step is done when CAS starts cleanly with the OIDC settings applied and the registered service appears in the CAS service registry.
Register authentik as a relying party
Create the CAS service entry that represents authentik as a relying party, using the callback path that the authentik CAS source documentation specifies for your authentik hostname. Choose the scopes authentik will request, typically openid, profile and email, and confirm that CAS releases a stable unique identifier claim that will not change when a display name changes. Record the client ID and secret for the next step. The step is done when a test client with those credentials can complete an authorization request against CAS in a browser.
Check the discovery document from authentik's network
Fetch the OpenID Connect discovery document from the CAS issuer URL, normally the well-known configuration path under the issuer, using a host on the same network path that authentik's server and worker containers use. Verify that the issuer value in the document matches the issuer you configured exactly, including scheme and trailing slash, and that the authorization, token and JWKS endpoints resolve to addresses authentik can reach. Run the same request from inside the authentik server container to catch DNS, proxy or certificate trust problems. The step is done when the document returns over HTTPS with a trusted certificate and every advertised endpoint responds.
Create the OAuth source in authentik
In the authentik admin interface, create a new OAuth source under the sources area and set the provider type to a generic OpenID Connect option, since CAS is not a named provider. Enter the CAS issuer, client ID and client secret, and confirm that the endpoints autodiscovered from the well-known document match the ones you checked earlier. Set the user matching mode and enrollment behavior deliberately, because they decide whether a CAS login links to an existing authentik user or creates a new one. The step is done when the source saves without validation errors and shows the callback URL that CAS must have registered.
Map CAS attributes to authentik user fields
Open the property mappings for the source and map the CAS claims you released to authentik user attributes, starting with a stable identifier for matching, then username, email and display name. Keep the mapping limited to what the application needs, and document which CAS attribute supplies each field so the team that operates CAS can change it safely. Confirm the exact claim names with the CAS attribute release configuration rather than assuming them. The step is done when a decoded token from a test login shows the expected claim names and the mapping populates the fields you chose.
Complete a test sign-in with a non-admin account
Sign out of authentik, open the source login from the sign-in page, and authenticate with a standard CAS user who has no administrator rights in authentik. Confirm the user lands in the expected authentik account, that the attributes populated correctly, and that the account has only the access you intended. Repeat once with a second user if your CAS directory has different attribute patterns. Review the authentik event log for the login and check that no errors were recorded. The step is done when a non-admin user completes sign-in end to end and the event log shows a clean success.

Which endpoints and claims to configure, by role

The CAS administrator enables the OpenID Connect module in the CAS deployment and registers authentik as a relying party. This role decides the public issuer identifier, publishes the authorization, token, userinfo and JWKS endpoints, and controls which directory attributes appear in the tokens and userinfo response. Exact endpoint paths come from the module's own documentation and discovery output, so copy them from there rather than building them from memory.

Issuer value: Confirm the issuer identifier matches the public base URL that CAS advertises, because authentik validates the issuer in every token it receives.
Client registration: Create an OIDC client for authentik with its redirect URI, a client ID and a client secret, and limit the allowed scopes to those authentik will request.
Endpoint set: Take the authorization, token, userinfo and JWKS endpoints from the module's discovery output and pass them unchanged to the authentik administrator.
Attribute release: Map directory attributes to the subject, email and name claims, and record which attributes are withheld from authentik.
Signing keys: Plan key rotation for the JWKS signing key and notify the authentik team before any change, since a stale key set breaks token validation.

Before handing values to authentik, complete one test login against CAS and confirm the discovery document and the issued ID token show the expected issuer and claims.

How CAS attributes map to authentik user fields

This table compares each CAS-side value with the authentik field it fills, from the identifier used for correlation to the group or role claims that drive authorization. Read the rows top to bottom: the first two decide whether a returning user lands on the same account, and the rest decide what that account can reach. Confirm each claim name against what your CAS deployment actually releases to the OIDC client before you write the mapping.

CAS value	authentik field	Unique and stable?	What to confirm
Subject identifier (sub claim from the CAS OIDC provider)	Source correlation key (user matching identifier for the source)	Must be unique and stable	Confirm the CAS sub value does not change when a username is renamed or reissued
Username or uid claim, if released	authentik username	Unique, stable preferred	Decide whether to use it or the sub value, since renames in CAS can break matching
email claim	User email attribute	Unique per user, may change	Confirm the attribute is released and whether it is verified by CAS
displayName or given_name and family_name	User name attribute	Not unique, may change	Map only for display; do not use for matching or authorization
groups or roles claim (multi-valued)	authentik group membership through the source's group mapping	Stable only if CAS group names are stable	Confirm the claim name and values with your CAS administrator before mapping
Attribute released for conditional access (for example, affiliation)	Custom user attribute read by policies	Depends on the source system	Confirm release rules in the CAS service registry for the authentik client

Securing the CAS to authentik trust relationship

Once authentik trusts CAS as an OpenID Connect provider, every login passes through that relationship. The controls below cover how the client secret is kept, which redirect URIs are accepted, how traffic is protected, what identity data leaves CAS, and how accounts are matched. Each one touches the duties that apply when the records belong to students or consumers.

Store the client secret outside configuration files

The OIDC client secret lets authentik exchange authorization codes with CAS, so anyone holding it can impersonate the relying party. Keep it in a secrets manager or an environment variable managed by your platform, not in exported blueprints or version control. Rotate it when administrators with access leave, and confirm who can read the authentik source configuration in the admin interface, since that view is a common leak path.

Restrict redirect URIs to exact values

Register only the exact callback URL that authentik's CAS source uses, with the scheme, host and path spelled out. Wildcards or broad prefixes let an attacker redirect an authorization code to a host they control. Review the registered list in the CAS OIDC service definition whenever the authentik hostname changes, and remove stale entries from test or migration periods.

Enforce TLS on both endpoints

Both the CAS OpenID Connect endpoints and the authentik callback must run over HTTPS with certificates your clients trust. Check the discovery document, authorization, token and userinfo URLs that authentik fetches, because a single plain HTTP endpoint exposes tokens in transit. Confirm certificate chains are valid for internal CA issuers, and plan renewal so a lapsed certificate does not silently break sign-in.

Release only the attributes applications need

The CAS OIDC module decides which claims appear in the ID token and userinfo response. Release identifiers and the specific attributes your applications use, and leave out contact details, national identifiers or free-text fields unless a named application requires them. Map those claims in authentik's property mappings and document the purpose of each one, so a reviewer can trace why a student or customer field reaches authentik.

Choose first-login creation or account linking

Decide whether authentik creates a new user the first time someone signs in through CAS, or links that login to an account that already exists. Creating users is simpler but can produce duplicate identities when a person already has a local account. Linking needs a stable, unique identifier from CAS, and it should be tested with real duplicate cases before go-live, because a wrong match gives one person access to another person's account.

Map data handling duties to the trust design

Education records under FERPA and consumer data under GDPR or COPPA each limit who may receive personal information and how long it is kept. Record which attributes flow from CAS to authentik, who administers the source, and how access is logged. If a contractor operates the integration, confirm it works under your direct control. Ask your counsel which duties apply to your data before setting the release policy.

Common CAS login source failures and their fixes

This table lists the failures teams most often hit when connecting Apereo CAS to authentik through the cas-server-support-oidc module, with the likely cause and fix for each. Use it as a first-pass checklist, then follow the authentik Apereo CAS source documentation for the exact settings.

Failure	Likely cause	Fix
Login redirect fails with no OIDC option	The CAS deployment does not include the cas-server-support-oidc module, so CAS has no OpenID Connect provider to offer authentik.	Add the module to the CAS overlay, rebuild and redeploy CAS, then confirm the OpenID Connect endpoints are published before editing authentik.
Source cannot load CAS configuration	The discovery URL is unreachable from the authentik server or worker, often because of DNS, firewall rules, a wrong path or a CAS context path mismatch.	Request the discovery document from the authentik host itself, not your laptop. Check DNS, egress rules and the CAS base path, then correct the URL in the source settings.
Redirect URI mismatch error at CAS	The callback URL registered in CAS does not match the authentik source callback exactly, including scheme, host, port or trailing slash.	Copy the callback URL shown on the authentik source page into the CAS OIDC service definition. Compare it character by character after any hostname or proxy change.
TLS or certificate trust errors on login or discovery	authentik does not trust the certificate chain of the CAS server, often because the CAS certificate is issued by an internal certificate authority.	Install the internal root and intermediate certificates in the authentik server and worker trust store, restart both containers, and retest. Do not disable verification in production.
User creation fails after successful login	CAS does not release the attributes that authentik's property mappings expect, such as email or a username claim, so the user cannot be created.	Confirm the claims CAS releases for the service, then align the authentik attribute mapping with those names. Test with one account and review the source logs.
Duplicate accounts for returning users	The identifier mapped to the authentik user changes over time, for example a display name, email alias or a value that differs between CAS attribute releases.	Map a stable, unique identifier from CAS, such as the principal ID, and use it for matching. Clean up duplicates before enabling the source for all users.
Users locked out after source enablement	Local accounts or existing users were not linked to the CAS identity, or enrollment and authorization flows block the new source.	Review the source's user matching and enrollment settings, link existing accounts deliberately, and keep a local administrator available during rollout.
Group or role assignment missing	CAS does not release group or role attributes in the form authentik policies or group mappings expect.	Agree the group attribute name with the CAS team, add it to the release policy, and map it in authentik. Test with accounts in each group before granting access.

Questions teams ask before connecting CAS to authentik

What drives the cost of connecting Apereo CAS to authentik?

Cost is driven mostly by the CAS-side work, because authentik has no native CAS protocol source. The Apereo CAS guide in authentik's documentation uses the OpenID Connect provider from the cas-server-support-oidc module, so the CAS deployment must include that module before any authentik configuration starts. The main cost components are:

Building and testing the CAS module on your current CAS version, including any custom overlay or build changes.
Configuring the authentik source, claim mapping and enrollment behavior.
Testing each relying application that depends on CAS sign-in.

One-time work covers the initial build and test. Recurring work follows CAS and authentik upgrades, because each change to either side can affect the OIDC integration. Ask any partner for a written scope that separates these components so you can compare it with your own estimate.

How long does a CAS to authentik connection usually take?

Duration depends on how many applications sit behind CAS, how much the CAS build has been customized, and how many test cycles your change process requires. No timeline is fixed in the supplied material, so treat any number you hear as unverified until it appears in a written scope. A small CAS deployment with one test application is usually far simpler than a deployment where CAS fronts a dozen services with different attribute expectations. Ask for milestones covering the module build, a staging test with a test account, claim mapping sign-off and a cutover window agreed with application owners.

What do we need to provide before the work starts?

Before work starts, you need to provide access and inputs that the CAS side cannot be built without. Typically this includes:

Administrative access to the CAS server, its build repository and its deployment pipeline, so the OIDC module can be added and tested.
A test account in CAS with the attributes your applications expect, plus a test account in authentik for verification.
A TLS certificate for the CAS hostname and a trusted chain that authentik can validate.
A list of relying applications, their required claims, and the owners who approve cutover.

Confirm the exact certificate and network requirements with your CAS administrator, because the trust path between the two systems determines whether the connection works at all.

Can an in-house team connect CAS to authentik without a partner?

An in-house team with CAS operations experience and some OpenID Connect knowledge can usually do this work, provided it has time for testing. The skills involved are CAS build and deployment, OIDC configuration, and authentik source and property mapping. The steps are documented in authentik's Apereo CAS guide and in the module's own setup, so the work is not a research project. The usual gaps are testing across applications and handling CAS upgrades later. Partners are typically chosen when the team lacks CAS build skills, lacks capacity for a staged cutover, or wants a fixed-scope delivery with written acceptance criteria. DeployOpen works on fixed-scope engagements agreed in writing before work begins.

Does connecting CAS to authentik require a paid authentik edition?

The supplied material does not list the CAS source as an enterprise-only feature. The authentik pricing page lists three editions: Open Source (free, community Discord only), Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. The enterprise-only features named there include Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management, password history, enhanced audit logging and ticket-based support. Confirm the edition question against the current pricing page and the source documentation before you commit, because edition terms can change. Also check the license terms for any code path you plan to use, since the repository places code in the enterprise directory under a separate license.

What should we test before moving users to CAS sign-in through authentik?

Test the full sign-in path, not only the login page. Verify that the OIDC handshake completes for each relying application, that the claims authentik receives match your mapping, and that user attributes arrive in the form each application expects. Also test:

Sign-out and session expiry behavior across the CAS and authentik sessions.
Accounts that exist in CAS but have no matching authentik user, and the enrollment behavior you chose.
Failure cases, such as a CAS outage or an expired certificate, and whether users see a clear message.

Record results against a written test plan, and keep the test account in your staging environment only.

Does routing sign-in through authentik change our compliance obligations?

Adding authentik in front of CAS does not change the regulations that apply to your data, but it changes where authentication decisions and identity attributes flow, so your records should reflect that. If your institution handles student records under FERPA, for example, an outside party that receives education records as a school official must be under your direct control and follow redisclosure limits, and you must control access to records by legitimate educational interest. Your team should document the data flow, confirm who administers authentik, and keep access logs. Ask your compliance lead to review the design before cutover, and treat any contractor's access to identity data as a formal scope question.

Who maintains the CAS module after the connection goes live?

Ownership after go-live is the question most often left open. The CAS module must be rebuilt and retested whenever CAS is upgraded, and the authentik source configuration must be reviewed whenever authentik is upgraded. Agree who owns each part before cutover: the CAS team for the module and CAS upgrades, and the identity team for the authentik source and claim mapping. Recurring work such as monitoring, log review and upgrade testing is either kept in-house or covered by a support retainer, which DeployOpen offers for ongoing support and upgrades. Ask any provider to state in writing who handles each upgrade and how long rollback takes.

What changes for users and administrators after go-live

Users will see the CAS option as an additional source button on the authentik login page. Choosing it sends them to the CAS login screen, and after they authenticate, CAS redirects them back to authentik's callback endpoint before the enrollment or authentication flow completes. Users who already have an authentik account must decide whether their CAS identity should attach to it. Confirm with your CAS administrators which identifier CAS returns as the subject, and confirm with your authentik administrators how the source's user matching and enrollment settings handle an existing account with the same username or email. Settle this before go-live, because a mismatch can either create duplicate accounts or silently attach a CAS identity to the wrong person. Accounts that were created locally or from another source should be left alone unless you have decided to link them deliberately.

Administrators need to watch for two kinds of failure. The first is failed callbacks, which show up as users stuck after the CAS login or returned to the login page with an error. Review the authentik event log and the CAS server logs together, since the redirect URI registered in CAS and the callback URL configured in the authentik source must match exactly. The second is claim drift. The OpenID Connect module in CAS can change which attributes it releases, and a CAS upgrade or a change to its attribute release policy can remove or rename the claims your attribute mapping depends on. Users may then be created without an email address or lose group membership without any login error. Ask your CAS team to notify you before changing the module, the attribute release policy or the CAS version, and rerun a test login with a known account after each change.

Plan ongoing ownership before the source is in production. Name who owns the CAS client registration, the authentik source configuration and the attribute mapping, and record what each depends on. Keep a test account in CAS for regression checks after CAS or authentik upgrades, and review the authentik Apereo CAS source documentation whenever either side changes. Confirm with your CAS vendor or deployment team which module version your server runs, since the authentik guide depends on the cas-server-support-oidc module being present in that deployment.

How DeployOpen scopes and delivers a CAS source integration

DeployOpen treats the CAS source as a bounded integration: the CAS server, the cas-server-support-oidc module and the authentik OpenID Connect source are agreed in writing before work starts. The engagement then covers configuration, attribute mapping, testing and handover inside infrastructure you control.

How we scope

Confirm the CAS server version and whether the cas-server-support-oidc module is already deployed or must be added
Agree which CAS services, login flows and user populations the authentik source will serve
Record the required claims, attribute mappings and enrollment behavior in the written scope before build starts

How we build

Configure the OpenID Connect endpoints, client registration and redirect settings on the CAS side and in authentik
Map CAS attributes to authentik user properties and test first-login enrollment with representative accounts
Test sign-in, failure paths and account linking in a non-production authentik instance before changing live login

How we hand over

Document the endpoint values, client settings, attribute mappings and the reasons behind each configuration choice
Provide a runbook covering certificate rotation, client secret changes and steps to disable the CAS source
Walk your identity and CAS administrators through the configuration so they can operate the source after handover

How we support

Offer ongoing support, upgrades and testing as a retainer when your team wants continued help after handover
Review the CAS module and authentik versions during any planned upgrade, since both change independently
Agree support terms and response expectations in writing, with no SLA assumed unless it appears in the contract

Apereo CAS as a login source in authentik