Nextcloud as an OpenID Connect identity provider: what it does and when to use it
A small organization that already runs Nextcloud for files often wants one set of accounts for the few other internal tools it uses. The community OIDC Identity Provider app lets Nextcloud issue OpenID Connect logins to other services, so people can sign in to those tools with their Nextcloud credentials. This is a trade-off. It suits a short list of internal tools and a small user base, and it is not a general identity platform, so plan for a dedicated identity provider if your needs grow.
The supported method is to install the app from the Nextcloud app store, as with other community apps on the server. Confirm that the app's version is compatible with the specific Nextcloud version you run before any work starts, and ask the same question for the version you expect to move to next. Nextcloud does not allow skipping major releases, and it asks administrators to back up before every upgrade and to disable third-party apps until they are confirmed compatible. Identity therefore becomes part of every upgrade plan, not a separate task that can be deferred.
Decide early where your user records should live. If your organization already keeps accounts in LDAP or Active Directory, Nextcloud can read them through its LDAP app, and that directory may be the better source of truth for the other tools too. If Nextcloud accounts are the only directory you have, the app fits more naturally. Next, list every service that would act as a relying party and confirm, with each vendor, that it supports OpenID Connect, which claims it expects, and how client registration is done. Do not assume these details match across tools.
Treat the Nextcloud server as a shared dependency. Once other tools rely on it for sign-in, a Nextcloud outage, a failed upgrade or a misconfigured client blocks access to all of them, not just to files. Before go-live, test the full path in a staging instance: first sign-in, token expiry, a user who has been disabled in Nextcloud, and a rotated client secret. Write down who can change identity settings and who is paged when sign-in fails. If you cannot answer those questions for your team, a dedicated identity provider is the safer choice.
When Nextcloud as an OpenID Connect identity provider fits a small organization
This option suits an organization where Nextcloud already holds the user directory, a small number of internal applications need single sign-on, and one team can operate both services. The OIDC Identity Provider app turns the Nextcloud login into an identity source for other services, so users sign in once with credentials they already use for files and collaboration.
What this typically looks like:
- User count: a workforce that fits comfortably within one Nextcloud instance, with no separate customer or partner population to manage.
- Relying applications: a short list of internal tools, each configured as a client. Every added client is another redirect URI, secret and scope set to review.
- Admin skills: the team already runs Nextcloud well, including upgrades, PHP and database maintenance, and app compatibility checks. OIDC configuration adds token lifetime, client secret rotation and claim mapping to that work.
- MFA and groups: two-factor authentication is handled by Nextcloud, and group membership is the main access control signal. Confirm that the claims your applications need, such as group names, are released exactly as they expect.
- Running cost: no second identity service to host, patch or back up. The cost is mostly the added Nextcloud change control and the time spent on client configuration.
Before committing, confirm with the vendor and your own environment how the app behaves under your Nextcloud version, and whether your MFA and group policy can be enforced for every relying application you plan to add.
A dedicated identity provider such as Keycloak, authentik or Zitadel is a separate service whose only job is authentication and identity administration. It makes more sense when the organization expects many applications, several user populations, or policy requirements that should not depend on a file-sharing platform's upgrade cycle.
What this typically looks like:
- User count: larger or more varied populations, such as employees, contractors, customers or partners, with different sign-in rules for each.
- Relying applications: a growing set of internal and external services, where one place to manage clients, scopes and sessions keeps the estate consistent.
- Admin skills: a team comfortable operating an additional stateful service, including database backups, certificate rotation, clustering and its own upgrade path. Verify which of these skills exist in-house before selecting a product.
- MFA and groups: MFA policy, conditional access and group or role mapping are designed in the identity provider and applied to every client, so the rules do not vary by application.
- Running cost: a second service to host, monitor and patch, plus the staff time to operate it. Ask any implementation partner to separate one-time setup from recurring operations in the quote.
This choice also has a migration cost later. Moving users, sessions and client registrations from one provider to another is a project of its own, so plan the identity model before the first application is connected.
Confirm your user growth, the number of applications in the next planning cycle and the skills available before choosing. The right answer depends on your own environment, and a short written scope review is the usual way to reach it.
What you need in place before configuring Nextcloud as an identity provider
Before the OIDC Identity Provider app is enabled, the Nextcloud server, its database, web stack and HTTPS endpoint need to be supported and stable. The cards below cover the server version, the platform requirements, the directory and test environment, and the people who keep the app current.
Supported Nextcloud server version
Pick a major version whose support window covers the planned life of the identity service. Nextcloud 33 is supported until February 2027, Nextcloud 34 until June 2027 and Nextcloud 35 until September 2027. Nextcloud 36 is scheduled for 17 February 2027. Choosing a version that ends support within a few months of go-live means an upgrade soon after launch, so check the dates against your own change calendar.
Database, PHP and web server
Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, with MariaDB 10.11 to 12.3, PostgreSQL 14 to 18 and MySQL 8.4 or 9.7 also supported. It recommends PHP 8.5, with 8.3 and 8.4 supported, and Apache 2.4 or nginx with php-fpm. Confirm that the version you select appears in the system requirements for your chosen Nextcloud release, because the identity service depends on the same stack as file sync.
HTTPS and trusted certificates
Every relying service must reach the Nextcloud discovery document, token and user info endpoints over HTTPS, using a certificate that each client trusts. Internal certificate authorities need their root certificates installed on every relying service and on the Nextcloud host. Confirm the public base URL, the reverse proxy headers and the certificate renewal process before you register any client, because a mismatch here breaks sign-in for every application at once.
Directory source and LDAP app
If users already exist in LDAP or Active Directory, decide whether Nextcloud will read accounts from the directory through the LDAP app before the identity provider is set up. The LDAP app lets directory users appear in Nextcloud and log in with their directory credentials. Agree on which system owns usernames, group membership and account disablement, so that a user removed from the directory cannot keep signing in through Nextcloud.
Test instance for the app
Build a separate Nextcloud instance with the same major version, database engine, PHP version and web server as production. Use it to enable the OIDC Identity Provider app, register a test client, and sign in from each relying service. Keep test accounts and test clients separate from production so that changes to claims, redirect URIs or signing keys can be checked without affecting live users.
Named owner for app updates
Assign one person or team to track Nextcloud server releases, monthly maintenance releases and updates to the OIDC Identity Provider app. Before each Nextcloud upgrade, that owner confirms app compatibility, takes a backup and checks sign-in on the test instance. Nextcloud requires upgrading one major version at a time, and third-party apps should be disabled until confirmed compatible, so an unowned app is the most likely cause of a broken login after an upgrade.
How to configure the OIDC Identity Provider app step by step
This sequence takes a Nextcloud instance from a verified backup to a tested OpenID Connect identity provider that other internal services can use for sign-in. Each step ends with a check you can record before moving on. Setting names and claim names come from the app and each relying service, so confirm them in their own documentation as you go.
Back up and confirm the supported version
Before changing anything, the administrator takes a full backup of the database, the data directory and the configuration, then confirms that the Nextcloud version is still receiving maintenance releases using Nextcloud's maintenance and release schedule. If the server is behind, upgrade one major version at a time first, back up before each upgrade, and disable third-party apps until they are confirmed compatible. Check the app's store listing for the Nextcloud versions it declares support for. The step is done when the backup restores in a scratch environment and the version check is written into the change record.
Install the app on a test instance
The administrator installs the OIDC Identity Provider app on a separate test instance, either a copy of production configuration and data or a clean instance with representative users and groups. Confirm the installation method and the location of the app's settings in its own documentation, because this page does not list setting names. Enable the app and watch the server log while it loads. The step is done when the app shows as enabled, the log shows no errors on load, and the standard OpenID discovery document responds over HTTP on the test instance.
Register each relying service as a client
For each internal service that will sign users in, the administrator creates one client entry in the app with a clear name, the redirect URI that service expects, and a client secret stored in that service's secret manager. The redirect URI must match exactly what the service sends, including scheme, host, path and port. Record each client identifier in an inventory with its owner. The step is done when every client appears in the app's list, and a test authorization request that uses a deliberately wrong redirect URI is rejected.
Set the issuer to the public HTTPS address
The administrator sets the issuer to the public HTTPS address that users and services reach, usually the hostname that serves Nextcloud behind your reverse proxy, with a certificate chain that every relying service trusts. Do not use an internal hostname or plain HTTP, because services validate the issuer value in tokens and in the discovery document. Confirm in the app's documentation which field holds this value. Changing the issuer after clients exist can break them, so plan to re-test every client. The step is done when the discovery document loads over HTTPS from a machine outside the server network, and its issuer matches the configured value exactly.
Define which groups and users can sign in
For each client, the administrator decides which Nextcloud groups or individual accounts may obtain tokens for that service, and sets that restriction using the access control the app documents. Use groups that already exist in Nextcloud. If accounts come from LDAP or Active Directory, confirm that the groups are synchronized before relying on them. Confirm whether the app refuses users outside the allowed set at token issuance or leaves that decision to the relying service, and document the answer. The step is done when, for each client, a test user inside the allowed group signs in and a test user outside it is refused.
Test one login per client
Using a dedicated test account in an allowed group, the administrator signs in to each relying service once through the full flow. The tester then inspects the ID token and the user information response and confirms the claims the service depends on, such as the subject identifier, name, email and any group claim, checking claim names against that service's documentation. The tester also repeats one refused-account attempt per client. Record the results, the app version and the Nextcloud version. The step is done when every client completes one login with the expected claims and every refused attempt fails.
How Nextcloud accounts map to OIDC claims and relying service roles
This table compares each Nextcloud account attribute with the OIDC claim or scope that may carry it, the field it fills in a relying service, and who decides its value. Group names are the main input to access decisions in each relying service, so group design belongs to the Nextcloud administrators who own it. Confirm every claim name and scope against each relying service's documentation before go-live.
| Nextcloud data | OIDC claim or scope | Relying service field | Owner who decides the value |
|---|---|---|---|
| User ID | sub, the standard subject claim (confirm the mapping in your provider app) | Stable account key the service stores as its link to the user | Nextcloud administrator |
| Display name | name, typically released under the profile scope | Name shown in comments, activity feeds and user lists | User, within the editing policy set by administrators |
| Email address | email, typically released under the email scope | Account matching, notifications and invitations; check how each service treats unverified addresses | Administrator, from the directory or user profile |
| Group membership | groups claim, only if the provider app is configured to send it | Role or group lookup that drives access decisions in each relying service | Nextcloud administrator, through group design and directory sync |
| Account enabled or disabled | No claim; enforced when the provider issues a new token | Disabled users cannot obtain new tokens, so new sign-ins fail at the provider | Nextcloud administrator or the upstream directory |
| Quota or account status | Not sent by default; confirm before adding any custom claim | Rarely needed by relying services, and storage data should stay out of tokens | Nextcloud administrator |
How a sign-in token moves from Nextcloud to a relying service
The sign-in path between Nextcloud and a relying service is the authorization code flow, and a platform team debugging a failed login needs to know which hop produced the error. The relying service sends the browser to Nextcloud's authorization endpoint with its client identifier, a redirect address registered in advance, the requested scopes and a state value it will check on return. Nextcloud authenticates the user, shows the consent screen for the requested scopes, and then redirects the browser back to the relying service with a short-lived one-time code. Almost every failure at this stage traces to a mismatch: a redirect address that differs by a trailing slash or scheme, a client identifier that was edited in one system only, or a state check that fails because cookies were blocked.
Once the browser has returned the code, the relying service calls Nextcloud's token endpoint directly from its back end, authenticating with the client secret. The response normally includes an ID token, which is a signed statement about who the user is and which issuer vouched for it, and an access token used to call protected APIs. The relying service should validate the ID token's signature against the published keys, check the issuer value, the audience (its own client identifier), and the expiry time. Confirm the exact token lifetimes, refresh token behavior and claim names in your Nextcloud version and in the OIDC app's documentation before you write validation logic, because these settings are configurable and default values should not be assumed.
Token lifetimes decide how long a removed or disabled user keeps access. An ID token is normally checked only at sign-in, so it does not revoke anything by itself. An access token or refresh token can continue to work until it expires or is revoked, which means a disabled Nextcloud account may still reach a relying service for the remaining lifetime of tokens already issued. Ask the team to test this directly: disable a test user, then attempt to call a protected endpoint with a token issued before the change. Record the observed window, decide whether it is acceptable for each relying service, and plan the offboarding procedure to include session and token revocation where the relying service supports it. Also decide who is responsible for that revocation step, since it sits across two systems.
Signing keys and the issuer URL are the trust anchors that every relying service stores. If the issuer URL changes, for example when a domain moves or a reverse proxy is reconfigured so that the discovery document advertises a different address, the ID token's issuer value will no longer match what services expect and sign-in will fail everywhere at once. If signing keys are regenerated or rotated without updating the published key set, services that cache keys will reject valid tokens until they refresh. Before go-live, fix the public hostname, confirm the discovery document and key endpoint return the expected values through the production proxy, record the key identifiers, and agree on a key rotation procedure with a test in staging. Treat any change to these values as a planned change with a rollback path, not a routine configuration edit.
Security settings to harden the Nextcloud identity provider
These settings decide how far one sign-in can travel. Each one narrows who can obtain tokens, where those tokens can be sent and which services accept them. Confirm every setting against the documentation for the OpenID Connect Identity Provider app and the Nextcloud release you run before go-live.
HTTPS and exact redirect URIs
Serve every endpoint over HTTPS with a certificate that clients validate, and register each relying service's callback as a full exact URI that includes scheme, host, port and path. Authorization codes and tokens pass through the browser, so plain HTTP or skipped certificate checks expose them. Wildcard or partial redirect patterns let an attacker send a code to a site they control. Confirm in the app documentation whether wildcards are possible at all, and remove callbacks for retired services.
Group limits for each service
Decide which groups may sign in to each relying service, and enforce that in the identity provider as well as in the service itself. Nextcloud groups often mirror departments created for file sharing, so a broad group can grant access to a finance tool or wiki it was never meant to reach. Test sign-in with an account from an excluded group. Document which group grants access to which service so that access reviews can check the mapping.
Two-factor authentication for admins
Require two-factor authentication on every Nextcloud administrator account, and use separate accounts for administration and daily work. The admin account can change identity provider settings, client registrations and user groups, so its compromise changes the sign-in path for every connected service. Confirm in the Nextcloud two-factor documentation which methods are enabled, and how recovery codes are issued and stored.
Supported Nextcloud and app versions
Nextcloud publishes a new major version every four months and supports each one for one year through monthly maintenance releases that address known critical bugs and security problems. Run a Nextcloud release inside that window, and keep the OpenID Connect Identity Provider app on a version compatible with it. Upgrades must move one major version at a time, with a backup taken first. Disable third-party apps until they are confirmed compatible.
Logging on both sides
Log successful sign-ins, failed attempts, token issuance and client registration changes in the identity provider, and collect the matching events from each relying service. A failed attempt that appears in one service but nowhere in the provider log is a gap in detection. Confirm which events the app writes, where they are stored, how long they are kept, and whether they can be forwarded to your central log platform.
Blast radius of a provider compromise
A compromise of the identity provider reaches every connected service, because whoever controls it can issue tokens that those services accept. Nextcloud also holds the files, so the provider and the file store share a failure domain. Before go-live, list each relying service, the data it holds and whether it can be reached without a second factor. Decide with the business owners whether this combined risk is acceptable. If it is not, consider a dedicated identity provider.
How to test sign-in, token claims and logout before users depend on it
Before any internal service accepts Nextcloud as its sign-in source, run a written test plan that proves the identity provider behaves correctly for the users it should admit, refuse, and stop. The first check is a successful login by a user who belongs to a permitted group. Confirm that the relying service receives the expected subject identifier, email address and any group or role claims, and that the values match what the Nextcloud account actually holds. Repeat the same check with a second permitted user from a different group so you know the claim mapping is not accidentally tied to one account. Denied and disabled accounts: Next, sign in as a user outside the permitted groups. The login must fail at the identity provider or at the relying service, and no session or token should be issued to that user. Then disable a test account in Nextcloud and attempt to sign in again, along with any existing sessions. The disabled account must fail to obtain new tokens, and you should check how quickly the relying services stop honoring access they already granted. Record the observed behavior, because it defines the real exposure window if an employee leaves.
Token lifetime and refresh need a test in every relying service, not only in Nextcloud. Note the access token and refresh token lifetimes configured for the identity provider, then confirm that each service expires its own session at the expected point and that refresh either succeeds for an active user or fails cleanly for a disabled one. Some services cache claims or keep local sessions long after the token has expired, so treat each one as a separate case. Test logout the same way: sign out from one service and check whether the others end their sessions, and whether the identity provider session is also terminated. Document any service where logout is local only. Credential changes: Change the password of a test user, and if multi-factor authentication is enabled, enroll or remove a second factor. Confirm that existing refresh tokens are revoked or rejected as your policy requires, and that the change is reflected at each relying service without a manual step. Verify this with the two-factor authentication configuration you intend to run in production, since a passing test on a different method does not prove the production path works.
Upgrades are the test that most often gets skipped. Nextcloud does not allow skipping major releases, so administrators must move one major version at a time, take a backup before every step, and keep third-party apps disabled until each is confirmed compatible. The identity provider app is a third-party app in this design, so it must be disabled during the upgrade and re-enabled only after you have rerun the full test plan on the test instance. Rehearse each step on a copy of production data first, and keep the backup from the previous step until the next one has passed. Before you start, confirm with the app's maintainers which Nextcloud versions it supports, and do not assume support carries over to the next major release. Ask the Nextcloud release schedule for the support window of the version you run, since that determines how often you must upgrade. Plan the retest as a fixed, repeatable script covering sign-in, denial, disabled accounts, token refresh, logout and credential change, and sign off the upgrade only when every case matches the baseline you recorded.
Common sign-in failures with Nextcloud as an identity provider, and their fixes
This table lists the sign-in failures teams most often hit when Nextcloud issues OpenID Connect tokens to other services, with the likely cause and the first thing to check for each. Work down the rows in order when a login breaks, and confirm exact settings and behavior in the Nextcloud app and relying service documentation before you change anything in production.
| Symptom | Likely cause | Fix (check this first) |
|---|---|---|
| Redirect URI mismatch error after the user approves sign-in | The redirect URI registered in Nextcloud for the client differs from the one the relying service sends, often in scheme, host, port or trailing slash | Compare the registered redirect URI character by character with the service configuration. Confirm the exact matching rule in the OIDC app and the service documentation. |
| Discovery or token requests fail, or issuer claim does not match | Nextcloud builds its issuer and endpoint URLs from the request host, so a reverse proxy that passes an internal hostname or scheme advertises the wrong issuer | Set the public URL and overwrite headers on the reverse proxy and in the Nextcloud configuration, then fetch the discovery document and compare the issuer value to the one the service expects. |
| Tokens rejected as not yet valid or expired immediately after issue | Clock skew between the Nextcloud host, the relying service and any token validator, which breaks the iat, nbf and exp checks | Confirm time synchronization (NTP) on every server in the flow. Check the service's allowed clock skew setting in its documentation before widening it. |
| TLS or certificate error when the service calls the token or userinfo endpoint | The relying service does not trust the certificate chain of the internal CA or self-signed certificate used by Nextcloud | Import the CA chain into the service's trust store and confirm the service uses it. Test the endpoints with a TLS client from the service host before retesting sign-in. |
| User signs in but lacks expected roles or access in the service | The groups claim is missing, empty or uses a different claim name than the service maps, or the user is not in the Nextcloud group that the mapping expects | Inspect the ID token or userinfo response for the signed-in user. Confirm the claim name and whether group values are sent, then check the group membership in Nextcloud. |
| Account disabled in Nextcloud but the service still accepts the user | Access tokens and existing sessions in the relying service remain valid until they expire, and the service may not check the user status at each request | Confirm the token lifetime and any session revocation or introspection behavior in the service. Disable the user, revoke active sessions where supported, and test with an existing session. |
| Relying service fails after a Nextcloud major or minor upgrade | The OIDC app or its compatibility with the new Nextcloud release changed, or a third-party app was re-enabled before it was confirmed compatible | Check the app version against the target Nextcloud release and the upgrade notes. Keep third-party apps disabled until compatibility is confirmed, then retest the full sign-in flow in a staging copy. |
| Relying services reject tokens after a signing key change | The signing key was rotated, so cached JWKS data or pinned keys in the service no longer match the key that signed new tokens | Fetch the current JWKS from the discovery document and compare its key ID with the token header. Confirm how the service refreshes keys and clear any cached or pinned key before retrying. |
Questions buyers ask before setting up Nextcloud as an OpenID Connect identity provider
How much does it cost to set up Nextcloud as an identity provider?
The cost is mostly the planning, configuration, integration and testing work, plus the infrastructure you already run. The OIDC Identity Provider app is a community app, so confirm its licensing terms in its app store listing before budgeting. A DeployOpen engagement is fixed-scope and priced from a written scope, and DeployOpen does not publish a price list. Ask the quote to show each relying service, the group model, any directory sync, the MFA approach, the environments covered and handover documentation as separate line items. Ask what is excluded, such as changes to relying services owned by other teams.
How long does an OpenID Connect identity provider setup take?
The timeline depends on the agreed scope, which a fixed-scope agreement sets in writing before work starts. The largest factors are the number of relying services, whether each one needs its own client configuration and testing, and whether accounts come from an existing directory. Ask for milestones: design of claims and groups, a pilot with one or two services, production cutover and a post-go-live review. Also check how long your change approvals and maintenance windows take, because those often set the calendar more than the build does. Treat any duration given without a stated scope as a starting point to question.
What does our team need to provide for an identity provider project?
Expect to supply access, decisions and people. Access means a test instance of your Nextcloud server, administrator accounts, and network paths between Nextcloud, each relying service and your user store. Decisions cover the group model, which attributes go into tokens, password and MFA policy, and session lifetimes. People include an application owner for each relying service who can confirm redirect addresses and test sign-in, and someone who can approve production changes. Name a backup owner for Nextcloud as well, because a backup is required before every upgrade. Agree in advance who signs off test results so acceptance does not stay open after cutover.
Can our internal IT team set this up without a partner?
Often yes, if you have someone comfortable with OAuth 2.0 and OpenID Connect concepts, Nextcloud administration and your relying services. The harder parts are usually not the first login but the edge cases: token lifetimes, group claims that change, clients that handle token refresh poorly, logout behavior and the upgrade path. Assess your team on three points: whether they have completed a Nextcloud upgrade with third-party apps disabled and re-enabled, whether they can test each relying service end to end, and whether they have time to own the setup after go-live. If two of those are missing, a fixed-scope engagement can cover the build and handover while your team keeps ownership.
What makes the effort of an OIDC setup go up?
Five factors move effort most: the number of relying services, the group model, directory integration, the MFA policy and the upgrade cadence. Each relying service needs its own client registration, redirect addresses, claim mapping and test cases, so effort grows with the count. A flat group model is simple, while nested or role-based groups mapped to permissions in several services need design and review. Directory integration adds attribute mapping, sync rules and handling of disabled accounts. An MFA policy that differs by group or service multiplies the test paths. Upgrade cadence matters because Nextcloud publishes a new major version every four months, each supported for one year, according to its maintenance and release schedule, so sign-in needs retesting often. Ask the quote to show how each factor is scoped.
Which parts of an identity provider setup are one-time and which recur?
Design, build, the first integration of each relying service and the initial test cycle are one-time work. Recurring work includes regression testing of sign-in after each Nextcloud upgrade, onboarding new relying services, rotating client secrets and certificates, reviewing group mappings when teams change, and handling support requests. Nextcloud supports each major version for one year through monthly maintenance releases, so plan a recurring test cycle that follows that rhythm. Ask whether the quote treats these items as a retainer or as separate work orders, and what response expectations apply to each. Retainers are available for ongoing support, upgrades and continuous testing.
Does Nextcloud Enterprise support cover the OIDC Identity Provider app?
Check this before you buy anything, because the answer decides who fixes a broken login. Nextcloud's pricing page describes Standard as including 1-year maintenance, and Premium as adding a maintenance lifecycle of 5 or more years, extended support hours and clustered instance support. Those tiers describe support for Nextcloud itself. Community apps from the app store are not necessarily covered by any tier, so confirm in writing with Nextcloud whether the OIDC Identity Provider app is in scope and for which versions. Ask also whether a tier change affects a community app on your current release, and how long the app's own maintainer supports each Nextcloud version.
When is Nextcloud a poor fit as an identity provider?
Nextcloud can serve sign-in for small organizations, especially where it already holds the users and the relying services are few and low risk. A dedicated identity provider is the better choice when many applications need central login, when you need stronger or more varied MFA options, when HR-driven lifecycle automation or access certification is required, or when logins must keep working through Nextcloud outages or upgrades. Also consider whether a file sync server should be a single point of failure for sign-in to other systems. Self-managed identity platforms such as Keycloak and authentik are options DeployOpen also implements. Ask for a short written comparison against your requirements before you choose.
How DeployOpen scopes, builds and supports a Nextcloud identity provider
DeployOpen starts by confirming whether Nextcloud should act as an OpenID Connect identity provider for your internal services, or whether a dedicated identity provider is the better fit. Each engagement is fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. Build, testing and documentation then take place inside your own infrastructure.
How we scope
- The written scope lists the internal services that will sign in through Nextcloud, along with the users and groups involved.
- We record which identity sources, such as LDAP or Active Directory, remain in place alongside the OpenID Connect setup.
- The scope states your current Nextcloud and PHP versions and whether a major upgrade must happen before the build.
How we build
- We configure the OpenID Connect identity provider app on your Nextcloud server, with a client registration for each relying service.
- We test sign-in, sign-out and group claims for each relying service using representative test accounts before cutover.
- We take a backup before any change to the server, in line with Nextcloud's upgrade guidance.
How we hand over
- A written runbook covers client registrations, signing keys, redirect URIs and where each setting is stored.
- A decision record explains why Nextcloud serves as the identity provider and what would prompt a move to a dedicated one.
- We walk your administrators through adding a service, rotating a client secret and checking authentication logs.
How we support
- An optional retainer covers sign-in issue handling, patching and advice when you add new relying services.
- Upgrades proceed one major Nextcloud version at a time, with third-party apps confirmed compatible before each step.
- We review whether Nextcloud still suits your setup as the number of services and users grows.
