Open jessebot opened 11 months ago
It looks like if AppFlowy-Cloud is using gotrue under the hood, that Keycloak is supported: https://github.com/supabase/gotrue/tree/master#external-authentication-providers
Zitadel is not listed though, so I added a comment to their issue tracking additional oauth support requests: https://github.com/supabase/gotrue/issues/451#issuecomment-1834357750
Hi @jessebot. Currently, we support SAML. So pretty much any Idp that uses SAML Assertion should work with correct configuration. iirc I don't think GoTrue support OIDC connect.
Edit: from what I read, it seems that Zitadel have SAML support. You might want to give it a try with that. Our recent addition of SAML for okta doc might be relevant to you: https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/main/doc/OKTA_SAML.md
Thank you for your fast reply! I will look into those and report back here with findings and how to proceed before closing so that other community members can use it too :)
Hi @jessebot , we're eager to gather valuable feedback from our users to better plan for 2024. Participants who complete this survey will gain priority access to our new launches. We appreciate your insights: https://tally.so/r/nW8qAQ.
Thank you @annieappflowy ! I will fill that in as soon as I can (probably in the next week).
In the meantime, as I see a way forward for zitadel and there's already support for keycloak in gotrue, I'll close this to prevent clutter, and update the issue when I work on making zitadel play nice with gotrue just so other users searching know what to do.
Thanks again to @speed2exe for always taking time to help me out :)
I am currently working on getting Keycloak to work with AppFlowy. Shall I open a new request for changes or shall we reuse this issue?
My findings are following:
https://<AppFlowy URI>/callback?state=<hash>&session_state=<hash>
After adjusting the callback URI to include /gotrue/
I receive following internal error with Keycloak configured via env variables:
gotrue_1 | {"component":"api","error":"invalid_grant: Invalid Refresh Token: Refresh Token Not Found","level":"info","method":"POST","msg":"invalid_grant: Invalid Refresh Token: Refresh Token Not Found","path":"/token","referer":"appflowy-flutter://","remote_addr":"172.19.0.3","time":"2024-01-15T10:27:48Z","timestamp":"2024-01-15T10:27:48Z"}
gotrue_1 | {"component":"api","duration":754617,"level":"info","method":"POST","msg":"request completed","path":"/token","referer":"appflowy-flutter://","remote_addr":"172.19.0.3","status":400,"time":"2024-01-15T10:27:48Z","timestamp":"2024-01-15T10:27:48Z"}
gotrue_1 | {"component":"api","level":"info","method":"GET","msg":"request started","path":"/authorize","referer":"/web/login","remote_addr":"172.19.0.4","time":"2024-01-15T10:28:04Z","timestamp":"2024-01-15T10:28:04Z"}
gotrue_1 | {"component":"api","level":"info","method":"GET","msg":"Redirecting to external provider","path":"/authorize","provider":"keycloak","referer":"/web/login","remote_addr":"172.19.0.4","time":"2024-01-15T10:28:04Z","timestamp":"2024-01-15T10:28:04Z"}
gotrue_1 | {"component":"api","duration":119063,"level":"info","method":"GET","msg":"request completed","path":"/authorize","referer":"/web/login","remote_addr":"172.19.0.4","status":302,"time":"2024-01-15T10:28:04Z","timestamp":"2024-01-15T10:28:04Z"}
nginx_1 | 172.19.0.1 - - [15/Jan/2024:10:28:04 +0000] "GET /gotrue/authorize?provider=keycloak&redirect_to=/web/login HTTP/1.1" 302 608 "https://appflowy.hetzner.company/web/login?error=server_error&error_code=500&error_description=Error+getting+user+email+from+external+provider" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0"
@suntorytimed Thanks for the findings. This will be helpful in supporting auth with keycloak, which we will doing in the coming months
In my opinion it's better to support generic OIDC which will cover all possible solutions, including Casdoor and so on.
@L11R depends on what GoTrue supports, as it is the base for user management in AppFlowy Cloud. Afaik. GoTrue does have a generic SAML provider. Not sure about OIDC. But they do offer a Keycloak-specific implementation out of the box. But I agree that this shouldn't be limited to just Keycloak. It's just the most common on-prem enterprise solution due to RedHat.
I used a lot Authelia a light OIDC, I can test this feature when It's possible ;)
@suntorytimed Did you later sort out the keycloak errors? I want to deploy appflowy cloud with keycloak as well
1~3 main use cases of the proposed feature As a sysadmin I'd like to be able to use an open source self hosted OIDC (Open ID Connect) provider like Zitadel to authenticate myself and other users in a contained environment.
what types of users can benefit from using your proposed feature This helps those with strict security requirements to self host every part of their stack to ensure compliance as Discord and GitHub are not always viable options.
Additional context Add any other context or screenshots about the feature request here.