Security: OAuth/session findings from code review

[tkaufmann]

Context

While reviewing the codebase (v0.65.0) for a BasicAuth deployment, I noticed several security issues in the OAuth/session paths. I'm submitting PRs for the input validation issues I encountered (XML injection, path traversal, SSRF, etc.), but the findings below are in code paths I'm not modifying, so I'm reporting them here.

Findings

1. JWT decoded without signature verification (Critical)

Files: auth/token_exchange.py:305,340, auth/token_broker.py:527, auth/provisioning_decorator.py:82,165, auth/token_utils.py:49, auth/browser_oauth_routes.py:373, auth/oauth_routes.py:~595

8+ locations use jwt.decode(token, options={"verify_signature": False}). In _validate_flow1_token() (token_exchange.py), audience/expiry/subject checks run on unverified claims. Code comments confirm awareness ("In production, should verify signature").

Impact: An attacker can forge arbitrary JWT claims. In token exchange mode, a self-crafted JWT with aud: "mcp-server" enables full identity takeover.

CWE-347 (Improper Verification of Cryptographic Signature)

2. Predictable session cookie value

Files: auth/browser_oauth_routes.py:448-453, auth/session_backend.py:80-81

The mcp_session cookie is set to the raw user_id (the sub claim from the ID token). No HMAC, no signature, no cryptographically random session token. The user_id is typically a predictable UUID from the IdP.

Impact: If an attacker learns another user's user_id (exposed in debug logs), they can forge the cookie and access the admin UI and stored refresh tokens.

CWE-287, CWE-384

3. LLM-controllable user_id parameter in OAuth tools

File: server/oauth_tools.py:588-640

Tools provision_nextcloud_access, revoke_nextcloud_access, check_provisioning_status, and check_logged_in accept an optional user_id parameter. An LLM or direct MCP client can supply an arbitrary user ID.

Impact: Cross-user attacks: revoking another user's Nextcloud access (DoS), querying other users' provisioning status (information disclosure).

Fix: Remove user_id from public tool signatures; always extract from the authenticated token.

CWE-639 (Authorization Bypass Through User-Controlled Key)

4. Logout does not revoke refresh token

File: auth/browser_oauth_routes.py:459-479

The logout handler only deletes the cookie. The refresh token remains in the database. This is marked as a TODO in the code.

Impact: After logout, the session is not invalidated server-side. Refresh tokens remain valid for up to 90 days.

CWE-613 (Insufficient Session Expiration)

5. Hardcoded encryption keys in docker-compose.yml

File: docker-compose.yml:151,190,271,314

Four Fernet encryption keys are hardcoded in the committed docker-compose.yml.

Impact: Anyone with repo access can decrypt all stored tokens.

Fix: Use placeholder values with comments, or move to .env.example.

Notes

• Findings 1-4 only affect the OAuth code path. BasicAuth-only deployments are not impacted.
• I'm happy to help with fixes if that's useful — just didn't want to scope-creep my existing PRs.

[cbcoutinho]

Hi @tkaufmann thanks for raising these valid issues, I will take a look at your related PRs as well this week and address the issues raised above.

Regarding the deployment modes, I have been considering consolidating the nextcloud MCP server into two deployment modes to simplify the codebase: single-user and oauth with NC login flow v2. This would remove the need for multi-user basic auth, as well as the more generic oauth implementation that requires patching Nextcloud upstream.

Would you mind sharing your thoughts on this, and do you still see a need for multi-user basic auth flow if something like OAuth + Login Flow v2 would be sufficient for multi-user setups? This would change how refresh tokens are handled by the nextcloud mcp server, for example.

I see you've provided some PRs/comments regarding the multi-user basic auth deployment mode, and I think this is worthy of discussion if users are interested in the multi-user basic auth deployment mode as opposed to a more simplified OAuth setup.

[tkaufmann]

Hi @cbcoutinho thanks for the thoughtful response! I'd like to share my use case because it might inform your design decisions around deployment modes.

How I use your MCP server

I run your nextcloud-mcp server as a gateway for multiple AI agents. Each agent has a different job and needs different permissions. For example, my document scanner agent processes incoming documents and needs to upload files to specific Nextcloud folders and nothing else. No calendar access, no contacts, no deleting files.

Where your server helped me

The single-user BasicAuth mode got me started quickly. One app password, and agents could talk to Nextcloud through MCP. The security hardening in PR #627 and the scope system in PR #628 came from running this in production and finding things I needed to tighten.

Where I needed to extend

The challenge: with single-user auth, every agent has the same permissions. I needed per-agent access control without creating a separate Nextcloud account for each agent. With 2 agents that's manageable, with 10 or 20 it's not each account needs provisioning, password management, quota configuration.

