Casdoor OIDC Integration Fails with "Unknown authentication type" Error (OD-2529)
biankasyo opened 5 months ago

Description:
I'm trying to configure single sign-on (SSO) in OneDev using Casdoor as the OIDC provider, but encountering an authentication error. The configuration appears correct but fails during the login attempt.

Current Configuration:
OneDev SSO Provider Type: OpenID
Discovery URL: https://xxxx.com/.well-known/openid-configuration
Requested scopes: openid email profile
Callback URL: https://onedev.xxxx.com/~sso/callback/casdoor

Error Message from Casdoor:

Login encountered a problem... Unknown authentication type (not password or third-party provider): {"type":"unknown",...}

未知的认证类型(非密码或第三方提供商): {"type":"unknown","signinMethod":"","organization":"","username":"","password":"","name":"","firstName":"","lastName":"","gender":"","bio":"","tag":"","education":"","email":"","phone":"","affiliation":"","idCard":"","language":"","region":"","invitationCode":"","application":"","clientId":"","provider":"","providerBack":"","code":"cKTrL509yeF14Df4995ayFA6HA8CaK3E","state":"","redirectUri":"https://casdoor.internal.kurflo.com/callback","method":"","emailCode":"","phoneCode":"","countryCode":"","autoSignin":false,"relayState":"","samlRequest":"","samlResponse":"","captchaType":"","captchaToken":"","clientSecret":"","mfaType":"","passcode":"","recoveryCode":"","enableMfaRemember":false,"plan":"","pricing":"","faceId":null,"faceIdImage":null,"userCode":""}

Additional Context:
1.The same Casdoor OIDC configuration works perfectly with other applications like Outline
2.The discovery document is properly accessible and contains all required endpoints
3.Redirect URIs match between OneDev and Casdoor application settings

Suspected Issue:
The problem might be related to:
1.Incorrect handling of the authorization code flow by OneDev
2.Mismatch in expected request parameters between OneDev and Casdoor's implementation
3.Potential redirect_uri validation issue

Request: Could the OneDev team investigate and add proper support for Casdoor's OIDC implementation? Many thanks for your attention to this matter.

