5 Commits

Include renames

Author	SHA1	Message	Date
jmaretteandGitHub	f34cc45eac	feat(oidc): add RFC 7591 dynamic client registration (#12313) ... # 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`).	2026-07-30 14:43:47 +00:00
Livio SpringandGitHub	1e0b810dca	feat: allow managing invite code in secret generators (#12109) ... # Which Problems Are Solved Zitadel exposes the secrets generator configuration through its admin api. This allows instance admins to manage them on their own and they can create overwrite the system / runtime defaults (incl. expiration). This very much needed in multi-instance scenarios such as zitadel.cloud. Currently the invite code configuration was not manageable through the API, but only runtime config. # How the Problems Are Solved - added the `invite_code` type to the API allowing it to be set and retrieved. - added the type to console's management list - added the type to be stored on instance setup - change the `GetSecretGenerator` endpoint to fall back to the runtime config if no config is stored on the instance itself - ensure the `length` and at least one charset is enabled, return an error otherwise - expiry is not enforced, so 0 allows codes with no expiry (current state) # Additional Changes None # Additional Context - closes https://github.com/zitadel/zitadel/issues/10474	2026-07-01 04:53:16 +00:00
4 people	3903355d18	feat(settings): add secret generator type to settings RT implementation (#11152) ... # Which Problems Are Solved The `SecretGenerators` setting is missing among the instance settings in the new relational model. # How the Problems Are Solved This PR adds: * `SettingTypeSecretGenerator` type to the settings model * `SecretGeneratorSettingsRepository` and `secretGeneratorSettingsJSONChanges` interfaces to set, retrieve, and delete `secret_generator` settings, and corresponding unit tests. * projection reducers to reduce the following events: * `SecretGeneratorAddedEvent` * `SecretGeneratorChangedEvent` * `SecretGeneratorRemovedEvent` * integration tests to test that the events get reduced correctly # Additional Changes N/A # Additional Context - Part of https://github.com/zitadel/zitadel/issues/10207 --------- Co-authored-by: Copilot <[email protected]> Co-authored-by: Marco A. <[email protected]>	2025-12-11 12:33:19 +01:00
3 people	b4732579cb	fix(RT): correct restricting null columns (#11123) ... # Which Problems Are Solved `IS NULL` and `IS NOT NULL` conditions were incorrectly marked as restricting columns, and currently fails unit tests. The restricting columns are mostly used to ensure single row selection during DELETE and UPDATE . When a `IS NOT NULL` condition is passed, the filter may (unintentionally) apply to all rows, while still allowing the query to execute. Settings and other repositories (still to be done) have unified tables for instance-level settings and organization-level settings. In those cases the organization ID may be null or have a value. The unique condition is a compound of multiple columns, in which case `IS NULL` is valid as part of the other restricting columns. # How the Problems Are Solved In order to prevent unsafe usage of null related filters and not break settings: - null conditions are no longer considered restricting columns - A function to force the restricting column state on a condition is provided - The settings unique condition function forces restricting column state on the returned condition. # Additional Changes - add `backend/v3` to the NX build. # Additional Context - [pipeline failures](https://github.com/zitadel/zitadel/actions/runs/19852295780/job/56881654340?pr=11115#step:13:3197) --------- Co-authored-by: Elio Bischof <[email protected]>	2025-12-03 16:15:49 +00:00
6 people	911967c865	feat(settings_relational): adding settings table for relational db (#10769) ... # Which Problems Are Solved As part of https://github.com/zitadel/zitadel/issues/9599 to push to move to a relational db table model, this is the migration of the settings # Additional Changes I had to add 2 non source code files `backend/v3/storage/database/events_testing/font.otf` and `backend/v3/storage/database/events_testing/picture.png`, these are used as part of the reduce tests, hence why they're sourced inside `backend/v3/storage/database/events_testing/settings_instance_test.go` - Closes https://github.com/zitadel/zitadel/issues/10207 --------- Co-authored-by: adlerhurst <[email protected]> Co-authored-by: Copilot <[email protected]> Co-authored-by: Tim Möhlmann <[email protected]> Co-authored-by: Stefan Benz <[email protected]>	2025-12-02 08:16:21 +01:00