Motivation
Some enterprise SkillHub deployments use DingTalk as their primary identity provider. Adding an optional DingTalk OAuth login provider would make self-hosted deployments easier to adopt in DingTalk-centered organizations while preserving the existing GitHub/GitLab OAuth, local account, mock auth, API token, and session flows.
Proposed scope
- Add a
dingtalk OAuth provider that is disabled unless explicitly configured.
- Reuse the existing Spring Security OAuth2 login flow, including state validation, success/failure handlers, session establishment, RBAC principal construction, and audit/session behavior.
- Reuse the existing identity mapping model:
identity_binding(provider_code, subject) remains the unique external identity key.
- Map DingTalk user identity using the most stable returned identifier available, preferring
unionId, then openId, then userId when applicable.
- Do not assume DingTalk always returns email. Treat email/mobile as optional profile fields, not primary identity keys.
- Surface the provider through the existing auth method/provider discovery so the frontend can render the login entry dynamically.
- Document runtime configuration for local, Docker/Compose, and Kubernetes deployments.
Out of scope
- No company-specific intranet configuration, tenant-specific organization rules, or real credentials in the repository.
- No DingTalk contact synchronization, department-to-namespace automation, approval workflow, robot notification, mobile-only H5 login, or internal deployment scripts.
- No replacement of existing authentication mechanisms.
Implementation direction
Current code already has the main extension points needed:
CustomOAuth2UserService delegates OAuth login to OAuthLoginFlowService.OAuthClaimsExtractor handles provider-specific profile mapping.IdentityBindingService binds or creates platform users from normalized OAuth claims.AccountMergeService can consolidate identity bindings, API tokens, roles, namespace memberships, and local credentials./api/v1/auth/methods and /api/v1/auth/providers already advertise configured OAuth methods to the frontend.
The minimal contribution would add DingTalk-specific provider configuration and claims extraction/token-userinfo adaptation while keeping provider-specific logic behind the existing auth extension points.
Rollout and security
- Default behavior remains unchanged unless the DingTalk client registration is configured.
client_id, client_secret, and tenant/app-specific values must be injected by environment variables or Kubernetes Secrets.- CI tests should mock DingTalk endpoints and must not depend on real DingTalk network credentials.
- Sensitive tokens and secrets must not be logged.
If this direction looks acceptable, I can prepare a focused PR for the provider, tests, frontend entry behavior if needed, and deployment documentation.
Motivation
Some enterprise SkillHub deployments use DingTalk as their primary identity provider. Adding an optional DingTalk OAuth login provider would make self-hosted deployments easier to adopt in DingTalk-centered organizations while preserving the existing GitHub/GitLab OAuth, local account, mock auth, API token, and session flows.
Proposed scope
dingtalkOAuth provider that is disabled unless explicitly configured.identity_binding(provider_code, subject)remains the unique external identity key.unionId, thenopenId, thenuserIdwhen applicable.Out of scope
Implementation direction
Current code already has the main extension points needed:
CustomOAuth2UserServicedelegates OAuth login toOAuthLoginFlowService.OAuthClaimsExtractorhandles provider-specific profile mapping.IdentityBindingServicebinds or creates platform users from normalized OAuth claims.AccountMergeServicecan consolidate identity bindings, API tokens, roles, namespace memberships, and local credentials./api/v1/auth/methodsand/api/v1/auth/providersalready advertise configured OAuth methods to the frontend.The minimal contribution would add DingTalk-specific provider configuration and claims extraction/token-userinfo adaptation while keeping provider-specific logic behind the existing auth extension points.
Rollout and security
client_id,client_secret, and tenant/app-specific values must be injected by environment variables or Kubernetes Secrets.If this direction looks acceptable, I can prepare a focused PR for the provider, tests, frontend entry behavior if needed, and deployment documentation.