image.pngimage_2.pngimage_3.png

  • Robin Shen commented 5 months ago

    Just set up a local casdoor instance with simplest settings (just add an organization, an app, and a user), and OneDev works fine with it.

  • biankasyo commented 5 months ago

    Just set up a local casdoor instance with simplest settings (just add an organization, an app, and a user), and OneDev works fine with it.

    @robin Thank you for testing with a basic Casdoor setup. I've conducted additional testing and found that the issue occurs specifically when Casdoor is configured with third-party providers (like Feishu/Lark).

    Login Flow with Third-party Provider:

    1. User accesses OneDev
    2. Redirected to Casdoor login page (https://casdoor.../login)
    3. User clicks "Feishu Login" button on Casdoor page
    4. Redirected to Feishu for authorization
    5. After Feishu authorization, redirects back to Casdoor's callback endpoint
    6. Casdoor establishes server session, marking browser as authenticated
    7. Casdoor redirects back to OneDev's callback URL (https://onedev.internal.kurflo.com/~sso/callback/casdoor)

    Issue Analysis:
    The problem appears to be in steps 6-7. The OAuth flow uses the state parameter for CSRF protection. OneDev generates a state when initiating login and expects the exact same state in the callback.

    The callback URL from Feishu to Casdoor contains this structure:

    https://casdoor.internal.kurflo.com/callback?code=bGPqxe2cJ1zaA0ad945ddF7b1dA01ezB&state=P3Jlc3BvbnNlX3R5cGU9Y29kZSZjbGllbnRfaWQ9ZjI0NGY3N2M3NWI1MzllOWRkNzAmcmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGbG9iZWNoYXQuaW50ZXJuYWwua3VyZmxvLmNvbSUyRmFwaSUyRmF1dGglMkZjYWxsYmFjayUyRmNhc2Rvb3Imc2NvcGU9b3BlbmlkK3Byb2ZpbGUrZW1haWwmY29kZV9jaGFsbGVuZ2U9cjdva3dsOEhHTFQ5YkxnUnJseWpPT2NNb21qbjVEVzRLMXQ3ckM1SE5rUSZjb2RlX2NoYWxsZW5nZV9tZXRob2Q9UzI1NiZhcHBsaWNhdGlvbj1sb2JlY2hhdF9sb2dpbiZwcm92aWRlcj1mZWlzaHUmbWV0aG9kPXNpZ251cA%3D%3D
    

    When Base64-decoded, the state parameter reveals OneDev's original callback details and expected parameters.

    Potential Issues:

    1. Session Management: OneDev's session handling during the callback phase might be inconsistent - the session that generated the state might differ from the one validating it
    2. State Parameter Handling: The state parameter might not be properly preserved or reconstructed through the multi-step OAuth flow involving third-party providers
    3. Callback Validation: OneDev might be rejecting valid callbacks due to strict state validation that doesn't account for third-party provider workflows

    Request:
    Could you please investigate how OneDev handles state validation in multi-step OAuth flows? The issue seems to be that when using third-party providers through Casdoor, the state parameter management needs special consideration.

    Thank you for your continued support in resolving this integration challenge. image_4.png

  • Robin Shen commented 4 months ago

    I configured casdoor to authenticate via GitHub, and both OneDev/Gitea can work without any issues. However when set up feishu/lark. It always complains about "the user's owner and name should not be empty". I don't think this is a OneDev issue.

  • Robin Shen changed state to 'Closed' 4 months ago
    Previous Value Current Value
    Open
    Closed
  • biankasyo commented 4 months ago

    I configured casdoor to authenticate via GitHub, and both OneDev/Gitea can work without any issues. However when set up feishu/lark. It always complains about "the user's owner and name should not be empty". I don't think this is a OneDev issue.

    @robin Hi Robin,

    Thank you for testing with GitHub authentication and confirming that it works correctly. Regarding the "the user's owner and name should not be empty" error when using Feishu/Lark, this appears to be a Casdoor configuration issue.

    Based on our experience integrating Casdoor with Feishu for other applications (including alist, lowcoder, outline, and lobechat), this error typically occurs when:

    1. The Feishu developer platform hasn't properly enabled the required application permissions
    2. There are issues with the redirect URI configuration in Feishu's settings

    You might find this reference helpful for configuring Casdoor with Feishu: https://blog.sleepstars.net/archives/alist-da-pei-casdoor-zhi-chi-fei-shu-dan-dian-deng-lu (particularly steps 5-6).

    If you'd like, I can share our Casdoor configuration screenshots with you for reference - just let me know what specific settings you'd like to see. The integration has been working smoothly across multiple other applications in our environment.

    Best regards,
    biankasyo

  • biankasyo commented 4 months ago

    @robin Hi Robin,

    Just wanted to add one more important point about the Feishu configuration - the "获取用户 user ID" permission in the Feishu application is absolutely critical. If this permission is not enabled, Casdoor will default to using the Feishu username as the name during user registration in Casdoor.

    When Feishu usernames are in Chinese, this often causes registration failures in Casdoor, which would explain the "user's owner and name should not be empty" error you're encountering. Please ensure this specific permission is properly enabled in your Feishu developer platform settings.

    Best regards,
    biankasyo

  • Robin Shen commented 4 months ago

    Just wanted to add one more important point about the Feishu configuration - the "获取用户 user ID" permission in the Feishu application is absolutely critical. If this permission is not enabled, Casdoor will default to using the Feishu username as the name during user registration in Casdoor

    Thanks for pointing this out. I added this permission at Feishu side. Now both Gitea and OneDev can authenticate via casdoor. I am using latest OneDev and Casdoor version (build from source).

  • biankasyo commented 4 months ago

    Hi Robin,

    Thank you for your thorough testing and confirmation that the integration works with Feishu after enabling the necessary permissions. I appreciate your efforts in reproducing the setup.

    However, I’m still encountering some issues on my end. After further investigation, I found that if I adjust the OpenID scopes in OneDev from openid email profile to just openid email, the authentication process completes without errors, and I can log in successfully. However, in this case, the username is not retrieved properly, and even if I manually update it after logging in, subsequent logins overwrite the changes, making it impractical for team use.

    It appears that when the profile scope is included, an issue arises during the call to Casdoor’s get_account API. This might be due to unexpected data formats or other compatibility problems, causing the process to fail and clear the previously stored session. When the flow continues, the absence of a valid session triggers the “Unknown authentication type (not password or provider)” error. By excluding the profile scope, we bypass this issue, but at the cost of not retrieving essential user information.

    Interestingly, this problem seems to occur during the interaction between Casdoor and Feishu, even though this interaction works flawlessly with other applications (e.g., Outline, Lowcoder). This suggests that the issue might lie in how OneDev and Casdoor handle certain aspects of the OpenID flow when the profile scope is involved.

    Additionally, I noticed that if I log into Casdoor via Feishu first (so the Casdoor cookie is valid) and then initiate SSO to OneDev directly (without going through Feishu again), the process works correctly even with the openid email profile scopes. However, in this case, OneDev does not seem to use the displayName as the “Full Name” but instead uses the Name field. Since Casdoor uses the Feishu user_id as the Name field, this results in usernames that are not user-friendly, again making it unsuitable for team use.

    Could you please investigate further how OneDev handles the profile scope and user attribute mapping when integrating with Casdoor? It seems like there might be a compatibility issue in the way user information is retrieved or processed when the profile scope is included.

    Thank you again for your support and attention to this matter.

    Best regards,
    biankasyo

  • Robin Shen commented 4 months ago

    Handling of profile is no different from other scopes, and I did not encounter any session issue you mentioned. As to user name, OneDev uses preferred_username attribute in returned claim set, and this can be changed later and OneDev can associate the updated account with OIDC account as long as email address is available for account linking.

    However with Casdoor integration, I can not get email address returned. My Feishu account has email address specified. I added the permission to retreive email info. I also tried to specify email scope as contact:user.email:readonly in addition to email at OneDev side, as this is what being displayed at Feishu side under the email scope: email-scope.png

    However seems that Casdoor has bugs handling such scope: casdoor-error.png

  • biankasyo commented 4 months ago

    Handling of profile is no different from other scopes, and I did not encounter any session issue you mentioned. As to user name, OneDev uses preferred_username attribute in returned claim set, and this can be changed later and OneDev can associate the updated account with OIDC account as long as email address is available for account linking.

    However with Casdoor integration, I can not get email address returned. My Feishu account has email address specified. I added the permission to retreive email info. I also tried to specify email scope as contact:user.email:readonly in addition to email at OneDev side, as this is what being displayed at Feishu side under the email scope: email-scope.png

    However seems that Casdoor has bugs handling such scope: casdoor-error.png

    @robin Hi Robin,

    Thank you for your detailed testing and feedback. Regarding the email retrieval issue with Feishu integration in Casdoor, I’d like to provide some additional context:

    Feishu is a bit special in how it handles user information. It uses the /open-apis/authen/v1/user_info endpoint to retrieve user data. For the email field:

    • If you want to retrieve the user’s personal email (custom email), you need to apply for the "获取用户邮箱信息" permission in the Feishu developer platform. The returned field is email.
    • If the user is bound to an enterprise email and you want to retrieve that instead, you need to apply for the "获取用户雇佣信息"/"查看员工企业邮箱" permission. The returned field is enterprise_email.

    Casdoor’s current logic is to first try to fetch the email field. If that is empty, it falls back to fetching enterprise_email. However, this requires that the corresponding permissions are properly enabled in the Feishu developer platform. You can directly search for enterprise_email in the Feishu permissions list to find and enable the required scope.

    This might explain why the email isn’t being returned in your case—it could be due to missing permissions or the fact that the user’s email is stored as an enterprise email rather than a personal one.

    Hope this helps clarify the issue. Let me know if you need further assistance!

    Best regards,
    biankasyo

  • Robin Shen commented 4 months ago

    My email is for my personal account. As mentioned earlier I added necessary permissions for user email retrieving.

  • Robin Shen commented 4 months ago

    @biankasyo OneDev 12.0.9 is now able to login via SSO without email. When first login via Casdoor, OneDev allow the user either creating a new account specifying own user name, or linking with an existing account. User name will not be overriden on subsequent logins.

  • biankasyo commented 4 months ago

    @biankasyo OneDev 12.0.9 is now able to login via SSO without email. When first login via Casdoor, OneDev allow the user either creating a new account specifying own user name, or linking with an existing account. User name will not be overriden on subsequent logins.

    @robin Hi Robin,

    Thank you for your continued testing and feedback. Regarding the issue where Casdoor isn't retrieving your personal email from Feishu, it might be due to the initial user registration process in Casdoor.

    When a user first registers via Feishu login, Casdoor captures the user information available at that time. If the email permission wasn't fully enabled or properly configured in the Feishu developer platform during that initial registration, the email field may not have been captured and stored in Casdoor. Subsequent logins typically don't update existing user information in Casdoor unless specifically configured to do so, which means the email field might remain empty even if permissions are corrected later.

    There are two potential solutions to resolve this:

    1. Delete and re-register the user in Casdoor: You may need to delete the affected user account in Casdoor (and potentially remove any associated certificates or configuration files). Then, with the email permissions properly enabled in the Feishu developer platform, have the user log in again through Feishu. This will trigger a new user registration in Casdoor with all the currently available information, including the email.

    2. Manually update the user in Casdoor: Alternatively, you can manually add or update the email field for the affected user directly in Casdoor's user management interface. This avoids the need for re-registration while ensuring the email is available for OneDev's account linking.

    Additionally, thank you so much for the update regarding OneDev 12.0.9's ability to handle SSO logins without email and the improved user account handling (allowing users to specify their username during first login and preventing overwrites on subsequent logins). I will update my OneDev instance to test this new behavior.

    We truly appreciate your support and attention to this integration challenge. Wishing the OneDev project continued growth and success!

    Best regards,
    biankasyo

issue 1/1
Type
Bug
Priority
Normal
Assignee
Affected Versions
12.0.4
Labels
No labels
Issue Votes (0)
Watchers (2)
Reference
OD-2529
Please wait...
Connection lost or session expired, reload to recover
Page is in error, reload to recover