Enterprise OAuth2/OIDC (Hydra + MFA) integration with DolphinScheduler – state issue and best-practice guidance needed #17886
Unanswered
GulshanMishra321
asked this question in
Q&A
Replies: 1 comment
-
|
Regarding the OIDC integration you mentioned, the latest dev branch currently offers full support. You may try integrating OIDC using the most recent dev version for testing. Additionally, we plan to officially release version 3.4.0 within the next week, and you are also welcome to upgrade and try it then. You can refer to the following PR and documentation links for OIDC-related implementation and configuration: If you encounter any issues during the integration process, please feel free to reach out to us with your feedback. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello Community,
We are evaluating Apache DolphinScheduler 3.x (binary deployment) for integration with our enterprise IDAM, which is based on OAuth2 / OpenID Connect (Hydra) with MFA enabled.
Our objective is to enable secure SSO with MFA in a way that is stable, upgrade-safe, and aligned with enterprise best practices. Below is what we have tried, the issues we are facing, and what we are trying to achieve.
⸻
🔹 Environment
• DolphinScheduler version: 3.x (tested on 3.3.x)
• Deployment type: Binary (API + Master on VM)
• IDAM: OAuth2 / OIDC (Hydra)
• MFA: Enabled at IDAM level
• Requirement: Enterprise SSO, CSRF protection, minimal custom code
⸻
🔹 What We Have Tried
• Used DolphinScheduler’s inbuilt OAuth2/OIDC configuration
• Configured authorization, token, and userinfo endpoints
• Tested authorization code flow with redirect and callback
• Tested with MFA enabled on IDAM side
⸻
🔹 Issues Observed
1. OAuth2 state handling issue
• state parameter (CSRF protection) is not reliably persisted or validated
• Callback sometimes fails even after successful IDAM authentication
• Redirect flow becomes unstable
2. Incomplete enterprise OAuth2 / OIDC behavior
• OIDC support appears limited
• MFA flow is not clearly or reliably handled
• No silent / auto-login experience
3. No automatic (JIT) user provisioning
• Users must be pre-created in Dolphin
• No native support for auto user creation on first login
• No built-in role / tenant mapping from IDAM claims
4. Upgrade & maintenance concerns
• Fixing OAuth issues appears to require code or JAR-level changes
• Such changes are not upgrade-safe and increase operational risk
⸻
🔹 What We Are Trying to Achieve
• Enterprise-grade SSO with OAuth2 / OIDC
• MFA enforced by IDAM
• Proper CSRF protection (state)
• Stable redirect and login behavior
• No risky or unsupported code changes in Dolphin
• A clean approach for user provisioning and role/tenant assignment
⸻
🔹 Questions to the Community
1. Is DolphinScheduler’s inbuilt OAuth2/OIDC intended for enterprise-grade IDAM + MFA, or mainly for simpler SSO scenarios?
2. Are the OAuth2 state and redirect issues known limitations in the current design?
3. Is there an officially recommended approach for integrating DolphinScheduler with enterprise IDAM systems?
4. Is externalizing authentication (e.g., using a reverse proxy / API gateway like Kong in front of Dolphin) considered a best practice?
5. What is the recommended approach for user provisioning and role/tenant mapping in SSO scenarios?
Any guidance, best practices, or reference architectures from the community would be greatly appreciated.
Thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions