Adds a CLI-friendly authorization flow so difyctl (and future
non-browser clients) can obtain user-scoped tokens without copy-
pasting cookies or raw API keys. Two grant paths share one device
flow surface:
1. Account branch — user signs in via the existing /signin
methods, /device page calls console-authed approve, mints a
dfoa_ token tied to (account_id, tenant).
2. External-SSO branch (EE) — /v1/oauth/device/sso-initiate signs
an SSOState envelope, hands off to Enterprise's external ACS,
receives a signed external-subject assertion, mints a dfoe_
token tied to (subject_email, subject_issuer).
API surface (all under /v1, EE-only endpoints 404 on CE):
POST /v1/oauth/device/code — RFC 8628 start
POST /v1/oauth/device/token — RFC 8628 poll
GET /v1/oauth/device/lookup — pre-validate user_code
GET /v1/oauth/device/sso-initiate — SSO branch entry
GET /v1/device/sso-complete — SSO callback sink
GET /v1/oauth/device/approval-context — /device cookie probe
POST /v1/oauth/device/approve-external — SSO approve
GET /v1/me — bearer subject lookup
DELETE /v1/oauth/authorizations/self — self-revoke
POST /console/api/oauth/device/approve — account approve
POST /console/api/oauth/device/deny — account deny
Core primitives:
- libs/oauth_bearer.py: prefix-keyed TokenKindRegistry +
BearerAuthenticator + validate_bearer decorator. Two-tier scope
(full vs apps:run) stamped from the registry, never from the DB.
- libs/jws.py: HS256 compact JWS keyed on the shared Dify
SECRET_KEY — same key-set verifies the SSOState envelope, the
external-subject assertion (minted by Enterprise), and the
approval-grant cookie.
- libs/device_flow_security.py: enterprise_only gate, approval-
grant cookie mint/verify/consume (Path=/v1/oauth/device,
HttpOnly, SameSite=Lax, Secure follows is_secure()), anti-
framing headers.
- libs/rate_limit.py: typed RateLimit / RateLimitScope dispatch
with composite-key buckets; both decorator + imperative form.
- services/oauth_device_flow.py: Redis state machine (PENDING ->
APPROVED|DENIED with atomic consume-on-poll), token mint via
partial unique index uq_oauth_active_per_device (rotates in
place), env-driven TTL policy.
Storage: oauth_access_tokens table with partial unique index on
(subject_email, subject_issuer, client_id, device_label) WHERE
revoked_at IS NULL. account_id NULL distinguishes external-SSO
rows. Hard-expire is CAS UPDATE (revoked_at + nullify token_hash)
so audit events keep their token_id. Retention pruner DELETEs
revoked + zombie-expired rows past OAUTH_ACCESS_TOKEN_RETENTION_DAYS.
Frontend: /device page with code-entry, chooser (account vs SSO),
authorize-account, authorize-sso views. SSO branch detaches from
the URL user_code and reads everything from the cookie via
/approval-context. Anti-framing headers on all responses.
Wiring: ENABLE_OAUTH_BEARER feature flag; ext_oauth_bearer binds
the authenticator at startup; clean_oauth_access_tokens_task
scheduled in ext_celery.
Spec: docs/specs/v1.0/server/{device-flow,tokens,middleware,security}.md
Dify Frontend
This is a Next.js project, but you can dev with vinext.
Getting Started
Run by source code
Before starting the web frontend service, please make sure the following environment is ready.
You can also use Vite+ with the corresponding vp commands.
For example, use vp install instead of pnpm install and vp test instead of pnpm run test.
Tip
It is recommended to install and enable Corepack to manage package manager versions automatically:
npm install -g corepack corepack enableLearn more: Corepack
Run the following commands from the repository root.
First, install the dependencies:
pnpm install
Note
JavaScript dependencies are managed by the workspace files at the repository root:
package.json,pnpm-lock.yaml,pnpm-workspace.yaml, and.nvmrc. Install dependencies from the repository root, then run frontend scripts fromweb/.
Then, configure the environment variables.
Create web/.env.local and copy the contents from web/.env.example.
Modify the values of these environment variables according to your requirements:
cp web/.env.example web/.env.local
Important
- When the frontend and backend run on different subdomains, set NEXT_PUBLIC_COOKIE_DOMAIN=1. The frontend and backend must be under the same top-level domain in order to share authentication cookies.
- It's necessary to set NEXT_PUBLIC_API_PREFIX and NEXT_PUBLIC_PUBLIC_API_PREFIX to the correct backend API URL.
Finally, run the development server:
pnpm -C web run dev
# or if you are using vinext which provides a better development experience
pnpm -C web run dev:vinext
# (optional) start the dev proxy server so that you can use online API in development
pnpm -C web run dev:proxy
Open http://localhost:3000 with your browser to see the result.
You can start editing the files under web/app.
The page auto-updates as you edit the file.
Deploy
Deploy on server
First, build the app for production:
pnpm -C web run build
Then, start the server:
pnpm -C web run start
If you build the Docker image manually, use the repository root as the build context:
docker build -f web/Dockerfile -t dify-web .
If you want to customize the host and port:
pnpm -C web run start --port=3001 --host=0.0.0.0
Storybook
This project uses Storybook for UI component development.
To start the storybook server, run:
pnpm -C web storybook
Open http://localhost:6006 with your browser to see the result.
Lint Code
If your IDE is VSCode, rename .vscode/settings.example.json to .vscode/settings.json for lint code setting.
Then follow the Lint Documentation to lint the code.
Test
We use Vitest and React Testing Library for Unit Testing.
📖 Complete Testing Guide: See web/docs/test.md for detailed testing specifications, best practices, and examples.
Important
As we are using Vite+, the
vitestcommand is not available. Please make sure to run tests withvpcommands. For example, usenpx vp testinstead ofnpx vitest.
Run test:
pnpm -C web test
Note
Our test is not fully stable yet, and we are actively working on improving it. If you encounter test failures only in CI but not locally, please feel free to ignore them and report the issue to us. You can try to re-run the test in CI, and it may pass successfully.
Example Code
If you are not familiar with writing tests, refer to:
- index.spec.tsx - Component test example
Analyze Component Complexity
Before writing tests, use the script to analyze component complexity:
pnpm analyze-component app/components/your-component/index.tsx
This will help you determine the testing strategy. See [web/testing/testing.md] for details.
Documentation
Visit https://docs.dify.ai to view the full documentation.
Community
The Dify community can be found on Discord community, where you can ask questions, voice ideas, and share your projects.