Connecting authentik to OpenProject sign-in
If your team runs OpenProject and wants people to sign in through authentik instead of local accounts, the supported method is OpenID Connect. The OpenID Connect provider on the OpenProject side is an OpenProject Enterprise add-on, so the license must be in place before the connection can work. Separately, OpenProject needs a first name and a last name for each user as distinct values, which means you must create a custom property mapping in authentik that sends both fields as OIDC claims. Plan that mapping as part of the build, not as a later fix, because accounts created at first login will otherwise lack the name fields OpenProject expects.
authentik provides the identity side: the OAuth2/OIDC provider and application that OpenProject registers against, the user store where passwords, multi-factor settings and account status live, and the claims that carry identity and group membership to OpenProject at sign-in. OpenProject still manages the application itself: its local roles and permissions, project memberships, work packages, and whether a given account is active inside OpenProject. Group-based project access is the decision that needs the most care. Confirm which authentik groups should map to which OpenProject roles, and check in your own test environment how OpenProject handles group claims on the Enterprise edition you license, since the integration guide is the authority on what the claim contains. Keep local administrator access available during testing so a misconfigured provider cannot lock everyone out.
Before you start, confirm the OpenProject version you run against the authentik OpenProject integration guide, and confirm the Enterprise plan tier that includes OpenID Connect with your OpenProject account team. Write down which user attributes OpenProject will store, who owns the authentik application and mapping, and how existing local accounts will be matched to incoming identities. Those answers drive the rest of the build, including the sequence of provider, property mapping and group configuration covered in the sections that follow.
What you need before configuring OpenProject SSO
OpenProject SSO with authentik depends on a licensed OpenProject edition, a supported release line, a database that meets OpenProject's requirements, a supported authentik release and trusted HTTPS between the two. Confirm each item before you create the OpenID Connect provider, because a gap in any one of them tends to surface as a failed sign-in later.
OpenProject Enterprise add-on
OpenID Connect providers are an OpenProject Enterprise add-on, not part of the Community edition. Confirm with OpenProject that your subscription includes OIDC single sign-on before you plan the integration, and ask which edition and user count the quote covers. The Enterprise add-on is licensed separately from the free Community edition, so the cost of this step recurs with your subscription, not with the authentik side.
Supported OpenProject release
Plan against the 17.9.x line, which is the latest listed in the release facts, and check the release notes for the patch you deploy. Pin the exact version in your deployment files so an unplanned update does not change the OIDC settings under you. Review the notes for each target release before you upgrade OpenProject or authentik.
Packaged or Docker installation
Docker is the recommended installation method. Packaged .deb or .rpm installs are also supported on specific Linux distributions, including Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Decide which method your team operates before you start, because the file paths and service restarts for the OIDC settings differ between them.
PostgreSQL 16 or later
OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Confirm that your database server can install these extensions and that the OpenProject database user has the rights to create them. Check the extension setup before first start, since a missing extension blocks the installation rather than the sign-in.
Supported authentik release
The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines receiving security fixes. Run one of these and confirm the exact patch level in your authentik instance, since the OpenProject guide was written against the current authentik provider screens. Upgrade authentik sequentially, following its upgrade rules, before you add the OpenProject application.
HTTPS and an administrator on each side
Both systems need HTTPS addresses with certificates that the other side trusts, including any internal certificate authority, because OIDC redirects and token calls fail on untrusted certificates. Name one administrator for authentik and one for OpenProject, with the rights to change providers, application settings and user attributes. Agree on who owns the redirect URI and the client secret.
How to configure the authentik OpenID provider for OpenProject
This sequence produces a working OpenID Connect sign-in from authentik to OpenProject, with first and last names passed through and sign-in limited to the group that should have access.
Create the OAuth2/OIDC provider in authentik
An administrator in authentik creates an OAuth2/OIDC provider and an application that points to it, then enters the redirect URI given in the authentik OpenProject integration guide. Use the exact redirect URI from that guide, matched to your OpenProject hostname over HTTPS, because a mismatch is the most common cause of a failed login. Record the client ID, client secret and the issuer URL shown on the provider page. The step is complete when the provider saves without error and the issuer URL resolves in a browser to a discovery document.
Add the first and last name property mapping
OpenProject needs first and last names as separate values, so the integration guide calls for a custom property mapping in authentik that sends given name and family name claims from the user's attributes. Create the mapping, attach it to the provider's scope or property mappings, and confirm that the scope list includes the openid, profile and email scopes OpenProject will request. The step is complete when a test user's token, inspected in the authentik provider preview or with a token decoding tool, contains separate given_name and family_name values.
Bind the group or policy that controls access
Bind the application to the authentik group or policy that defines who may sign in to OpenProject, so that only intended users reach the login. Decide with the OpenProject project owners which group maps to which project role, because OpenProject role assignment is handled on the OpenProject side and authentik only decides who may authenticate. Confirm that a user outside the bound group is denied at the authentik application page. The step is complete when one user inside the group is allowed and one user outside it is refused.
Enable OpenID Connect in OpenProject
OpenID Connect providers are an OpenProject Enterprise add-on, so confirm that an Enterprise license is active on the instance before continuing. In the OpenProject administration settings for authentication, add an OpenID Connect provider and enter the issuer URL, client ID and client secret from the authentik provider. Keep the secret out of shared notes and restrict who can view the administration page. The step is complete when OpenProject shows the new provider as available on its sign-in page without a configuration error.
Test sign-in with a non-admin account
Sign out of OpenProject, then sign in through the authentik button using a standard user account that is inside the bound group and has no OpenProject administrator rights. Check that the account is created or matched, that the first and last name display correctly on the user profile, and that the user sees only the projects granted to their role. The step is complete when this account signs in end to end and its profile matches the authentik values.
Inspect claims and record the working configuration
If any value is wrong, decode the ID token from the authentik login flow and compare the claims with the names OpenProject expects, correcting the property mapping rather than changing OpenProject's user model. Test a denied user again to confirm that the access rule still holds after any change. Store the final issuer, redirect URI and mapping names in your configuration record so that the setup can be repeated after an OpenProject or authentik upgrade. The step is complete when a repeat test with both users gives the expected result and the record is saved.
How the sign-in and claim flow works
OpenProject signs users in through the OpenID Connect authorization code flow, with authentik as the identity provider. The browser is sent from OpenProject to authentik's authorization endpoint, where the user authenticates and consents. authentik then redirects the browser back to the OpenProject callback URL with a short-lived authorization code. OpenProject's server exchanges that code directly with authentik's token endpoint for an ID token, and then reads the claims it needs to create or match a local account. The browser never sees the tokens, so the back-channel exchange and the client secret are where a misconfiguration usually shows up first. Confirm the exact callback path, scopes and client authentication method in the current OpenProject OIDC documentation for your release before you register the provider in authentik.
Because OpenProject stores first and last names as separate fields, it needs two distinct claims from the ID token or user info response, typically mapped to given_name and family_name. The standard openid scope returns the subject identifier, while profile details such as names come from the profile scope. In authentik, a custom scope mapping is what places those values into the token, and the OpenProject guide in the integrations catalog calls for this custom property mapping. Check the claim names OpenProject expects against the release you run, and decode a test ID token to confirm both values are present before you enable sign-in for users.
A missing given name or family name is a hard failure, not a cosmetic gap. If either claim is absent or empty, OpenProject cannot complete the account it would create, so the user lands on an unfinished registration instead of a working session. This tends to surface only for users whose directory records lack a surname or given name, or for service and test accounts, so test with a representative sample of real user records. Plan the property mapping as part of the build, and agree with your identity team who owns the source attributes when a name is blank in the directory.
Mapping authentik attributes to OpenProject user fields
This table compares each OpenProject user field with the authentik attribute or scope that should populate it and the check that confirms the mapping works. Read it before building the OpenID Connect provider, then verify each row with a test user before enabling sign-in for everyone. Group handling is listed as a decision to confirm, because project access depends on how your OpenProject edition and mappings are set up.
| Field | authentik source | OpenProject field and check |
|---|---|---|
| Login or username | Stable user identifier from the OIDC subject or a chosen username attribute in the user record | Login name in OpenProject. Check that signing in twice with the same test account lands on the same OpenProject user and creates no duplicate. |
| Email attribute, released through the email scope | Email address on the OpenProject user. Check that the address matches the test user's authentik record and that notifications reach it. | |
| First name | Custom property mapping that writes the given name claim from the user's given name attribute | First name field, which OpenProject requires as a separate value. Check that the name shows correctly on a work package author after first login. |
| Last name | Custom property mapping that writes the family name claim from the user's family name attribute | Last name field, required separately from the first name. Check that a blank or missing family name is caught in testing rather than left empty in production. |
| Group claim for project access | Groups scope with a group claim, passed through a property mapping that you define and confirm | Decision to confirm. Confirm with OpenProject documentation for your edition whether groups are read at login or synchronized, and which OpenProject role each authentik group should receive. Test one user per group before rollout. |
| Enterprise add-on status | Not an authentik setting, but the provider only works when the OpenProject instance has the Enterprise add-on | Check that the OpenID Connect option appears in OpenProject administration. If it does not, confirm the add-on is active before debugging the mapping. |
Giving project access through groups
Decide early which mechanism will carry group membership from authentik into OpenProject, because the choice determines what you can design. The first question is whether your OpenProject edition accepts group information from the OpenID Connect sign-in at all, or whether group synchronization is only available through LDAP. The OpenProject pricing page lists LDAP group synchronization as an Enterprise feature, so confirm with OpenProject which mechanism your edition and license support before you build a group model around it. Keep this check on your pre-build list, next to the Enterprise add-on requirement for OpenID Connect providers.
Sign-in and project authorization are separate decisions, and treating them as one causes most access problems. Signing in tells OpenProject who the user is. Project roles, such as the role a user holds on a given project or in a given group, are assigned inside OpenProject. In authentik, the group that a user belongs to can be made available to the application as a claim on the token, and an application or policy binding can restrict who may reach OpenProject at all. Neither step grants a project role by itself. Write down which authentik groups, if any, are meant to change OpenProject roles, and which are only used to permit sign-in.
LDAP group synchronization and OIDC group claims differ in how they behave over time. A claim is read at sign-in, so a user who is removed from a group in authentik keeps the old role until their session or token refreshes, and a group that exists only in authentik does not create anything in OpenProject. Synchronized LDAP groups are pulled on a schedule and can create and maintain memberships without the user signing in. Test the removal case on a non-production instance: remove a test user from a group, sign in again, and check the project memberships that remain. Record the result, the sync or token timing you observed, and who owns the cleanup of stale roles.
Hardening the OpenProject sign-in path
Signing in to OpenProject through authentik puts two systems on the critical path for every user. The cards below cover the controls that keep that path narrow: how the OIDC secret is stored, who can reach the application, how MFA is enforced, how administrators get back in, and how authentik's own release policy affects your patch plan.
Client secret storage
The OIDC client secret shared between the authentik provider and OpenProject must live in a secrets store or an environment file with restricted read access, never in a shared configuration file or a ticket. Plan a rotation step on both sides, since changing the secret in authentik without updating OpenProject breaks sign-in for every user at once. Confirm in your own environment who can read the OpenProject container configuration, because anyone with that access can impersonate the application.
Restricting access by group
Bind the authentik application to a dedicated group or policy so that only users who should reach OpenProject can start the flow. Without this binding, any authentik user may be able to authenticate to the application and be created in OpenProject on first login. Check the binding by signing in with a test account outside the group and confirming the attempt is refused before go-live.
Enforcing MFA in authentik
Attach an authenticator validation stage to the authentication flow that serves OpenProject, so second factors are checked by authentik before the OIDC token is issued. OpenProject itself does not know whether the user passed MFA, so the control lives entirely in the identity provider. Test the enforcement with a user who has no enrolled factor to confirm the flow prompts for enrollment or refuses access as your policy requires.
Break-glass local administrator
Keep at least one local OpenProject administrator account that does not depend on authentik, and record where its credentials are held and who may use them. If the authentik provider, its database or the OIDC configuration fails, this account is the only way to repair OpenProject without restoring from backup. Test the break-glass login on a schedule and log each use, since the account is a privileged path that bypasses the central controls.
Exact redirect URIs
Register the OpenProject callback URL in the authentik provider exactly as OpenProject generates it, including scheme, host, port and path, and avoid wildcards. A mismatch causes login failures, and an overly broad redirect list can allow tokens to be returned to an unintended location. Compare the value in both systems after any change to the public hostname or reverse proxy.
authentik release lines and notice
The authentik security policy lists 2026.5.x and 2026.8.x as the supported release lines receiving security fixes, and the project announces security releases at least 24 hours in advance. Assign an owner to watch that notice and schedule the authentik patch window, since a sign-in component that falls off a supported line stops receiving fixes. Confirm your upgrade path before a security release lands, because the 24-hour window is short for a change that involves a database migration.
Why OpenProject SSO login fails and how to fix it
This table lists the failures most often seen when OpenProject is wired to authentik over OpenID Connect, with the likely cause and the fix for each. Read it by matching the symptom your users or logs show to a row, then checking the cause column on both the OpenProject and authentik sides before changing settings. Most failures trace back to a licensing gap, a mismatched callback URL or issuer, or a missing name claim.
| Symptom | Likely cause | Fix |
|---|---|---|
| OpenID Connect option missing in OpenProject | The OpenProject instance does not have an Enterprise add-on covering OpenID Connect providers, so the option is not offered. | Confirm the Enterprise add-on is installed and active for the instance, then reload administration settings. Ask OpenProject GmbH to confirm the plan covers OIDC before rollout. |
| Redirect error or invalid callback after clicking sign-in | The redirect URI registered in the authentik provider does not exactly match the callback URL OpenProject sends, often due to http versus https or a trailing slash. | Copy the callback URL shown in the OpenProject OIDC settings into the authentik provider's redirect URIs exactly, then retry from a fresh browser session. |
| Login succeeds but the account is incomplete or shows blank name fields | authentik did not send separate first and last name claims, so OpenProject has no values to store for the user. | Add a custom property mapping in authentik that emits given_name and family_name from the user record, bind it to the provider's scopes, and have affected users sign in again. |
| Token validation fails with an issuer mismatch | The issuer URL configured in OpenProject differs from the issuer in the authentik provider, such as a different slug, host or path. | Copy the issuer from the authentik provider's OpenID configuration and paste it into OpenProject without edits. Check that the public hostname matches what OpenProject resolves. |
| Token or certificate errors, or logins rejected intermittently | Clock skew between the OpenProject host, the authentik server or the browser, or a TLS certificate the OpenProject host does not trust. | Synchronize time on all hosts with NTP, confirm the authentik certificate chain is trusted by the OpenProject container or host, and retest. |
| Users sign in but see no projects or work | Users were created through SSO without project roles, and group-based access was not configured in OpenProject or passed through the token. | Map the authentik group claim to OpenProject groups, assign project roles to those groups, and confirm the user is a member of the intended authentik group before the next login. |
Questions buyers ask before configuring OpenProject with authentik
How much does OpenProject Enterprise cost for SSO with authentik?
OpenProject Enterprise on-premises is priced per named user per month, and OpenID Connect sign-in is part of the Enterprise add-on, so the license is the main recurring cost on the OpenProject side. According to OpenProject's pricing page, Basic is 5.95 euros and Professional is 10.95 euros per user per month with a 25-user minimum. Premium is 15.95 euros per user per month with a 100-user minimum, and Corporate is quoted on request for 250 or more users. Confirm current figures on the OpenProject pricing page before you budget, because the tier you need depends on your user count and whether you also need LDAP group synchronization or custom branding, which are also Enterprise features.
Do we need a paid authentik edition to sign in to OpenProject?
No. The OpenProject side is what requires the Enterprise add-on for OpenID Connect, and the authentik integration uses the OpenID Connect provider type that authentik documents for generic OAuth2/OIDC applications. authentik's Open Source edition is free and is the edition this integration is built around. The authentik Enterprise license covers code in the enterprise directory and adds features such as Google Workspace and Microsoft Entra ID integrations, which you only need if those systems are part of the same project. Check the authentik pricing page to confirm which features fall under each edition before you decide.
What drives the effort of an OpenProject and authentik SSO setup?
The effort depends on how much of the identity model you need to map, not on the sign-in step itself. The main drivers are the number of OpenProject groups that will control project access, whether those groups come from authentik or from an existing directory, and whether you already run authentik with TLS and a reverse proxy. The first and last name requirement adds a custom property mapping in authentik, because OpenProject needs both names as separate attributes. Other drivers include how many OpenProject instances you run, whether you use Docker or a packaged install, and whether your PostgreSQL version meets OpenProject's current requirements.
How long does the OpenProject and authentik integration take?
The duration depends on scope, so ask for a timeline in the written scope rather than relying on a general figure. A single-instance sign-in with a test group and one property mapping is a much smaller job than a multi-group project access model that must be tested against several teams. Plan time for three activities: configuring the provider and application in authentik, setting the OpenID Connect and mapping values in OpenProject, and testing with real user accounts in a staging instance. Time for change control and a cutover window also depends on how many users are already signed in with local accounts.
Can our internal team set up OpenProject SSO with authentik on its own?
Yes, a team that already runs authentik and OpenProject can do the configuration, provided it has someone comfortable with OpenID Connect claims, reverse proxy settings and OpenProject administration. The authentik integration guide covers the provider settings and the custom property mapping for first and last names. Teams without that background usually spend the most time on claim mapping and group-based access, where a wrong claim name silently gives users the wrong project roles. A useful test is whether your team can explain every claim OpenProject receives and reproduce a failed login in a non-production instance.
What do we need to provide before the work starts?
Ask the partner for a written list before work begins. Typically you need administrator access to the authentik instance to create the provider, application, property mapping and groups, and administrator access to OpenProject to enable the Enterprise OIDC settings and map groups. You also need a test group of named users who can sign in during validation, a staging or test OpenProject instance if one exists, the public URLs and TLS certificates for both systems, and a named owner who approves the group-to-role model. Confirm these items during scoping so they do not delay the build.
What breaks most often when OpenProject signs in through authentik?
Most failures come from mismatched redirect URIs, incorrect issuer or client settings, and missing first or last name claims. If a user signs in but has no name, the property mapping has not reached OpenProject, which usually makes the account incomplete. Group-based access fails quietly when group claims are not included in the token or when group names differ between the two systems. Test each path with a user from every target group, and check the authentik event log and OpenProject logs together to confirm that the same claim reaches both sides.
Does the OpenProject Community edition support SSO with authentik?
Not for OpenID Connect sign-in. According to OpenProject's pricing page, the Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support, while OpenID Connect providers are an Enterprise add-on. If your requirement is only shared email and password sign-in, the Community edition may be enough, but any plan to centralize sign-in and project access through authentik needs the Enterprise license. Confirm the exact feature list with OpenProject before you decide, since feature tiers can change between releases.
How DeployOpen scopes and delivers this integration
DeployOpen scopes the authentik and OpenProject sign-in integration in writing before any configuration starts. The written scope names the deliverables, which typically cover the authentik OpenID Connect provider and application for OpenProject, the first and last name property mappings, the group claim and the group-to-project access model, and the OpenProject OIDC settings. Because OpenID Connect providers are an OpenProject Enterprise add-on, the scope also needs to state which OpenProject edition and how many named users it covers, so the quote reflects the license you actually need. Ask for the scope document to list each deliverable, the environment it lands in, and what you must supply, such as DNS names, TLS certificates and a decision on whether local OpenProject logins stay enabled as a fallback.
DeployOpen configures both systems inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. Work is carried out in a staging copy first, then moved to production under a change window you approve. Sign-in and group access are tested with your administrators and a small set of pilot users: a successful login, correct first and last names on the OpenProject user record, a user in the right group seeing only the intended projects, and a user outside the group being refused. Ask how test accounts are created and removed, and who signs off each test case, so the handover record shows what was verified and by whom.
After go-live, you can keep the integration current through an ongoing support or upgrade retainer. That covers reviewing authentik and OpenProject release notes when new versions are published, testing the sign-in path before upgrades, and fixing issues with the claim mapping or group sync after changes on either side. Confirm with DeployOpen how upgrade windows, response expectations and out-of-scope work are defined in the retainer agreement before you sign. DeployOpen is a Chainscore Labs company, and it implements and supports self-hosted open-source platforms, so the work is scoped to your environment rather than delivered as a hosted service.
