Quick answer
The Marketplace listing says Nextcloud for Jira stores the Nextcloud app password in encrypted Forge storage and never returns it to the administration UI after save. Those are two distinct controls:
- Forge's Secret store protects the persisted value.
- The app's UI design avoids sending the saved password back to the browser.
A third fact matters: encryption here is for later use, not one-way hashing. Atlassian documents that app code retrieves a value written with kvs.setSecret by calling kvs.getSecret. The integration needs that runtime access to authenticate to Nextcloud.
The right security conclusion is therefore specific: secret storage and non-display reduce credential exposure. They do not, by themselves, prove correct admin authorization, log redaction, least-privilege Nextcloud access, rotation readiness, or deletion behavior.
Start with the evidence boundary
As checked on September 14, 2026, the official Atlassian Marketplace listing identifies Nextcloud integration for Jira (FREE) as a Backlog Bridge Forge app for Jira Cloud. It describes one hosted or self-hosted Nextcloud connection per site.
The listing says administrators enter an HTTPS URL, account, and app password, test the connection, and save it. Under Security, it states that app passwords are stored encrypted and not returned to the UI after save. These are public vendor disclosures on Atlassian Marketplace; they are not the same as an independent source-code review.
| Public statement | Supporting source | What still needs evidence |
|---|---|---|
| The app uses encrypted credential storage | Marketplace listing and vendor product page | The exact fields and all code paths that handle them |
| A saved password is not returned to the UI | Marketplace listing | Browser responses, error paths, diagnostics, and logs |
| Connection setup is for administrators | Marketplace listing and vendor page | Server-side authorization in the installed version |
| The app runs on Forge for Jira Cloud | Marketplace listing | Current scopes, external destinations, and app-version behavior |
| Nextcloud accepts an app password | Nextcloud documentation | Service-account permissions and local token policy |
This article relies on public documentation and does not independently verify the application's source code.
Model the save and use path
Based on the disclosed behavior and Forge's documented APIs, an administrator can evaluate this conceptual flow:
- A Jira administrator enters the Nextcloud URL, account, and a newly generated app password.
- The app tests the credential against the approved HTTPS destination.
- On save, the app stores the sensitive value through Forge's Secret store.
- Later, app code retrieves the value inside the Forge runtime when it needs to authenticate a Nextcloud request.
- The Jira issue panel receives the folder information or an error it needs to render, but not the stored password.
- When the credential changes, an administrator supplies a replacement instead of reading the old value from the UI.
This is a review model, not a description of private resolver names, secret keys, or source code. Use it to ask for evidence at each boundary:
admin browser → trusted app function → Forge Secret store → trusted app function → HTTPS Nextcloud request
The password should cross the first boundary only during entry or replacement. It must cross the runtime-to-Nextcloud boundary when used for authentication. It should not return in a settings response, panel response, log line, analytics event, or support bundle.
What kvs.setSecret does
Atlassian's Forge Secret store reference describes kvs.setSecret as the KVS method for sensitive credentials. Values written through it are read with kvs.getSecret, and the ordinary KVS query method cannot return them.
The broader Forge KVS reference adds three useful boundaries:
- Forge hosted storage is namespaced by app, installation, environment, and Atlassian product context.
- Only the app can read and write its stored data in that namespace.
- Data is transferred, encrypted, and stored according to Atlassian cloud encryption policies.
Using @forge/kvs requires the storage:app scope. That scope tells you the app can use its hosted storage. It does not tell you which values use kvs.setSecret instead of ordinary kvs.set; the vendor disclosure and implementation evidence must answer that.
Secret storage is not a password hash
A one-way password hash is checked without recovering the original password. That would not work for this integration: Nextcloud expects the app password during authentication.
Forge secret storage keeps a retrievable encrypted value. App code that knows the stored entry's KVS key can obtain it with kvs.getSecret within the installation context. This is necessary behavior, but it means reviewers should not accept claims such as:
- “The password can never be retrieved.”
- “Nobody can decrypt or use the saved credential.”
- “Encryption alone prevents the app from exposing the password.”
The precise statement is stronger because it is testable: the app can use the credential in its trusted runtime, while its browser-facing responses should not disclose it.
Secret values are not ordinarily queryable
Atlassian says a value stored with kvs.setSecret cannot be retrieved through the normal KVS query method. This reduces the chance that a general list or search operation returns a secret alongside ordinary configuration.
It does not prevent application code from calling kvs.getSecret for a known key. Review which functions need that access and what they return.
Storage is isolated per installation
Forge's namespacing means one installation does not use a key chosen by another site to read its data. This platform boundary matters for a Marketplace app installed across customers.
It does not replace authorization inside one Jira site. If a resolver returns sensitive configuration without checking the caller, installation isolation will not repair that application-level error.
Deletion is a separate operation
Forge provides kvs.deleteSecret. Atlassian also says persistent storage remains until the app deletes or updates it.
Do not infer that disconnecting or uninstalling Nextcloud for Jira automatically deletes a secret unless the current product documentation or vendor evidence says so. Ask what each action does:
| Action | Secret question | Independent Nextcloud action |
|---|---|---|
| Replace connection | Is the old value overwritten? | Revoke the old app password after the new one works |
| Disconnect | Is the secret deleted, retained for reconnect, or only disabled? | Revoke the app password if access should end |
| Uninstall | What is the Forge storage-retention and deletion path? | Revoke the app password without waiting for app cleanup |
| Reinstall | Can previous hosted data become available again? | Decide whether the prior token should remain invalid |
Revoking the token in Nextcloud is the control the customer owns directly. Use it when the integration should no longer authenticate, regardless of app-side cleanup.
Why the password is not shown again
A settings page that can reveal an existing credential creates additional exposure paths: screen sharing, browser extensions, copied support payloads, compromised administrator sessions, and accidental screenshots.
A write-only settings pattern reduces those paths. After save, the interface can report that a credential is configured without sending its value to the browser.
A row of bullet characters is not proof. Some interfaces populate a password input with the real value and merely mask it visually. A stronger implementation sends a state such as “configured” and leaves the secret value out of the response entirely.
Test these states separately:
- Configured: the app reports that a saved credential exists.
- Displayed: the browser has received the actual value.
- Usable: the Forge runtime can retrieve it for an authenticated request.
- Valid: Nextcloud accepts it and the account can access the requested folder.
The desired state after save is configured, usable, and valid—but not displayed.
Separate administrator configuration from runtime use
The Marketplace listing describes connection setup as an administrator action. The Backlog Bridge product page likewise says only Jira administrators can change the connection settings.
That claim concerns who may configure the integration. It does not mean an administrator must be present whenever a user opens a linked folder panel. At runtime, the app uses the site connection on behalf of the intended issue-panel workflow.
Check both boundaries:
- A non-admin cannot save, replace, disconnect, or change the Nextcloud destination.
- A permitted Jira user can use the panel without receiving the credential in a browser response.
Hiding the settings menu from non-admins is not sufficient evidence. Attempt the underlying action with a non-admin test account and confirm the trusted backend rejects it.
Also test how the shared Nextcloud service account changes visibility. A user may be allowed to browse a Jira issue while the integration account can list a folder the user could not open directly in Nextcloud. Decide whether file names, folder paths, and metadata shown in Jira match your intended audience.
Use an app password with an owned lifecycle
Nextcloud's authentication documentation says app passwords let client applications authenticate without receiving the account's main login password. Its device-management guide says each generated device password can be disconnected individually and is visible only when created.
Use a dedicated Nextcloud service account, generate one recognizably labelled app password for this integration, and limit the account to the folders the Jira workflow needs. Treat the generated value as a temporary secrets handoff until the Jira administrator enters it; never place it in a ticket, chat message, screenshot, or runbook.
For Nextcloud 30 and later, the administrator documentation says unused app passwords are deleted automatically after 365 days by default, and administrators can change that interval. Check the policy on your instance instead of assuming an unused integration token persists forever.
For service-account selection and connection steps, use the Nextcloud-to-Jira admin guide.
Prove the behavior in a sandbox
Use a temporary Nextcloud account, a dedicated app password, and non-production folders. Record the app version, Jira site, Nextcloud version, time, tester, and result.
| Test | Method | Evidence to retain |
|---|---|---|
| No redisplay | Save, reload settings, and inspect the rendered page and browser responses | No password value in HTML, JSON, network payloads, or client state |
| Admin-only change | Attempt save, replace, and disconnect with a normal Jira account | Trusted backend rejects each operation |
| Runtime use | Open a linked issue as an intended user | Folder data loads; secret is absent from browser traffic |
| Failed authentication | Revoke the temporary password in Nextcloud | Request fails closed with a useful, non-secret error |
| Rotation | Save a replacement, test, then revoke the old token | New token works; old token fails |
| Log redaction | Inspect permitted Forge logs and app diagnostics around failures | No URL credentials, authorization values, or password fragments |
| Least privilege | Link allowed and disallowed test folders | Service account returns only the intended directory scope |
| Disconnect | Disconnect, then retry and review settings | Document whether access, secret, and mappings remain |
| Removal | Uninstall in a disposable site if procurement requires it | Vendor or platform evidence explains retained/deleted hosted data |
Do not paste the credential into a browser developer-tools search field or evidence document. Use a separately generated, non-secret canary marker for redaction testing; never derive the marker from any part of the credential.
Read the public disclosures together
A security review should compare the Marketplace listing, permissions view, Backlog Bridge privacy policy, product documentation, and observed installation behavior. No single badge or paragraph covers the full flow.
The Marketplace listing says the app password is stored encrypted in Forge. The privacy policy explains that app configuration—including an integration credential when a connection requires one—may be stored in Atlassian Forge hosted storage, while Backlog Bridge does not operate a separate external database for that data. Those statements describe different parts of the same hosting model; Forge-hosted secret storage is still credential storage.
Verify that the current disclosures and installed behavior explain:
- who processes the credential;
- where the encrypted value is hosted;
- whether it reaches vendor-operated systems;
- retention on disconnect and uninstall;
- log and support access;
- incident and deletion procedures.
Do not interpret “no vendor-operated external database” as “no credential storage.” The runtime must be able to retrieve the app password to authenticate to Nextcloud.
Marketplace snapshot and limits
On September 14, 2026, the listing showed Jira Cloud compatibility, a free commercial license, Partner Supported status, version 2.11.0, a completed privacy and security questionnaire, and no participation in the Marketplace Bug Bounty program.
These details change and do not establish quality, security, or maintenance. Before approval, use the current Marketplace screens to verify:
- app version and recent changes;
- Forge scopes and integration permissions;
- external Nextcloud destination consent;
- privacy and security questionnaire responses;
- support and escalation route;
- current pricing;
- any security-program participation or certification actually displayed.
Do not infer SOC 2, ISO certification, Cloud Fortified status, data-processing terms, or regulatory compliance when the current listing does not show them.
Make an evidence-based decision
| Finding | Decision |
|---|---|
| Secret saved through Forge Secret store; browser never receives it again; admin actions reject non-admins | Continue to rotation, permission, logging, and deletion checks |
| Password input is only visually masked but the value returns to the browser | Pause approval and request remediation |
| Credential appears in logs, diagnostics, URLs, or error payloads | Stop the review and follow the incident process |
| Service account can browse more folders than Jira viewers should learn about | Reduce Nextcloud permissions before rollout |
| Rotation and revocation recover cleanly in sandbox | Record the runbook and owners |
| Disconnect/uninstall behavior is undocumented | Require an answer and revoke the Nextcloud token independently |
| Privacy, Marketplace, and observed behavior do not agree | Request corrected or app-specific documentation |
Approve the control, not an assumption
Forge Secret store is the right platform category for a retrievable Nextcloud app password. Avoiding UI redisplay is the right browser-facing pattern. Admin-only configuration is the right ownership model.
Approve those statements only at their actual scope. The app runtime still needs to use the credential. The Nextcloud account still defines accessible folders. Rotation and revocation still need owners. Logs and error routes still need inspection. Secret deletion still needs a documented path.
When those checks match the public claims, you have evidence for the credential-handling control—not a blanket guarantee about the entire integration.
For the network boundary, follow the customer-managed egress approval guide. For the full configuration sequence, read How Jira admins connect Nextcloud to Jira Cloud. Then evaluate the current Nextcloud for Jira Marketplace listing against your installed version.