Files
zitadel/internal/api/grpc/user
f3dcfa3db6 Merge commit from fork
* fix(security): check auth method permission on the user's organization

ListUserAuthMethodTypes checked user.read against the caller's own
organization instead of the organization owning the requested user. Any
org level role holding user.read - ORG_OWNER, ORG_OWNER_VIEWER - therefore
passed the check for every user of the instance, and the query itself
filters on instance and user id only, so it returned that user's
authentication methods across the organization boundary.

Resolve the requested user first and check the permission on its resource
owner, the same resolution GetUserByIDWithPermission already uses.

This covers both the v2 and v2beta ListAuthenticationMethodTypes handlers,
which share this function. The two login UI callers scope the context to
the user itself, so they keep skipping the check and pay no extra query.

Note that a request for a non existing user id now returns NotFound
instead of an empty list, which also removes an existence oracle.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MeUQhL2hxvnYbPn3qhWJAL

* test(user/v2): cover cross-organization auth method enumeration

TestServer_ListAuthenticationMethodTypes_CrossOrg fails without the
preceding fix: an ORG_OWNER and an ORG_OWNER_VIEWER of one organization
could list the authentication methods of a user of another organization,
leaking AUTHENTICATION_METHOD_TYPE_PASSWORD.

The two own-org subtests are positive controls, not decoration.
Memberships and auth methods are projected asynchronously, so without them
a denial could pass for the wrong reason - a membership that has not been
projected yet. The IAM_USER_MANAGER subtest pins that instance wide
user.read keeps working across organizations, so the fix narrows the
organization without narrowing the role set.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MeUQhL2hxvnYbPn3qhWJAL

---------

Co-authored-by: Claude Opus 5 <[email protected]>
2026-09-04 05:57:02 +02:00
..
2026-09-04 05:57:02 +02:00