How authentik signs users into Jenkins with OpenID Connect
A platform team whose Jenkins controllers still rely on local accounts should know the supported method before anything else: an OAuth2/OpenID Connect provider in authentik for Jenkins, configured by following the authentik integrations guide for Jenkins. Jenkins itself does not act as an identity provider in this design. It becomes an OIDC client that sends each sign-in to authentik, receives an identity token back, and maps the user's name and group claims to Jenkins access. Jenkins is distributed under the MIT License, so the licensing question is about Jenkins itself and plugins, not about which authentik edition you run. The authentik Open Source edition covers OAuth2/OIDC providers, so this integration does not depend on the Enterprise tier.
Three components do distinct jobs. The authentik provider defines the client ID, client secret, redirect URI and the scopes and claims it issues, and it decides which users and groups reach the application through its bindings and policies. The Jenkins OIDC plugin handles the redirect, token exchange and login session on the controller. Group claims are the link between the two: if the provider does not emit the groups you plan to authorize against, Jenkins has nothing to match matrix or role-based permissions to. Confirm the exact claim name and scope values in the current authentik guide and the plugin's documentation before you write the mapping, because a mismatch shows up as users who sign in successfully but receive no permissions.
All of this runs inside your own infrastructure. The authentik server, its PostgreSQL database and the Jenkins controllers stay in your cloud accounts, data centers or air-gapped network, and the client secret and redirect URIs never leave that environment. Plan the redirect URI against the exact controller URL users will reach, including any reverse proxy hostname, because that value must match in both systems. Keep a break-glass local administrator on each controller, tested before you enable SSO, so that a misconfigured provider or an authentik outage does not lock everyone out of configuration as code and recovery work.
What you need before configuring Jenkins and authentik
The OIDC configuration is the small part of this integration. Each card below names one prerequisite that the authentik side, the Jenkins side or the network between them must meet before you change a setting. Confirm them in order, because a gap in one usually shows up later as a login failure in the other.
Supported authentik version
Confirm your authentik server is on a release line that still receives security fixes. The security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance, so plan a maintenance window for that notice. The latest release on the GitHub releases page is 2026.8.4, published October 14, 2026. Check the release notes for any change to the OAuth2/OIDC provider before you upgrade and then configure Jenkins against it.
Jenkins controller on an LTS line
Run the controller on a current long-term support release, such as 2.580.1 released September 30, 2026, rather than a weekly build. LTS lines get only backported fixes in four-week cycles, which keeps the OIDC plugin and its dependencies on a predictable baseline. Before upgrading, check the changelog for plugins that are no longer bundled, such as the SSH server, JUnit and bouncycastle API plugins, and confirm they are installed through the plugin manager.
Java runtime for the controller
Confirm which Java version the controller runs on before you install the OIDC plugin. The Jenkins support policy lists Java 21 with planned end of support in September 2027 and Java 25 with planned end of support in September 2029. Java 17 ends with LTS 2.541.3, so a controller still on Java 17 needs a runtime change first. Check the runtime version on the controller host, not on your workstation.
Network path and TLS to the issuer
The Jenkins controller must reach the authentik issuer URL over HTTPS, and the browser of every user must reach both hosts. Confirm DNS resolution, firewall rules and proxy settings from the controller itself, then confirm that the certificate chain for the authentik host is trusted by the Java truststore that Jenkins uses. A certificate from an internal CA that the JVM does not trust is one of the most common causes of discovery failures during setup.
Reserved administrator path
Before you change any authentication setting, reserve a local administrator account on Jenkins that does not depend on authentik. Store its credentials in your password manager or secret store and test that it can sign in. Keep this path until SSO and group-based authorization have been verified for at least one user in each role. Without it, a bad authorization matrix can lock every operator out of the controller.
Authentik deployment and backups
Confirm how the authentik deployment is hosted and backed up before editing the provider, because the configuration is stored in PostgreSQL. The architecture documentation describes a server container, a worker container and PostgreSQL, with PostgreSQL holding all configuration except uploaded files. Confirm that a recent database backup exists and that you know who can change the Jenkins application and its client secret in authentik.
Configuration sequence from authentik provider to Jenkins login
This sequence connects Jenkins to authentik over OpenID Connect so that a user signs in through authentik, Jenkins receives the user's groups, and an administrator can still reach Jenkins if the identity provider is unavailable. Each step ends with a check you can run before moving on.
Create the OAuth2 provider in authentik
An authentik administrator creates an OAuth2/OpenID Connect provider for Jenkins and an application that uses it, following the Jenkins guide in the authentik integrations catalog. Set the client type to confidential so that Jenkins authenticates with a client secret, and confirm the signing key and scopes the guide specifies. Record the client ID, the client secret and the issuer discovery URL in your secrets manager, not in a ticket or chat. The step is done when the provider and application appear in the authentik admin interface and the discovery URL returns the provider's OpenID configuration when opened in a browser.
Define the group claim and scope mapping
Add a property mapping or scope mapping to the provider so that the ID token or userinfo response carries the group names a Jenkins role model will use. Keep the claim name identical to the one you configure in Jenkins, and limit groups to those intended for Jenkins so that unrelated groups do not appear in the token. Ask your authentik administrator to confirm the claim name in the provider's preview, since the exact mapping depends on your directory and the authentik version you run. The step is done when a test user's preview token lists the expected groups under the chosen claim name.
Install the Jenkins OIDC plugin
A Jenkins administrator installs the OpenID Connect authentication plugin through the plugin manager, then restarts Jenkins if the plugin requests it. Before installing, check the plugin's compatibility with your Jenkins LTS line in the plugin listing, and confirm that the plugins you rely on are still present, because recent LTS releases stopped bundling several plugins. Install through the plugin manager rather than copying files onto the controller by hand, so that the plugin is tracked with your other plugins. The step is done when the plugin appears in the installed list and the security realm options in Jenkins include OpenID Connect.
Set the security realm and redirect URI
In Jenkins global security settings, select the OpenID Connect security realm and enter the issuer discovery URL, client ID and client secret recorded in the first step. Set the Jenkins root URL under system configuration to the exact public address users type into the browser, because the redirect URI Jenkins sends to authentik is built from it. Register the matching redirect URI on the authentik provider, copying the value shown by the plugin rather than typing it from memory. The step is done when Jenkins saves the configuration without an error and authentik lists the redirect URI on the provider.
Map groups to Jenkins authorization
Configure the authorization strategy in Jenkins to use the group claim as the source of roles, using the matrix or role-based settings your team has chosen. Grant the administrator group the Administer permission and give other groups only the permissions their work needs, such as Read or Build on specific jobs. Keep the mapping in a short document so that reviewers can compare it with the authentik groups. The step is done when a user in the administrator group sees the Manage Jenkins page and a user in a read-only group cannot change configuration.
Test login with a non-admin account
Sign out of Jenkins, then sign in as a standard user who is in a non-administrative group in authentik. Confirm that the login redirects to authentik, returns to Jenkins, and that the user's groups appear in the user's profile or the security log as expected. Also confirm that the user cannot reach Manage Jenkins, which proves the role mapping works in the direction you intended. The step is done when the non-admin login succeeds, the expected groups are visible, and the restricted pages return a permission error.
Confirm the administrator path before closing
Before you rely on SSO for everyday access, verify that a local administrator account or another recovery path still works if authentik or the OIDC realm fails. If you manage Jenkins with configuration as code, confirm that the configuration file keeps the local administrator setting and that secrets are read from the environment or a secrets store, not stored in plain text. Ask your team to document who can change the security realm and where the recovery credentials are kept. The step is done when a tested administrator login works with the OIDC realm disabled in a test environment, and the recovery steps are written down.
Mapping authentik groups and claims to Jenkins authorization
This table traces a user's group membership from authentik through the OIDC scopes and claims that Jenkins receives, then to the role or matrix assignment that grants access. Read each row in order, because a gap at any stage usually shows up in Jenkins as a user who signs in but sees nothing. Confirm the exact claim names and authorization plugin behavior against the Jenkins plugin versions you run.
| Stage | What to configure | What to confirm before go-live |
|---|---|---|
| Scopes requested by Jenkins | The OIDC client in authentik must allow the scopes Jenkins asks for, including the scope that returns group membership in the ID token or userinfo response. | Check the scope names in the authentik Jenkins guide and the OIDC plugin, since group data is not returned unless the scope is granted. |
| Claim carrying group names | Add or confirm a property mapping that places authentik group names in a named claim, for example a groups claim, on the provider. | Decode a test ID token or read the userinfo response to confirm the claim name and that values are group names, not internal IDs. |
| Group naming | Use stable, unique group names in authentik that match the role or matrix entries you plan to create in Jenkins. | Renaming an authentik group changes the claim value, so Jenkins assignments keyed on the old name will stop matching. |
| Users with no group | Decide whether a user with no matching group can sign in at all, gets anonymous or read-only access, or is blocked. Authentication and authorization are separate decisions. | Test with a user outside every mapped group and confirm what Jenkins shows, since the default for the OIDC plugin may not be the access you want. |
| Role or matrix assignment | Map each group claim value to a Jenkins role or matrix row, such as administrator, developer or read-only, in the authorization strategy the plugin provides. | Confirm that role-based or matrix authorization is available in your installed plugin version, as the options and labels vary by release. |
| Where assignments live | Maintain role or matrix assignments in Jenkins itself, and keep the mapping from authentik groups documented alongside the Jenkins configuration. | If assignments are managed as configuration as code, confirm the plugin supports the authorization keys you use and that changes survive a controller restart. |
| Break-glass administrator | Keep a local Jenkins administrator account, or a documented recovery procedure, that does not depend on authentik being reachable. | Test the break-glass path before cutover and store its credentials under your normal secret handling policy. |
| Ongoing review | Review group membership and Jenkins assignments on a set schedule, and after any change to authentik groups or Jenkins plugins. | Record who approves a new group-to-role mapping and where the change is logged. |
Where Jenkins plugin settings, claims and the admin path live
The authentik side holds the OAuth2/OpenID Connect provider and application that the authentik Jenkins guide walks through. The provider defines the client ID and secret, the allowed redirect URI for Jenkins's security realm callback, the signing key, the scopes, and the property mappings that decide which claims appear in the ID token or userinfo response. Group claims are built here, so the group names Jenkins later reads are whatever authentik emits. Editing a mapping or renaming a group changes what Jenkins receives on the next login, and existing sessions may keep old claims until they expire.
- Client settings: The client ID and secret must match the Jenkins plugin exactly. Rotating the secret in authentik requires a matching update in Jenkins.
- Redirect URI: It must match the Jenkins external URL, including scheme and path. A mismatch after a hostname change is a common cause of failed sign-in.
- Group claim mapping: The claim name and group values determine matrix or role authorization in Jenkins. Renaming a group in authentik can silently remove access.
- Signing key and scopes: Changes here affect token validation. Record the certificate or key reference used.
- Back up: Export the provider, application, and mapping configuration from authentik as part of your authentik backup, and note the client ID in your Jenkins records.
Before closing, confirm that a test user in each group receives the expected claim values in a token from a non-production Jenkins.
The Jenkins OpenID Connect plugin stores its settings in the controller's configuration, under $JENKINS_HOME, alongside the other plugin settings. These settings include the issuer or discovery URL, the client ID and secret, the scopes requested, the user name and group fields read from the token, and the logout behavior. The plugin settings decide how a returned token becomes a Jenkins user and which groups that user holds. Because they live on the controller, a restore from backup returns them, and a plugin upgrade should be checked for changed field names.
- Discovery URL: Points Jenkins at authentik's issuer metadata. A wrong issuer causes token validation to fail for every user.
- Client credentials: Store the secret through Jenkins credential handling rather than in plain text where your version supports it.
- User and group fields: These must name the claims defined on the authentik side. Changing them changes who is recognized as a member of which group.
- Scopes: The group scope or claim must be requested, or group-based authorization will see no groups.
- Back up: Include $JENKINS_HOME, which holds the plugin configuration and the encrypted credentials. Keep a copy of the matching master key material with that backup.
After each plugin change, test a login from a clean browser session to confirm the mapping.
Configuration as Code, the Jenkins plugin that reads YAML from the path in the CASC_JENKINS_CONFIG variable (default $JENKINS_HOME/jenkins.yaml), can define the security realm, the authorization strategy, and the OIDC settings declaratively. This is useful for repeatable builds, but it creates a second source of truth. The plugin does not install plugins, so the OIDC plugin and its dependencies must be present through your Docker image or Helm chart. The admin path is the local or break-glass account that remains usable when SSO is down, and it should be defined outside the OIDC setting so a bad SSO change cannot remove it.
- Variable and file location: Confirm which file CASC_JENKINS_CONFIG points to in the running container, since a mismatch means Jenkins starts with defaults.
- Break-glass admin: Keep a local administrator defined in the YAML or in a secret, and test it regularly.
- Plugin prerequisites: The OIDC plugin must be installed by the image or chart, not only by the YAML.
- Secrets: Reference secrets through the supported mechanisms instead of committing them to the file.
- Back up: Version the jenkins.yaml file in source control and keep the secret store entries it references. Record the CASC_JENKINS_CONFIG value in your runbook.
Confirm the exact YAML keys against your installed plugin version before relying on them.
Changes to these three components can break sign-in in different ways, so verify them in the order a user experiences them. Start with the authentik provider, confirm the token contains the expected groups, then confirm the Jenkins plugin reads those claims into the right roles, and finally confirm the break-glass path works. Because Jenkins LTS releases can stop bundling some plugins, check that the OIDC plugin is still present after each controller upgrade. Document who owns each component so a change in one place is reviewed against the others.
- Token check: Decode a test token or use authentik's preview to confirm the group claim content.
- Login check: Sign in as a user from each authorization group and confirm the expected permissions.
- Plugin presence: After upgrades, confirm the OIDC and Configuration as Code plugins are installed.
- Break-glass check: Sign in with the local admin while the SSO path is deliberately disabled in a test environment.
- Backup check: Restore $JENKINS_HOME and the CASC_JENKINS_CONFIG file into a test controller and repeat the login tests.
Record each test result with the versions of authentik, the Jenkins LTS release, and the plugins involved.
Hardening the Jenkins and authentik login path
Single sign-on moves the trust decision from Jenkins to authentik, so a weak redirect URI, an unprotected administrator account or a stale plugin can undo the gain. The cards below cover the controls that connect the two systems and the fallback path that keeps the controller reachable when authentik is down.
Client secret in Jenkins credentials
The OIDC client secret that authentik issues for Jenkins is a credential, so it belongs in the Jenkins credentials store rather than in the Configuration as Code file or a Git repository. Check that the secret is masked in logs, that only administrators can read it, and that rotation is written into your runbook. Rotating the secret in authentik and in Jenkins must happen in one change window, or every login fails at the callback.
Exact redirect URIs only
Register the callback URL that Jenkins actually uses, including scheme, host and path, as the only redirect URI on the authentik provider. Wildcard or multiple redirect entries widen the set of places an authorization code can be sent. Confirm the value against your Jenkins root URL setting, because a mismatch between the public hostname and the configured root URL is a common cause of failed sign-ins.
MFA for administrator groups
Attach an authentication flow in authentik that requires a second factor for the groups that map to Jenkins administrators. Apply it to the group or policy that decides the authorization, not only to a general login, so a user cannot reach the controller with a password alone. Test the enforcement with an account that belongs to the admin group, and confirm that a user without the group is not prompted for an unnecessary challenge.
Local break-glass administrator
Keep one local Jenkins administrator account with a long, stored password for use when authentik, its database or the network path to it is unavailable. Store the credential in a sealed location with a named owner, and record each time it is used. Test the login path on a schedule, since a break-glass account that has never been tried is often blocked by a later security change.
Limit access to the HTTP interface
The controller should accept browser and API traffic only through the reverse proxy or load balancer that terminates TLS, and not on a directly exposed port. Restrict who can reach the Jenkins URL by network path, and review the proxy headers Jenkins trusts so that client addresses and scheme are not spoofed. The Jenkins scaling guide describes the controller as handling HTTP requests and managing the build environment, which is why build agents should carry the build work instead.
Plugin updates through the LTS cycle
Plan plugin and core upgrades against the LTS release line rather than applying weekly builds on the production controller. The OIDC plugin and the Configuration as Code plugin should be updated and tested together, because a plugin change can alter how group claims are read. Recent LTS releases stopped bundling some plugins, so confirm in the changelog which plugins you must install explicitly before a core upgrade.
Common Jenkins SSO failures and how to fix them
This table lists the sign-in failures teams most often hit when wiring Jenkins to authentik over OpenID Connect, with the likely cause, the check to run and the fix for each. Work down the rows in order when a sign-in breaks, because the first checks are the cheapest to rule out.
| Failure | Likely cause | Check and fix |
|---|---|---|
| Redirect URI mismatch | The redirect URI registered in the authentik OAuth2/OIDC provider does not exactly match the Jenkins URL the browser uses, often because of a changed hostname, a missing path segment or http versus https. | Compare the Jenkins root URL in system settings with the redirect URI on the authentik provider, character for character. Correct whichever side is wrong, then retry in a private browser window. |
| Missing group claims | The provider does not include the groups scope or the group claim mapping, so Jenkins receives no group membership and falls back to default authorization. | Inspect the ID token or userinfo response for the groups claim. Add the groups scope and mapping on the authentik side, then confirm the claim name matches the field the Jenkins OIDC settings read. |
| Users locked out after a plugin change | An upgrade to a recent LTS line stopped bundling plugins the OIDC setup depends on, so the authentication path breaks after restart. | Check the Jenkins LTS changelog for the plugins removed from the bundle, then install any you rely on through the plugin manager before restarting. Keep a local admin account reachable until the login path is verified. |
| Configuration as code overwrites OIDC settings | The Configuration as Code file in the Jenkins home or CASC_JENKINS_CONFIG path sets the security realm without the OIDC values, so each restart reverts the security configuration. | Open the YAML file the controller loads and compare its securityRealm block with the working settings. Move the OIDC block into the file, keep secrets in environment variables or credentials, and reload configuration to confirm the change persists. |
| Plugin missing after configuration as code load | The Configuration as Code plugin does not install plugins, so a referenced OIDC or authorization plugin is absent and the YAML fails to apply that section. | Check the controller log for unknown configuration keys. Install the missing plugins through the plugin manager or the image or Helm definition, then reapply the file. |
| No admin able to sign in | The authorization matrix grants admin only to a group claim that is absent or misspelled, and no local administrator account remains. | Keep a break-glass local admin during rollout. Confirm the admin group name in authentik matches the Jenkins matrix entry exactly, and test with a user who belongs to that group before removing local access. |
| Wrong permissions after login | Group names differ in case or prefix between authentik and the matrix or role strategy, so users match a broader or narrower role than intended. | Compare the group names in the token with the entries in the authorization configuration. Normalize the names in authentik, then sign in with a test account from each group and confirm its effective permissions. |
| Client secret rejected | The client secret was rotated in authentik or copied with extra whitespace, so the token exchange fails after the browser redirect. | Re-copy the client secret from the authentik provider into the Jenkins credential, avoiding trailing spaces, and save. Test the login again and review the controller log for the token endpoint error. |
Questions buyers ask before connecting Jenkins to authentik
Can our own team connect Jenkins to authentik without a partner?
Yes, a team that already runs Jenkins and authentik can do the basic OIDC connection in-house, because the work is configuration rather than custom code. The authentik integrations catalog includes a Jenkins guide that configures an OAuth2/OpenID Connect provider in authentik for Jenkins, and that guide is the natural starting point. What is harder to staff is the surrounding work: group claims that drive authorization, a tested recovery admin, configuration as code that survives restarts, and a change process for plugin updates. If your team has not done those before, a fixed-scope engagement with a written list of deliverables can shorten the learning curve. Confirm the exact steps against the version of the Jenkins plugin and authentik you run.
What drives the effort of a Jenkins and authentik SSO project?
Effort rises with the number of Jenkins controllers, how many groups must map to Jenkins roles or matrix permissions, and how far your configuration is already codified. Each controller needs its own client registration, redirect URI and authorization settings, so five controllers is more than twice the verification work of one, even when the pattern is identical. Group design is often the largest variable: a flat list of groups from authentik is simpler to map than nested teams that must be translated into folder or project permissions. Configuration as code maturity matters too. If Jenkins is already defined in YAML, the security realm can be added to version control and tested. If settings were made by hand in the UI, expect time spent exporting and reconciling them. Plugin versions also change the work, because the Jenkins LTS line and bundled plugins move on a set cadence. Ask any provider to price these drivers separately in the quote.
How many controllers or a primary and backup setup change the work?
A multi-controller or primary and backup setup multiplies configuration and testing, and it adds a failover question that a single controller does not raise. The Jenkins scaling guide describes adding controllers for new teams or projects, and a primary and backup arrangement in which a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails. For SSO, the backup controller needs the same OIDC settings, the same redirect URI pattern for its hostname or proxy address, and a tested login path, or users will be locked out at exactly the moment failover matters. Session and cookie behavior behind the proxy should be verified in both directions. Ask the provider to list each controller as a separate deliverable in the written scope, including the failover test.
What does the client's team need to provide for the work?
The work needs an owner for the authentik side, an owner for the Jenkins side, and access to both during the agreed window. On authentik, the team needs someone who can create providers, applications and groups and who understands which groups should carry Jenkins permissions. On Jenkins, the team needs administrator access to the controller, a current backup of $JENKINS_HOME, and a list of plugins and plugin versions in use. The Jenkins scaling guide notes that configuration, plugins and secrets all live in that directory, so a backup is a precondition, not an afterthought. The team also needs a test group of users who can sign in and report results, and a change window where a broken login can be rolled back. Write these items into the scope so that delays caused by missing access are visible.
How do we keep a recovery admin if SSO fails?
Keep a local Jenkins administrator account that does not depend on authentik, store its credentials in your secrets manager, and test the break-glass login before the SSO change goes live. Jenkins security realms can be switched, so a bad OIDC configuration can lock out everyone, including administrators, if the local account was removed or never tested. The Configuration as Code plugin reads YAML from the location set by CASC_JENKINS_CONFIG (default $JENKINS_HOME/jenkins.yaml), which makes it possible to keep the security settings under version control and roll back a broken change by reverting a commit. Note that the plugin does not install plugins, so the plugin set must be managed separately through images or the Helm chart. Record who may use the recovery account, when it is used, and how its password rotates.
What about group claims for matrix or role-based authorization?
Group claims decide who gets which Jenkins permissions, so the mapping should be designed before any configuration is written. authentik can include group membership in the tokens it issues to Jenkins, and Jenkins authorization strategies such as matrix-based security can then grant rights to those group names. Decide early which groups correspond to read-only, build-only and administrator roles, and avoid granting administrator rights to a broad group such as all employees. Check the claim name, the group format and whether the names are stable, because renaming a group in authentik can silently remove access. Verify with a test account in each role. Confirm the exact claim settings and matrix syntax against the version of the plugin you run.
How is the cost of a Jenkins SSO engagement structured?
Most engagements are fixed-scope, so the cost follows from a written scope that lists the controllers, the group model, the configuration as code work, the testing and the handover. The main cost components are the time to design the group model, the time to configure authentik and Jenkins, the testing across roles and failover paths, and the documentation and training for your team. Those are one-time costs. Recurring costs sit elsewhere: plugin updates, Jenkins LTS upgrades, and authentik version upgrades, which you can plan as a separate scope or a retainer. DeployOpen does not publish a price list, so ask for a quote that separates one-time work from ongoing support and states what is excluded, such as new controllers added later. Also ask for the deliverables and acceptance tests in writing before work starts.
How DeployOpen scopes and delivers a Jenkins SSO integration
DeployOpen starts every Jenkins SSO engagement with a written scope that names the controllers in play, the authentik provider and application definitions, the group design that feeds Jenkins authorization, the recovery path and the test plan. Most of the cost and schedule risk sits in those decisions, so they are settled on paper before any change reaches a controller. The scope should list each Jenkins controller that will use authentik, whether a primary and backup pair sits behind a proxy as described in the Jenkins scaling guide, and which teams own which controllers. A controller added for a new team later is a separate scope item, not a quiet extension of this one.
The group design and recovery path are where DeployOpen and the client's security team spend the most review time. The written scope records which authentik groups map to Jenkins roles, who approves changes to that mapping, and how the local administrator account and the configuration as code admin path are kept working if authentik is unreachable. Testing then covers a sign-in and an authorization check for each role, a forced failure of the identity provider, and a confirmation that configuration files load after a restart. All work runs inside the client's own infrastructure and accounts, and handover includes the documented settings and runbook the client's team keeps.
DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the controllers, groups, environments and test cases to be itemized, and confirm which items are one-time and which recur. Ongoing support for authentik and Jenkins upgrades, plugin changes and periodic testing can be added as a retainer, which is priced from the scope agreed for that support. Confirm the Jenkins and authentik versions you run before requesting a quote, since upgrade planning depends on them.
