Issue Station
Sign In
Tools hereToolbox

dify - ✅(Solved) Fix Feature Request: Per-user access control for plugin credentials (OAuth tokens, API keys, and all authorization methods) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langgenius/dify#34925•Fetched 2026-04-11 06:31:46
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
1
Author
ForeignKeyCNForeignKeyCN
Participants
ForeignKeyCNForeignKeyCN
Timeline (top)
labeled ×1

PR fix notes

PR #35162: feat: add per-credential access scope for builtin tool providers (#34…

Description (problem / solution / changelog)

Fixes: https://github.com/langgenius/dify/issues/34925

Summary

Implements per-credential access control for built-in plugin tool credentials in console and runtime.

  • Adds credential visibility/usage scopes: workspace, private, and restricted (selected members).
  • Enforces access at both listing and execution time: users only see/use credentials allowed by scope; runtime blocks unauthorized credential usage.
  • Extends console API payloads and frontend auth UI to set/update scope and restricted member list.
  • Persists scope and restricted-member mappings with new DB schema/migration and service-layer sync/validation.
  • Updates unit tests for backend services/controllers to cover new access-control behavior.

Checklist

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran make lint && make type-check (backend) and cd web && pnpm exec vp staged (frontend) to appease the lint gods

Changed files

  • api/controllers/console/workspace/tool_providers.py (modified, +28/-2)
  • api/core/tools/entities/api_entities.py (modified, +8/-0)
  • api/core/tools/entities/tool_credential_access.py (added, +14/-0)
  • api/core/tools/tool_manager.py (modified, +9/-0)
  • api/migrations/versions/2026_04_13_1200-a1b2c3d4e5f6_tool_builtin_credential_access_scope.py (added, +56/-0)
  • api/models/__init__.py (modified, +2/-0)
  • api/models/tools.py (modified, +27/-0)
  • api/services/tools/builtin_tools_manage_service.py (modified, +52/-3)
  • api/services/tools/tool_builtin_credential_access_service.py (added, +128/-0)
  • api/services/tools/tools_transform_service.py (modified, +6/-1)
  • api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py (modified, +16/-3)
  • api/tests/unit_tests/services/tools/test_builtin_tools_manage_service.py (modified, +10/-5)
  • web/app/components/plugins/plugin-auth/authorize/api-key-modal.tsx (modified, +101/-7)
  • web/app/components/plugins/plugin-auth/authorized/item.tsx (modified, +2/-0)
  • web/app/components/plugins/plugin-auth/types.ts (modified, +4/-0)
  • web/i18n/en-US/plugin.json (modified, +5/-0)
  • web/i18n/zh-Hans/plugin.json (modified, +5/-0)
  • web/service/use-plugins-auth.ts (modified, +4/-0)
RAW_BUFFERClick to expand / collapse

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

  1. Is this request related to a challenge you're experiencing? Tell me about your story.

I'm a Dify SA serving many customers. A frequent complaint is that plugin credentials (OAuth tokens, API keys, etc.) are shared with the entire workspace by default. Users have no way to keep their personal credentials private. Multiple customers have flagged this as a major security concern. Even the Enterprise version doesn't solve this — and without per-credential access control, the Enterprise plugin management feature becomes largely obsolete. Adding scoping options (only me / specific users / everyone) per credential would be the right solution.

<img width="1524" height="1650" alt="Image" src="https://github.com/user-attachments/assets/2a7826b1-9838-46ce-bbaa-fa8fed717d51" />

2. Additional context or comments

  1. Additional context or comments

Expected behavior: When creating or managing any plugin credentials (OAuth tokens, API keys, bearer tokens, or any other authorization method), users should be able to set an access scope:

Only me — only the credential creator can use this connection Specific users/roles — share with selected workspace members Everyone — available to all workspace members (current default behavior) This should apply universally to all plugins and all credential types in the Dify plugin ecosystem (Outlook Trigger, Google Drive, Slack, Zendesk, Lark, LangBot, and any future plugins).

Use case: In a team workspace, different members connect their own personal accounts or services. A user's credentials should not be automatically shared with the entire team unless they explicitly choose to share them.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.

extent analysis

TL;DR

Implementing per-credential access control with scoping options (only me, specific users, everyone) would address the security concern of shared plugin credentials in the Dify workspace.

Guidance

  • Introduce a new field in the credential creation form to select the access scope, allowing users to choose between "only me," "specific users/roles," and "everyone."
  • Modify the plugin management feature to respect the chosen access scope for each credential, ensuring that credentials are only shared with authorized users or roles.
  • Update the Enterprise plugin management feature to leverage the new access control mechanism, making it more effective and secure.
  • Consider implementing role-based access control (RBAC) to further enhance security and flexibility in managing plugin credentials.

Example

// Example of access scope selection in credential creation form
Access Scope:
- Only me
- Specific users/roles (select from workspace members)
- Everyone

Notes

The implementation details may vary depending on the specific requirements and technical constraints of the Dify platform. It is essential to ensure that the new access control mechanism is compatible with all plugins and credential types in the ecosystem.

Recommendation

Apply a workaround by implementing per-credential access control with scoping options, as this would directly address the identified security concern and provide a more secure and flexible plugin management experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#model loading#dependency error#configuration error#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING