mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-18 05:52:51 +00:00
jmaretteandGitHub
f34cc45eac
# Which Problems Are Solved ZITADEL cannot currently be used as an OAuth 2.0 Authorization Server by clients that need to register themselves at runtime: - There is no [OAuth 2.0 Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) endpoint, and no `registration_endpoint` is advertised in the discovery document. - This blocks [Model Context Protocol (MCP)](https://modelcontextprotocol.io) clients (Claude Desktop, claude.ai, Cursor, the MCP SDKs), whose OAuth 2.1 authorization profile expects an Authorization Server that supports dynamic client registration. They self-register before any user context exists and only then start the authorization code + PKCE flow. # How the Problems Are Solved ## Control plane: instance security settings No feature flag and no runtime config. A `DynamicClientRegistrationSettings` message is nested under the instance `SecuritySettings` in `settings/v2`, next to `embedded_iframe` and `enable_impersonation`: | `enabled` | `allow_unauthenticated` | Behaviour | | --- | --- | --- | | `false` (default) | — | `POST /oauth/v2/register` returns `404`, `registration_endpoint` absent from discovery | | `true` | `false` (default) | Token-gated registration, client homed in the token's organization | | `true` | `true` | Open registration for MCP hosts, client homed in the instance default organization | Both values are carried on `authz.Instance` and loaded with the instance, exactly like `EnableImpersonation`, so the discovery document and the endpoint read them per request without an extra query. `allow_unauthenticated` implies `enabled` in both implementations, so a single setting closes the endpoint. Adding the two columns bumps the projection table to `projections.security_policies3`, following what the impersonation setting did for `security_policies2`. ## Authorization: a dedicated permission, not `project.app.write` - New org-scoped permission **`project.app.register_dynamic`**, granted by default to `ORG_OWNER`, `IAM_OWNER` and `IAM_ORG_MANAGER` — in both `InternalAuthZ` and `SystemAuthZ`, mirroring where `project.app.write` already lives. - New built-in role **`ORG_DYNAMIC_CLIENT_REGISTRAR`** carrying only that permission, so a service user can self-register clients without gaining write access to the organization's existing applications. - Open mode (`allow_unauthenticated = true`) requires no token and no permission: that is the MCP self-register path. - A valid token whose user lacks the permission is answered with **`403 insufficient_scope`** (RFC 6750 §3.1) rather than `401 invalid_token`, so a caller can tell "your token is bad" from "your token may not do this". `verifyAccessToken` also reports invalid tokens as permission denied, so the authorization failure is marked explicitly to keep the two apart. The check runs once, at the endpoint, right after the token is verified and before any state is created, so it also gates the auto-provisioning of the organization's DCR project. The permission itself lives in the command layer next to the others (`Commands.CheckPermissionRegisterDynamicClient`). As the OIDC endpoints are not behind the authorization interceptor, the caller identity is derived from the verified token, the way token exchange does for the impersonating actor. ## Registration itself - **Registered clients are ordinary OIDC applications.** The endpoint reuses the existing application-creation events (`NewApplicationAddedEvent` and `NewOIDCConfigAddedEvent`), so the whole token, authorization and introspection flow keeps working unchanged. They are stored in a dedicated, auto-provisioned project named `ZITADEL DCR` per organization (name lookup), so they do not pollute the `IAMProject` or other projects. - Input is validated with the existing `GetOIDCV1Compliance` rules; `private_key_jwt` and `jwks`/`jwks_uri` are rejected with `invalid_client_metadata`. - **Endpoint wiring without forking the library.** `NewServer` calls `op.RegisterServer` instead of `op.RegisterLegacyServer`, so the new route can be added through the same `op.WithSetRouter` hook as the authorize callback. `op.RegisterLegacyServer` appends a middleware after the caller options, which chi forbids once a route has been registered; `op.NewIssuerInterceptor` reproduces the issuer middleware it would otherwise add. The `/oauth/v2` routing prefix is unchanged. # Additional Changes - **`application_type` inference for custom-scheme redirects** (last commit, isolated). `application_type` is an OpenID Connect member; RFC 7591 does not define it, so clients that only implement RFC 7591 omit it. Native MCP hosts doing so register custom-scheme redirect URIs, which ZITADEL reserves for native applications, and the OIDC default of `web` rejected them with `invalid_redirect_uri`. Inference is limited to custom schemes and to an absent `application_type`, so every request accepted today keeps its current application type and auth method — an `http` loopback redirect still yields a web application. Happy to drop this commit if you would rather keep it out of this PR. - **Docs**: a Dynamic Client Registration integration guide, a `registration_endpoint` section on the OpenID Connect endpoints page, and the new role in the administrators table (plus its description in the Console translations). # Additional Context - Part of #9810. This is **Phase 1 (DCR)**; #12315 adds RFC 7592 and #12316 adds CIMD, both stacked on this branch and rebased once this lands. - Implements the control-plane and authorization model requested in the review of this PR, itself a refinement of the direction in https://github.com/zitadel/zitadel/issues/9810#issuecomment-4891176997. - **Out of scope (deliberately)**: RFC 7592, CIMD, persisting free-form metadata (`logo_uri`, `contacts`, and similar), and `private_key_jwt` / `jwks_uri` (rejected cleanly). No new event types. - Follow-ups explicitly left out, per the review: DCR client lifecycle and richer audit, consent and custom scopes, JWT / `aud` (RFC 8707), and RFC 8414 AS metadata (currently absent from both ZITADEL and `zitadel/oidc`).
Zitadel Management Console
The Management Console is Zitadel's management UI.
It is built using Angular and part of the Zitadel monorepo.
To get started follow the contributing quick start.
Building
To build for production:
pnpm nx run @zitadel/console:build
This will:
- Generate proto files (via
prebuildscript) - Build the Angular app with production optimizations
Linting
To run linting and formatting checks:
pnpm nx @zitadel/console:lint
To auto-fix formatting issues:
pnpm nx @zitadel/console:lint-fix
Project Structure
src/app/proto/generated/- Generated proto files (Angular-specific format)buf.gen.yaml- Local proto generation configurationproject.json- Nx orchestration and caching for builds and testsprebuild.development.js- Development environment settings script
Dependency Chain
The Management Console app has the following build dependencies managed by Nx:
@zitadel/proto:generate- Generates the protobuf stubs@zitadel/client:build- Builds the TypeScript gRPC client library@zitadel/console:generate- Generates Management Console-specific protobuf stubs@zitadel/console:build- Creates a production build from Management Console
This ensures that the Management Console always has access to the latest client library and protobuf definitions.
Proto Generation Details
@zitadel/protogeneration: Modern ES modules with@bufbuild/protobuffor v2 APIs- Local
buf.gen.yamlgeneration: Traditional protobuf JavaScript classes for v1 APIs
The Management Console app calls Zitadel v1 and v2 APIs. As long as the Management Console still calls v1 APIs, it needs to import client stubs from separate sources:
Legacy v1 API (Traditional Protobuf)
- Uses local
buf.gen.yamlconfiguration - Generates traditional Google protobuf JavaScript classes extending
jspb.Message - Uses plugins:
protocolbuffers/js,grpc/web,grpc-ecosystem/openapiv2 - Output:
src/app/proto/generated/ - Used for: Most existing Management Console functionality
Modern v2 API (ES Modules)
- Uses
@zitadel/protopackage generation - Generates modern ES modules with
@bufbuild/protobuf - Uses plugin:
@bufbuild/eswith ES modules and JSON types - Output:
login/packages/zitadel-proto/ - Used for: New user v2 API and services
Dependency Management
The Management Console's project.json ensures proper execution order:
@zitadel/proto:generateruns first (modern ES modules)- Management Console's local generation runs second (traditional protobuf)
- Build/lint/start tasks depend on both generations being complete
This approach allows the Management Console app to use both v1 and v2 APIs while maintaining proper build dependencies.
Legacy Information
This project was originally generated with Angular CLI version 8.3.20 and has been updated over time.