Unreported flaky test detected, please review

@hemmerlein thanks a lot for working on this — the feature is useful and the overall structure is clean. A few things I'd like to discuss before this merges:

1. Organization redirect URL is not validated against a custom client

Today, the org's redirectUrl is used as-is with the account-management client — that's fine because it's an admin-configured value targeting a known client. But with this PR, a caller can now specify client_id=my-app without a redirect_uri, and resolveRedirectUri will still return the org's redirect URL without verifying it against my-app's registered redirect URIs:

  if (!StringUtil.isBlank(organization.getRedirectUrl())) {
      return organization.getRedirectUrl();
  }

The token handler (InviteOrgActionTokenHandler.handleToken()) doesn't re-validate either — it just redirects:

  if (redirectUri != null) {
      return Response.status(Status.FOUND).location(URI.create(redirectUri)).build();
  }

This means the token gets minted with clientId=my-app and a redirect URI that may not be registered for that client. I think the org redirect URL should either be validated against the specified client via RedirectUtils.verifyRedirectUri, or be skipped entirely when a custom client_id is provided.

2. PR description says redirect_uri without client_id returns 400

The description states: "redirect_uri without client_id → returns 400". But resolveInvitationTarget silently defaults to account-management:

  clientId = StringUtil.isBlank(clientId) ? Constants.ACCOUNT_MANAGEMENT_CLIENT_ID : clientId.trim();

So if someone passes redirect_uri=https://example.com without client_id, it validates the URI against the account client. The execute-actions-email endpoint (which the description says this mirrors) rejects that combination explicitly. Should this match? @pedroigor wdyt?

3. resolveRedirectUri can return null

Today, the redirect URI in the token is never null — there's always the Urls.accountBase(...) fallback. The PR's new cascade can return null for a custom client that has no base URL and no single registered redirect URI, because the account-management fallback is now conditional:

  if (Constants.ACCOUNT_MANAGEMENT_CLIENT_ID.equals(client.getClientId())) {
      return Urls.accountBase(...).path("/").build(realm.getName()).toString();
  }
  return null;

When the token has a null redirect URI, handleToken() skips the redirect entirely. Depending on the flow this might be fine, but it's a silent behavioral change. What if we return a 400 from resolveInvitationTarget when the redirect URI can't be determined, rather than minting a token with no redirect?

4. Missing test coverage

Please consider adding tests for:

• redirect_uri without client_id — no test for this, and the actual behavior differs from the description
• New user registration with custom client_id only (no redirect_uri) — the existing-user path has this test but the registration path doesn't
• Custom client_id with org redirect URL configured — exercises the unvalidated fallback from point 1

Pull request overview

This PR extends organization invitation flows to support optional client_id and redirect_uri parameters, validating them server-side and propagating them through admin clients and tests.

Changes:

• Add client_id/redirect_uri query params to the organization member invite endpoint and token/link generation.
• Validate client existence/enabled state and verify redirect URIs when provided, with updated error handling.
• Update Java/TypeScript admin clients and add integration tests covering new scenarios.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Thank you for the PR.

There are lots of reports on unstable tests, and it seems to me that those reported unstable tests have been added or changed in this PR. Please review and rework if necessary.

@hemmerlein thanks a lot for the changes

As @ahus1 pointed out there are unstable tests. I've checked it out and the reason is that there is interference between the test methods.

The issue is in testInviteNewUserRegistrationCustomRegistrationFlow (line 400-402). The cleanup sets the registration flow back on the local RealmRepresentation object but never calls update() to push the change to the server, could you change:

  getCleanup().addCleanup(() -> {
      realm.setRegistrationFlow(DefaultAuthenticationFlows.REGISTRATION_FLOW);
  });

to

  getCleanup().addCleanup(() -> {
      realm.setRegistrationFlow(DefaultAuthenticationFlows.REGISTRATION_FLOW);
      managedRealm.admin().update(realm);
  });

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

We need to do an internal security review on this one. This might take a while. Therefore I ask for your patience.

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

        String defaultRedirectUri = RedirectUtils.verifyRedirectUri(session, null, client, false);

        if (defaultRedirectUri != null) {
            return defaultRedirectUri;

        InvitationTarget invitationTarget = resolveInvitationTarget(clientId);

        if (!client.isEnabled()) {
            throw ErrorResponse.error("Client is not enabled", Status.BAD_REQUEST);
        }

        return new InvitationTarget(client.getClientId(), resolveRedirectUri(client));

        return OIDCLoginProtocolService.registrationsUrl(session.getContext().getUri().getBaseUriBuilder())
                .queryParam(OAuth2Constants.RESPONSE_TYPE, OIDCResponseType.CODE)
                .queryParam(Constants.CLIENT_ID, invitationTarget.clientId)
                .queryParam(Constants.TOKEN, createToken(user, invitation, invitationTarget))

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

                .queryParam(Constants.CLIENT_ID, invitationTarget.clientId)
                .queryParam(Constants.TOKEN, createToken(user, invitation, invitationTarget))