[FR] self-hosted OIDC authentication via Zitadel/Keycloak

[jessebot]

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.

[jessebot]

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:
supabase/auth#451 (comment)

[speed2exe]

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

[jessebot]

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 :)

[annieappflowy]

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.

[jessebot]

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 :)

[suntorytimed]

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:

• Using Keycloak with SAML according to the Okta Tutorial didn't work, as the authentication with Keycloak can't be set up (only Metadata URL, but no certificate exchange)
• Using Keycloak with SAML configured in the gotrue env variables (see GOTRUE_EXTERNAL_SAML variables here) results in no functionality of an SSO login whatsoever (not shown in the admin panel, no button and no errors)
• Using Keycloak with oauth2 configured in the gotrue env variables (see GOTRUE_EXTERNAL_KEYCLOAK variables here) results in an error message, due to missing logo on the login page. After adding a keycloak folder with logo under assets for the admin-frontend the button appears and I can login to Keycloak. But the callback URI can't be parsed by AppFlowy. I assume, that following is missing in AppFlow to support Keycloak OIDC login: https://discord.com/channels/903549834160635914/1171707854701461565/1196381448219934780
  • the callback URI after the Keycloak login looks like this: https://<AppFlowy URI>/callback?state=<hash>&session_state=<hash>

[suntorytimed]

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"

[speed2exe]

@suntorytimed Thanks for the findings. This will be helpful in supporting auth with keycloak, which we will doing in the coming months

[savely-krasovsky]

In my opinion it's better to support generic OIDC which will cover all possible solutions, including Casdoor and so on.

[suntorytimed]

@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.

[kosssi]

I used a lot Authelia a light OIDC, I can test this feature when It's possible ;)