bug: DingTalk web connector drops corpId from the access-token response

Describe the bug

The DingTalk web connector drops corpId returned by DingTalk's access-token endpoint before constructing the social user information.

At upstream commit a2d6e83a4f769b79900e1a34f373d96c751faa47 (@logto/connector-dingtalk-web version 0.4.6):

• accessTokenResponseGuard already accepts an optional corpId.
• getAccessToken() extracts and returns only accessToken, discarding corpId.
• getUserInfo() returns rawData from the separate user-info response without carrying over the corporation ID from the token response.

Consequently, even when DingTalk supplies corpId, that value does not reach the social identity details through this connector. Applications that need the corporation identifier cannot retrieve it from those details.

Expected behavior

When the token response includes corpId, preserve it in the returned social user information, for example as rawData.corpId, alongside the original user-info fields.

When corpId is absent, preserve the existing behavior. Access and refresh tokens should not be copied into rawData.

This request concerns retaining provider metadata; it does not request automatic organization assignment or additional token claims.

How to reproduce?

This is reproducible with the connector's existing mocked HTTP tests; no live DingTalk credentials are needed.

1. Check out upstream commit a2d6e83a4f769b79900e1a34f373d96c751faa47 and prepare the connector's workspace dependencies.

2. In packages/connectors/connector-dingtalk-web/src/index.test.ts, use the existing token-response fixture, which already includes accessToken: 'accessToken' and corpId: 'corpId'.

3. Strengthen the getAccessToken test to assert the complete result:

   typescript复制

   expect(await getAccessToken('code', mockedConfig)).toStrictEqual({
     accessToken: 'accessToken',
     corpId: 'corpId',
   });

   It fails because the actual result contains only accessToken.

4. In the existing valid getUserInfo test, expect corpId: 'corpId' inside rawData. This also fails because the returned rawData contains only the user-info response fields.

5. Run the connector tests with pnpm exec vitest run src --globals from the connector directory.

Both regression assertions failed on the original implementation. With the proposed fix, all 7 connector tests pass, including a case verifying that an absent corpId leaves the user-info data unchanged and retains additional provider fields.

I am willing to contribute the fix. The implementation and tests are available for discussion here: https://github.com/renyijiu/logto/commit/5090fb3

Environment

Self-hosted (Node.js) — reproduced locally against the source code using mocked HTTP responses, not an end-to-end DingTalk sign-in.

• Upstream commit: a2d6e83a4f769b79900e1a34f373d96c751faa47
• Connector: @logto/[email protected]
• Local test runtime: Node.js 26.5.1, pnpm 10.34.5, Vitest 4.1.8
• The project specifies Node.js ^22.14.0; the local test runtime above differs from that requirement.

Screenshots

Not applicable; the reproduction is covered by assertions on the connector's returned data.