How authentik signs users into Nextcloud
The choice of protocol decides what authentik can send to Nextcloud and whether Nextcloud can still encrypt its files on the server side. authentik provides OAuth2/OIDC, SAML and LDAP, and Nextcloud documents OpenID Connect, SAML and LDAP user authentication, so all three paths are possible. Before choosing, a team should decide which attributes, groups and quotas must reach Nextcloud at login, because those values are carried by scope mappings on the OIDC or SAML side and by attribute mapping on the LDAP side. Confirm the exact claims your Nextcloud release can consume in its authentication backend documentation before you design the mappings in authentik.
The most consequential constraint is server-side encryption. Nextcloud's encryption of files at rest depends on the server being able to hold the user's credentials at login, and the LDAP user backend is the path the team should verify for that case before committing. Treat this as a hard requirement to test rather than an assumption: build a small test with the chosen protocol, enable encryption on a non-production instance, and confirm that users can log in, read and write files, and recover access after a password change. Ask Nextcloud or your own encryption admins to confirm the current requirements for the release you plan to run.
Plan the Nextcloud version against its published lifecycle before the integration is built. Nextcloud 35 was released on 16 September 2026 and is supported until September 2027, Nextcloud 34 until June 2027 and Nextcloud 33 until February 2027, while Nextcloud 36 is scheduled for 17 February 2027. Because Nextcloud does not allow skipping major releases, the SSO configuration must survive each one-step upgrade, so keep a documented login fallback and a tested backup before every change to the authentication setup.
What you need before connecting Nextcloud to authentik
Connecting Nextcloud to authentik touches two platforms, two sets of certificates and at least one privileged account on each side. Settle the versions and naming first, because the protocol choice and the Nextcloud app set both depend on them.
authentik deployment and edition
Confirm you are running the Open Source edition, which is free and under the MIT license for most of the code, or an Enterprise subscription if you need features such as the Entra ID or Google Workspace providers. Pin to a supported release line, 2026.5.x or 2026.8.x, and check the security policy for the current window. For a single-host test or small production setup, Docker Compose is the documented path. For cluster-based hosting, use the Helm chart and a separately managed PostgreSQL, since the bundled database is intended for demonstration and testing.
Nextcloud release and runtime versions
Nextcloud 35 is the current major release and recommends MariaDB 11.8 or PostgreSQL 18, PHP 8.5 with 8.3 and 8.4 also supported, and Apache 2.4 or nginx with php-fpm. Choose the release line first, because Nextcloud does not allow skipping major versions during upgrades and each major is supported for one year. Confirm the Nextcloud version you will run against the system requirements page before building the authentik side, so the database and PHP pairing is fixed early.
DNS names and TLS certificates
Plan two externally resolvable names, one for the authentik issuer and one for the Nextcloud instance, and issue valid certificates for both. The OIDC or SAML redirect URIs and the issuer URL must match these names exactly, including scheme and path, so a mismatch shows up as a failed login rather than a clear error. Confirm that Nextcloud can reach the authentik discovery endpoint over TLS from its own network, and that any internal certificate authority is trusted by the Nextcloud host.
Administrator accounts on each side
You need an authentik administrator who can create providers, applications, property mappings and groups, and a Nextcloud administrator who can edit user authentication settings and install apps. Keep the Nextcloud admin account local and separate from the SSO path so you can recover if the identity provider is unavailable. Record who holds each role before work starts, because changes to scope mappings and group claims are made on both sides and need someone who can test them.
Directory service account for LDAP
Use this card only if you choose LDAP, either as the authentication backend or as the source for users and groups. Create a read-only bind account in authentik or in the upstream directory with the rights to read the user and group subtrees Nextcloud needs, and record the base DN, the user and group filters, and whether LDAPS is available. Do not reuse a personal administrator account for the bind, because password changes and lockouts will then affect Nextcloud silently.
Nextcloud app availability check
Before choosing an authentication method, confirm in your target Nextcloud release that the apps you need are installed and compatible: the LDAP user and group backend, and any OpenID Connect or SAML login app you plan to use. Third-party apps can lag behind a new major release, and the upgrade process requires disabling them until they are confirmed compatible. Record the app versions you have verified against Nextcloud 35 so the integration does not depend on an assumption about app support.
Choosing OIDC, SAML or LDAP for Nextcloud
OIDC is the protocol to start with when your Nextcloud deployment does not need LDAP-backed features. On the authentik side, you create an OAuth2/OIDC provider and bind it to a Nextcloud application. Nextcloud consumes the login through an OpenID Connect user authentication backend, which Nextcloud documents as an option alongside LDAP and SAML. Authentik sends standard claims such as the subject, email and name, and scope mappings can add custom claims for quota and group membership.
- Provider type: OAuth2/OIDC provider in authentik, with a client ID, client secret and redirect URI copied from Nextcloud.
- Nextcloud component: The OpenID Connect user backend, installed and configured through the apps and admin settings for your version.
- Claims carried: Subject, email and name by default, plus any custom claims you add through scope mappings for groups and quota.
- Where it fits: Browser and sync client sign-in where users do not need directory-backed user records inside Nextcloud.
- Limit to check: Whether group and quota claims are honored by your Nextcloud release and the app you use.
Confirm in the Nextcloud documentation for your exact version which OIDC backend options and claim handling are supported before you commit to this path.
SAML fits organizations whose identity standards already rely on SAML assertions and signed metadata. In authentik, you create a SAML provider that issues assertions for the Nextcloud application, exchanging metadata and signing certificates with the Nextcloud side. Nextcloud consumes the assertions through a SAML user authentication backend. Attributes such as the user identifier, email and group names travel inside the assertion, so attribute mapping in authentik determines what Nextcloud receives.
- Provider type: SAML provider in authentik, with metadata, signing certificate and attribute mappings configured per application.
- Nextcloud component: The SAML user authentication backend, installed as an app and configured with the identity provider metadata.
- Attributes carried: The NameID plus mapped attributes for email, display name and group membership.
- Where it fits: Environments that standardize on SAML across several applications and want one federation pattern.
- Operational cost: Certificate rotation and metadata refresh become recurring tasks that someone must own.
Verify the SAML backend's availability, supported attributes and any tier requirements for your Nextcloud version in the official documentation before you plan the build.
LDAP is the path when server-side encryption is required. Nextcloud's LDAP app lets directory users appear inside Nextcloud and log in with their directory credentials, and it reads user and group records from the directory directly. In this model authentik acts as the LDAP directory through its LDAP provider, so Nextcloud binds with a service account and resolves users and groups from the authentik side. That directory-backed record is what allows the server to hold the per-user key material that server-side encryption depends on.
- Provider type: LDAP provider in authentik, bound to a service account with search rights for users and groups.
- Nextcloud component: The LDAP user and group backend app, configured with host, base DN, filters and the bind account.
- Attributes carried: Distinguished name, user identifier, email, display name and group memberships exposed by the LDAP provider.
- Where it fits: Deployments that require server-side encryption, or that need Nextcloud to resolve users from a directory.
- Secure transport: Use LDAPS or StartTLS so bind credentials are not sent in clear text.
Confirm the LDAP app's configuration keys and encryption behavior for your Nextcloud version with the Nextcloud LDAP documentation before you choose this option.
Configuration sequence for authentik and Nextcloud
This sequence connects Nextcloud to authentik over one protocol, proves a single login works, then adds quota and group mappings and a tested fallback path for administrators. Each step closes with a check you can run before moving on.
Choose the protocol and create the authentik provider
The identity team creates an OAuth2/OIDC or SAML provider in authentik and attaches it to a new application for Nextcloud. Choose one protocol for the production path, since the LDAP route changes how users and passwords are stored in Nextcloud and should be a deliberate decision, especially if server-side encryption depends on it. Record the client ID, client secret or signing certificate, and the issuer or metadata location that authentik generates. The step is done when the application appears in authentik's application list and the provider shows the expected redirect or ACS values.
Set redirect URIs, ACS and issuer values
The Nextcloud administrator and the identity engineer agree on the exact public address of the Nextcloud instance, including the scheme and any path prefix. For OIDC, the redirect URI registered in authentik must match the callback address Nextcloud uses. For SAML, the ACS URL, entity ID and certificate must match what the Nextcloud SAML backend expects. Any mismatch here causes login loops or rejected assertions, so compare the values character by character. The step is done when the authentik provider values and the Nextcloud settings are recorded side by side and match.
Configure the Nextcloud authentication backend
The Nextcloud administrator installs and enables the app for the chosen backend, then enters the issuer or metadata values, client credentials or certificates, and claim names from the authentik provider. Keep the default local administrator account active and do not remove it until the fallback step is tested. Save the configuration and review the Nextcloud administration log for configuration errors. The step is done when the Nextcloud login page offers the authentik sign-in option.
Test sign-in with one account
Create or select one test user in authentik who is a member of no special groups, then sign in to Nextcloud from a clean browser session or a private window. Confirm that authentik prompts for credentials, redirects back to Nextcloud, and creates a Nextcloud account whose username and display name match the expected attributes. Check the Nextcloud log if the redirect fails. The step is done when the test user reaches the Nextcloud files page without using a local password.
Map quota and group claims
The identity engineer adds a scope mapping or property mapping in authentik that emits the quota value and group names into the token or assertion, then checks the claim names against the Nextcloud backend settings. Keep group names stable and avoid mapping every authentik group, so Nextcloud only reads the groups it uses for access or quota decisions. Sign in again with the test user and inspect the token or SAML assertion to confirm the claims are present. The step is done when the claim is visible in the token or assertion and the test user's group membership appears in Nextcloud.
Verify quota and group behavior for a second account
Use a second test account with a different group and quota value to confirm that Nextcloud applies the mapping per user rather than one shared setting. Review the Nextcloud user list and the quota shown in user settings for both accounts. Remove the test accounts or mark them for cleanup after the check. The step is done when both accounts show the expected group and quota values, and a change to one account in authentik flows into Nextcloud on the next login.
Enable and test the direct login fallback
The Nextcloud administrator confirms that a local administrator account can sign in directly at the standard login page, without going through authentik. Document who holds that account, where its credentials are stored, and the procedure for using it during an authentik outage. Test the fallback from a clean session while authentik is still running, then review whether the procedure works when authentik is unreachable. The step is done when the fallback login succeeds and the access procedure is written down and approved by the owners of both systems.
Why server-side encryption can force LDAP
The decision to use LDAP for this integration often comes down to how Nextcloud handles server-side encryption, not to a preference for directories. Server-side encryption keys are derived and stored for each user, and the way Nextcloud obtains the user's credential at login affects whether the encryption keys can be unlocked. In the configuration this topic covers, LDAP is the path that keeps the user's directory password as the login credential, which is the case the topic calls out. Before you design around OIDC or SAML, confirm in the current Nextcloud server documentation for your release, including the Nextcloud LDAP user authentication guide, whether the encryption module you plan to enable requires a password-based login for key access.
The trade-off is between directory-based login and token-based SSO. With LDAP, Nextcloud validates passwords against the directory on each login, users appear from the directory, and password change, lockout and group rules stay with your identity team. You accept that Nextcloud still handles a password, that clients and apps may need app passwords, and that MFA is enforced in authentik or upstream rather than uniformly across every client. With OIDC or SAML, authentik handles the password and second factor, and Nextcloud receives a token or assertion, which is the cleaner model for MFA and session control. If encryption requires the password, the token model may not be usable for those accounts without losing key access.
Make this decision early and record it, because switching login backends later changes how existing users authenticate and can affect encrypted data. Ask your Nextcloud partner or the Nextcloud support channel to confirm whether your chosen encryption mode requires the user's password at login, and test key access with a pilot group using the exact authentik flow and Nextcloud release you plan to run. Also confirm your target release from the Nextcloud release schedule, since encryption behavior can change between major versions.
Mapping authentik attributes, groups and quotas to Nextcloud
This table compares each identity attribute authentik sends to Nextcloud with the Nextcloud field it fills and the method used to set it. Read it per protocol: OIDC and SAML use claims and assertions from scope or property mappings, while LDAP reads directory attributes directly. The main takeaway is that quota values and group names must match what Nextcloud expects, and that group changes only reach Nextcloud at the next login or sync.
| authentik source | Nextcloud target | How the mapping is set | What to verify |
|---|---|---|---|
| User identifier (preferred username or UID) | Nextcloud user ID | OIDC: the subject or preferred_username claim from a scope mapping. SAML: the NameID or a chosen attribute. LDAP: the uid or sAMAccountName attribute in the LDAP user settings. | Confirm the same user logs in and keeps existing files. Changing the identifier later can create a second account. |
| Display name | Display name field | OIDC: the name claim in a scope mapping. SAML: a displayName attribute in a property mapping. LDAP: the displayName attribute mapping in Nextcloud's LDAP settings. | Check the name appears on the user's profile and in sharing dialogs after a fresh login. |
| Email address | Email field and share notifications | OIDC: the email claim in a scope mapping. SAML: an email attribute in a property mapping. LDAP: the mail attribute in the LDAP settings. | Confirm the address is populated for every test user, since notifications and some recovery paths depend on it. |
| Group membership | Nextcloud groups | OIDC: a groups claim from a scope mapping that lists group names. SAML: a group attribute statement. LDAP: group filters and membership attributes in Nextcloud's LDAP group settings. | Group names must match exactly, including case, what Nextcloud expects. Test that a group added in authentik appears after the next login or LDAP sync. |
| Quota | Nextcloud user quota | Typically a custom claim or attribute carrying a quota value such as 5 GB, applied by a Nextcloud user backend or group quota setting. Confirm the exact mechanism for your Nextcloud version. | Quota strings must use a unit format Nextcloud accepts. Verify the value on a test user's personal settings page after login. |
| Admin group | Nextcloud admin group membership | Mapped from a dedicated authentik group through the same groups claim or attribute. Nextcloud grants admin rights to members of the admin group. | Restrict who belongs to the authentik admin group. Confirm a non-member cannot reach the admin settings page. |
| Group changes after removal | Nextcloud group and quota state | Removed memberships are applied at the next login (OIDC or SAML) or the next LDAP background sync, not instantly. | Remove a test user from a group in authentik, then confirm the change after their next login or sync and document the observed delay. |
Securing the Nextcloud and authentik connection
A Nextcloud sign-in through authentik passes credentials, tokens and directory data between two systems, and each hop needs its own controls. The cards below cover transport and trust, who may reach Nextcloud, the admin fallback login, the directory bind account and the audit trail. Check each one in both systems before users depend on the connection.
TLS and issuer trust
Serve Nextcloud, authentik and the LDAP endpoint, if used, over TLS with certificates that Nextcloud's host trusts. For OIDC or SAML, the Nextcloud OIDC or SAML settings must match authentik's issuer URL and metadata exactly, and a certificate change on either side breaks sign-in until both are updated. Test the trust chain from the Nextcloud server itself, not from a workstation, because the server is the party making the back-channel calls. Confirm how and when you will rotate the SAML signing certificate.
Restricting access by authentik group
Bind the Nextcloud application in authentik to a policy or group binding so that only the intended population can start a sign-in. Users outside that group should be refused at authentik, before Nextcloud creates or updates an account. Review the bindings whenever a team moves in or out of scope, because a group that is never removed keeps its access. Document the group names so auditors can match them to the approved user population.
Keeping a separately managed admin login
Keep a local Nextcloud administrator account for recovery when authentik or the identity link is unavailable. Store its password outside the directory, give it a long unique secret, and require a second factor on it. Restrict who knows the credential and log every use. Test the fallback before go-live, since the first time anyone needs it should not be during an outage.
Least-privilege LDAP service account
If Nextcloud reads users through LDAP, the bind account only needs read access to the user and group subtrees and the attributes Nextcloud maps, such as quota and group attributes. It should not be a domain administrator or a member of groups that grant write rights. Limit its logon rights, set a rotation process, and confirm which LDAP-compatible source authentik is configured against. Verify that the account cannot change passwords or group memberships.
Logging events in both systems
Record sign-in successes and failures in authentik and the Nextcloud data directory's log, and decide where each log is kept and for how long. Correlate them by username and time so an investigation can follow one session across both systems. Enhanced audit logging is listed among authentik's enterprise-only features, so confirm against the edition you buy whether it is available to you or whether you rely on standard logs and forwarding.
Common Nextcloud and authentik login failures
This table pairs the failures most often seen when Nextcloud and authentik are joined, with the likely cause and the fix for each. Use it as a first pass during testing, and check the log named in each row before changing settings, since several symptoms look alike from the browser.
| Symptom | Likely cause | Fix and where to confirm |
|---|---|---|
| Redirect error after authentik login, with a 400 or invalid redirect message | The redirect URI registered in the authentik OAuth2/OIDC or SAML provider does not match the callback URL Nextcloud sends, including scheme, host or trailing path | Copy the callback URL from the Nextcloud OIDC or SAML settings exactly into the authentik provider. Confirm the value in the authentik provider settings and the Nextcloud web server access log |
| SAML login loops back to the Nextcloud login page | The ACS URL or entity ID in the authentik SAML provider differs from what the Nextcloud SAML backend expects | Align the ACS URL and entity ID on both sides and re-export the IdP metadata. Confirm in the Nextcloud log under the user_saml app |
| Nextcloud rejects the OIDC token or reports an issuer mismatch | The issuer or discovery (well-known) URL configured in Nextcloud does not match the issuer that authentik publishes, often because of a different host name or missing path segment | Use the issuer and discovery URL shown on the authentik provider page, with the same scheme and host as the public address. Confirm in the Nextcloud data/nextcloud.log |
| Tokens or SAML assertions are rejected as not yet valid or expired | Clock skew between the Nextcloud host, the authentik server containers and the database host, which shifts the iat, nbf or NotOnOrAfter checks | Synchronize time with NTP on every host and container host, then retry. Confirm by comparing timestamps in the authentik event log with the Nextcloud log |
| Users are created in Nextcloud but belong to no groups, or quota stays at default | The authentik scope mapping does not send the groups or quota attribute, or the Nextcloud group and quota claim names do not match the mapping output | Check the claim name in the authentik scope mapping, then match it to the group and quota attribute set in Nextcloud. Confirm by inspecting the claims in the authentik user preview and the Nextcloud log at login |
| Quota is not applied to a user who logs in | The mapping name or claim key differs from the one Nextcloud reads, so the value is ignored without an error | Compare the exact key string on both sides, including case, and test with a test user in a non-production group. Confirm with the user's storage quota in the Nextcloud admin user list |
| LDAP bind fails, users cannot log in, or the directory sync finds no users | The service account DN or password is wrong, the account is disabled or lacks read rights on the base DN, or the Nextcloud LDAP host and port do not match authentik's LDAP outpost | Test the bind with the service account, confirm the base DN and search filter, and check the authentik outpost and LDAP provider settings. Confirm in the Nextcloud LDAP connection test and the authentik outpost logs |
| Users locked out after local login is disabled | The direct login fallback was turned off before the SSO path was verified, so no admin or service account can sign in when authentik is unavailable | Keep one break-glass local admin account and test it before disabling fallback. Confirm the setting in the Nextcloud user_oidc or user_saml configuration and in the admin account list |
Questions buyers ask before connecting Nextcloud to authentik
What drives the cost of connecting Nextcloud to authentik?
The cost follows the written scope, and the main drivers are the protocol you choose, the number of groups and quota rules to map, whether LDAP or server-side encryption is required, how many Nextcloud instances are involved, and how much testing is expected. Each of these adds configuration, verification and documentation work. Some costs are one-time, such as design, build and testing, while others recur, such as maintaining mappings and handling upgrades. DeployOpen does not publish a price list, so ask for a quote built from a written scope that lists each of these drivers separately.
Which protocol should we use for Nextcloud and authentik?
The choice depends on what Nextcloud needs to do beyond the browser login. OpenID Connect and SAML are both documented Nextcloud user authentication backends, so either can sign users in through authentik. LDAP is different because Nextcloud's LDAP app lets directory users appear in Nextcloud and log in with their directory credentials, which matters when your users already live in a directory. Server-side encryption is the case where LDAP is typically required, so confirm that requirement early. Document the decision with your security and identity teams before configuration begins.
How long does a Nextcloud and authentik connection take?
The duration depends on scope, not on a fixed figure. The main variables are the protocol, the number of groups and quota rules, whether LDAP sync or encryption needs to be designed, the number of Nextcloud instances, the testing scope and the time your team needs for access approvals and test users. A narrow single-instance login project with one protocol will move faster than a multi-instance build with group-based quotas and directory sync. Ask for a timeline as part of the written scope rather than relying on a general estimate.
Can our internal team connect Nextcloud to authentik without a partner?
Yes, an internal team can do this if it has the skills to cover the work. You will need people who understand authentik providers, applications and scope mappings, people who can administer Nextcloud and its configuration files, and people who understand your directory and certificate setup. Someone must also own upgrades for both products and run the verification steps. Teams without this mix often underestimate the testing and the upgrade path, so assess your skills against that list before deciding to build in-house or engage a partner.
What do we need to provide before the integration starts?
Prepare the inputs that the build depends on before work begins. Typical items include read access to the directory if LDAP is in scope, a DNS name for each Nextcloud and authentik endpoint, valid certificates for those names, administrator accounts on both systems, and a set of test users covering each group and quota rule. Confirm who approves changes to production and where the configuration will be stored. Missing inputs are a common cause of delays, so list them in the scope document with named owners.
Is the authentik open-source edition enough for a Nextcloud integration?
The core Nextcloud connection can be built with the open-source edition of authentik. The pricing page lists Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support as enterprise-only features. None of these is a required step to sign users into Nextcloud over OIDC, SAML or LDAP. Check your own requirements, such as audit logging or directory provisioning, against the authentik pricing page before you finalize the design, since your needs may differ.
What changes when we upgrade authentik or Nextcloud?
Each product has its own upgrade path, and the two must be planned together. Nextcloud does not allow skipping major releases, so administrators must move one major version at a time, back up before every upgrade and disable third-party apps until they are confirmed compatible. On the authentik side, check the release notes for breaking changes and confirm which versions receive security fixes under its security policy. Retest the login flow, scope mappings and group-based quotas after every upgrade of either product, and confirm that your support window covers the versions you run.
How DeployOpen scopes and delivers the Nextcloud SSO integration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including the authentik and Nextcloud sign-in path. Engagements start from a written scope that fixes what is connected, what is tested and what the team receives at handover.
How we scope
- Confirm the Nextcloud version, hosting model and whether Nextcloud Enterprise is in use before any design work.
- Agree the protocol (OIDC, SAML or LDAP), the authentik provider type and the users and groups in scope.
- Record in writing which quota, group and fallback login decisions the integration must support.
How we build
- Configure the authentik provider, application and scope mappings, then wire Nextcloud to them in a staging instance first.
- Test first sign-in, group-driven access, quota assignment and the direct login fallback with named test accounts.
- Where server-side encryption needs LDAP, build and verify the directory connection alongside the sign-in path.
How we hand over
- Deliver configuration records, mapping documentation, test results and a runbook for changing claims or groups later.
- Walk your administrators through the login flow, troubleshooting steps and the recovery path for locked-out users.
- Document the upgrade checks to repeat when Nextcloud or authentik moves to a new release.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope is agreed in writing, including which Nextcloud and authentik releases it covers.
- Ask for the support boundaries, response expectations and change process in your quote before work starts.