So I built a token layer on top of your MCP server (not submitted as a PR because it's opinionated):

• One Nextcloud service account (e.g. ai.scanner) with a single app password
• Multiple bearer tokens at the MCP level, each with different scopes
• NEXTCLOUD_MCP_TOKEN_<NAME> in the .env maps to: NC account + app password + allowed scopes
• Deny by default a token without scopes can't do anything

Think of it like GCP service accounts or AWS IAM roles: the underlying authentication is one account, but access control is fine-grained and managed at the gateway level, not in the backend system.

My provisioning pipeline

I built a CLI tool that fully automates the setup:

1. Create a Nextcloud service account via occ user:add
2. Generate an app password for that account via occ
3. Generate a bearer token with scoped permissions at the MCP level
4. Deploy the complete configuration (account + app password + bearer token + scopes) to the .env file on the server
5. Restart the MCP service

This runs end-to-end without requiring manual steps in Nextcloud's web interface no browser login, no clicking through settings pages.

My security model

I take the possibility of agents gone rogue seriously. The MCP server is part of a larger infrastructure where multiple services act as controlled gateways for AI agents:

• An n8n instance proxies outbound API calls (Google APIs, RunPod, etc.) agents never see the API keys, they just call a webhook and get the response back.
• The MCP server provides scoped Nextcloud access the same way agents authenticate with bearer tokens, but the actual Nextcloud credentials are in .env files they can't read.
• A CLI tool provisions accounts and tokens across these services, deploying credentials to the right .env files on the right hosts.

The pattern is the same across all services: agents authenticate with a simple bearer token, and the service maps that token to the appropriate permissions and upstream credentials. Agents never see the actual API keys or passwords.

On the infrastructure level:

• Dev and production are separate non-root Linux users on the same machine. LLM agents have SSH access to dev only, where they work with test data and test tokens.
• Production: No LLM has access period. I review and deploy manually. Even a fully compromised agent in dev can't reach production.
• Bearer tokens are separate from NC app passwords by design: an intercepted bearer token doesn't give direct Nextcloud access.

What this means for your simplification plan

What matters for my use case is having a layer where the MCP server can authenticate multiple clients based on their tokens with different permission scopes, backed by one (or few) Nextcloud accounts. That layer is auth-agnostic it works on top of whatever connection mode you choose.

However, my provisioning pipeline depends on being able to create credentials programmatically today I use occ to generate app passwords and configure them in the .env, without requiring anyone to log into Nextcloud's web interface. Whether dropping multi-user BasicAuth works for me depends on whether headless credential provisioning remains possible in your simplified design.

Is there a way to create credentials programmatically in the setup you're envisioning whether through occ, an API, or some other mechanism that doesn't require a browser-based login flow?

If the token/scope layer is a use case you want to support natively, I'm happy to collaborate on a design. If not, I'll maintain it in my fork either way, our approaches are compatible as long as headless provisioning remains possible.

[cbcoutinho]

Hi @tkaufmann thanks for the clarification - this is an interesting use-case and something different than I have had in mind for the MCP Server up until this point.

Currently my thought-process was geared towards multiple users (NC accounts) to each be able to connect to a single MCP server with permissions based on OAuth scopes, and enable users to reauthorize the service on-demand; however, I had primarily considered this to be a browser-based flow using NC Login Flow v2. At the MCP level this would be taken care of via URL elicitation, which is starting to gain adoption by various MCP clients.

That said, I haven't committed to deprecating the multi-user basic auth mode, yet - I would prefer to replace the current OAuth deployment modes with the new one based on Login Flow v2 so that it doesn't require patching the NC server. I personally think multi-user basic auth deployment is fine and easy to reason about, although the official spec defines token pass-through via MCP Servers as an "anti-pattern" - I don't hold a very strong opinion on this one way or the other🤷

I'm curious, which MCP client are you currently using to manage these agents? Multiple instances of Claude Code, or something else you've built yourself?

Also, just some food-for-thought - when a colleague and I were exploring setting up our own "cloud-based" LLM some weeks ago, we ran into context issues for some smaller models, and came around to using an "App Expert" pattern. This was the same Nextcloud MCP server was actually defined multiple times with each "MCP Integration" in OpenWebUI only exposing a limited number of tools to an LLM. This sounds very similar to your "gateway" use-case, but then with the logic in the workflow/orchestrator rather than the MCP Server itself. Link to blog post

[tkaufmann]

Hi Chris,

On the token passthrough anti-pattern

I actually think my token layer is fully compliant with the spec, and maybe even more so than the current BasicAuth mode, if you'll forgive me saying so.

The anti-pattern as defined in the spec is about an MCP server accepting tokens that were "not explicitly issued for the MCP server" and passing them through to downstream APIs. The risks it lists, circumvented security controls, broken audit trails, trust boundary violations, all stem from the MCP server being a dumb pipe that forwards credentials it doesn't understand.

My token layer does the opposite:

• The bearer tokens are issued by the MCP server, for the MCP server. They don't exist anywhere else.
• The MCP server validates them, resolves the associated scopes, and enforces access control before any request reaches Nextcloud.
• The actual Nextcloud credentials (app passwords) live in the server's .env file. Clients never see them and can't use them directly.

That's the "proper token audience separation" the spec recommends as mitigation.

If anything, the current multi-user BasicAuth mode is closer to the anti-pattern: clients send Nextcloud credentials through the MCP server, which forwards them to the Nextcloud API. The MCP server doesn't issue those credentials, Nextcloud does. An intercepted BasicAuth header gives direct access to the Nextcloud account.

I'm not saying BasicAuth is insecure for typical deployments, it's simple and works well in trusted environments. Just pointing out that the spec's concerns about token passthrough seem to apply more to that pattern than to dedicated MCP-level tokens.

MCP client setup

I'm currently using Claude Code as my primary MCP client. I'm also looking into orchestrators like OpenClaw for more complex multi-agent setups.

I've also been using MCP in a way that might be a bit unconventional: rather than only connecting LLMs to MCP servers directly, I have Claude Code develop standalone scripts that communicate with the MCP server. Claude can talk to the MCP during development and testing, iterate on the script, and verify it works, but the final artifact is a script that runs independently.

It seemed like a sensible approach to me, even if it's a bit unusual since MCP is typically only seen in direct LLM-to-server communication. The main advantage is that I don't have to provision and revoke credentials for the LLM every time I want it to build or improve something. Claude develops and tests against the same MCP interface with the same scoped token that the finished script will use, but neither Claude nor the script ever see the Nextcloud credentials behind the MCP server.

On the App Expert pattern

I read your blog post, it's a clever workaround for a real problem. My token layer already solves this at the protocol level: since I filter tools/list based on the token's scopes, each agent only sees the tools it's authorized to use. A token scoped to notes:read will only see the Notes read tools in the tool listing, not all 90+.

So it addresses both concerns at once: access control (the agent can only do what it's scoped for) and context reduction (the agent only sees what it's scoped for). No need to configure multiple MCP connections on the client side, which is essentially what you described as something that "should be a protocol-level feature."

By the way: What has your experience been with Leaflet? I recently tried runpod.io and found it pretty challenging. The machines take quite a while to boot up, reported different CUDA versions, which forced me to very precisely define which GPU models could be used, and so on. It may be that I’ll be faster with further experiments, but the time it took to get the first working setup (an LLM that processes scanned documents) was 8 hours. I’ve now ordered a Mac Studio Ultra so I can work locally, sigh.

[cbcoutinho]

Hi @tkaufmann — quick update: PR #758 just landed on master (348ac56), released as v0.79.1, closing all five findings from your report. Thank you for the thoughtful writeup back in March, and for sticking with the review process.

Status of each finding:

1. JWT decoded without signature verification (CWE-347) — Every verify_signature=False callsite is gone. A single verify_id_token() helper now lives in auth/token_utils.py, doing RS256/PS256/ES256 verification against the IdP's JWKS, with kid lookup, key-rotation retry per OIDC §10.1.1, and secrets.compare_digest for the nonce check.
2. Predictable session cookie (CWE-287/384) — The mcp_session cookie is now an opaque secrets.token_urlsafe(32) mapped server-side via the new browser_sessions table (migration 005). The session backend requires both a live session row and a live refresh token, so a leaked cookie becomes useless after logout or revocation.
3. LLM-controllable user_id (CWE-639) — Removed from all four OAuth tool signatures; identity is derived exclusively from the authenticated bearer token. A schema regression test pins this so it can't drift back.
4. Logout doesn't revoke refresh token (CWE-613) — Logout calls the IdP's revocation_endpoint (RFC 7009) when advertised, then atomically deletes both the refresh token and browser session, with CSRF protection via Origin/Referer + SameSite=Lax.
5. Hardcoded Fernet keys — docker-compose.yml now uses ${TOKEN_ENCRYPTION_KEY:?...} so Compose refuses to start without a real value, and env.sample documents how to generate one.

On the deployment-mode question from earlier in this thread: I ended up adding Login Flow v2 alongside the existing modes rather than replacing anything — multi-user BasicAuth and single-user BasicAuth are both still there. Your headless provisioning pipeline (occ-driven app passwords into .env) keeps working as-is. docs/ADR-022-login-flow-v2.md has the architectural details if you're curious.

Re: your token-layer pattern with MCP-issued bearer tokens, scope-filtered tools/list, and one underlying NC service account — interesting design, and I take your point that audience-bound tokens issued by the MCP server are a different shape than the spec's pass-through anti-pattern. I don't have plans to take this on natively right now, but if there's broader interest I'd happily consider it as a separate issue.

On Leafcloud: very happy with them. The OIDC login via `kubectl` was the one rough patch — took some fiddling — but everything else has been smooth. Node hibernation is production-ready in my experience, with ~5 minute startup times on GPU-enabled nodes — totally acceptable for homelab / small-cluster scenarios where you don't need instant scale-up. RunPod sounds like a different operational model entirely; sorry the first setup ate 8 hours. The Mac Studio Ultra should give you a much nicer local feedback loop.

Thanks again for the report.