-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OIDC login provider support #9
Comments
Hello, I am also wondering if there could be support for SuperTokens (https://supertokens.io/) which I just found yesterday and which also has a free tier as well as the option to run your own instance onsite. This might be a good options to have in as well. |
hey @firestrife23, @lonnietc These are good options. We were looking into SuperTokens or keycloak and we are considering supporting it. Btw, would you be willing to participate in implementing this integration? |
More than happy to provide feedback on the implementation. |
I would like to turn off the authorization page in the management console altogether I can add basic authorization to reverse proxy |
I'm familiar with Keycloak and could help test that. |
That would be of a great help @jhult . Thank you! Let's have a chat? You can ping me in Slack https://join.slack.com/t/wiretrustee/shared_invite/zt-vrahf41g-ik1v7fV8du6t0RwxSrJ96A |
+1 for SuperTokens |
Hey @pomazanbohdan @jhult @firestrife23 @lonnietc @ZR3SYSTEMS, thanks for your feedback. We are looking at the alternatives you provided here, and one requirement we have to move forward is that the solution supports the Dashboard which is a Single Page Application, without the need to work on having a session cache somewhere in our Management layer. This is important as it would allow us to build a project that is scalable and stateless, needing the least amount of services to be deployed. With that in mind, we are looking at Ory Hydra and Ory Kratos as possible options for archiving the requirements above. Any thoughts on that? Also, as this is more of a Management layer problem, we will have tickets there as a main way of tracking, please follow the ticket netbirdio/netbird#126 |
Instead of limiting options of auth providers, why not implement OAuth2/OIDC and let the user pick whatever provider they need? This would cover Keycloak, Authentik, SuperTokens, Ory Hydra, Auth0 itself and more. Edit: Personally interested in Keycloak, which is my IdP. |
@adyanth I like your suggestion, and keeping it simple. |
and its what Kubernetes do as well (OIDC) - so I assume there's some good GO libs that support it :) |
I have used ORY stuff in the past and found it to be a generally frustrating experience due to low quality documentation. I second the general OIDC recs and specifically Authentik has done a really good job of reducing operational complexity. While Keycloak did a lot of things that worked well in a single pane of glass way, the operational complexity with running Keycloak has eroded its position in the field IMHO. |
I'd probably do it like shown here: https://stackoverflow.com/questions/48855122/keycloak-adaptor-for-golang-application - which uses generic go oidc module |
and could we rename this issue to be "OIDC login provider support" ? (instead of 'Authentik' ) |
Looks good @KlavsKlavsen ! Anyone up for a challenge? :) |
@braginini What is the auth0 frontend part? oauth2/oidc does not have a UI part.. it redirects to the third party auth (keycloak f.ex.) for serving login UI (thats kinda the point :) |
You have to generate tokens when calling API, save them, handle refresh tokens, etc. This is all done in the frontend. And still you need handling to show the login. For example this is where the auth0 lib is used. No the only place, every view uses it. |
It seems soneone wrote a keycloak specific module - making it even easier: https://github.com/Nerzal/gocloak - and a short search on github shows many using it (so its easy to see how to do it) - https://github.com/Clarilab/gocloaksession f.ex. |
It's always better to do OIDC than limit to any one provider. Many, many different IdPs (including cloud hosted ones) implement OIDC compared to just adding Keycloak. |
A quick search on GitHub also showed some react libs for the frontend part. |
I am also quite familiar with OIDC both on OP and RP side. Any well written OP shall have the .well-known/openid-configuration endpoint implemented, see https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig. Using a proper module for your specific language shall enable you to read the configuration and get from there all the necessary information to proceed the OIDC flow in a generic way. Thus your generic implementation would only need a pointer to the the the well-known configuration endpoint, a client_id and things like audience or other claims to be validated. For public clients (which you can use for SPA only) the preferred way is to use authorization code flow + PKCE enabled on the server side. I am not very familiar with TypeScript but I am willing to help testing, giving feedback or whatever is needed ... |
@MrRagga- thank you for offering help on that. Very much appreciated! We had a look into our backend code and it seems that there is nothing todo since the jwt token validation part is generic. Only if we would want to support multiuser setup, then we could implement the IDP manager interface -> https://github.com/netbirdio/netbird/blob/295f0c755adffc14d04252f8f169bfba070d0f57/management/server/idp/idp.go#L11. Similar to our auth0 implementation. But this could be the 2nd step. As for the frontend part - we will engage with @dataontabs to replace auth0 lib with a generic solution. |
Oh, you have a bff, then you should offer authorization code flow with a confidential client + PKCE. I am not so much "concerned" about the validation part of the JWT token, but more that you provide a generic implementation with a well-known configuration endpoint support, which is going to work with all existing IdP's out of the box following OIDC standards. |
Not really bff. We just use IDP manager user endpoint to store application-specific user data and query it when needed via API. We just don't want to store email and things like that in the Management service database, we leave it for the specialized software or providers (e.g. auth0 in the case of our hosted version). |
Hey guys, P.S. As I understood, we could embed Zitadel into the management service. Not sure if it is a good idea thought. |
Hey guys, just letting you know that we have started working on the generic OIDC support. |
Hey everyone! We will be also working on documentation in the following days. Cheers, |
FYI: Just tested Keycloak :) |
Hey everyone. The Keycloak integration guide is there, check it out! |
Hello I would like to ask for a little help. I followed the description of the keycloak step by step, but I encounter an error at point 9 Your authority OIDC configuration will be available under: https:///realms/netbird/.well-known/openid-configuration unfortunately I have 404 not found. What can I do wrong? |
Hi @bohemtucsok
What is the name of the realm you created? netbird? |
yes the name netbird, and the keycloak version is 16.1.1 |
Quite an old version. You might try this URL instead:
Or get the info from the Admin UI (use your realm) |
Ooooooo I understand thx for help now working :) |
Hi one more question :) How can I add another user on the netbird management interface ??? is there a way to do this? |
For the self-hosted setup After finishing these steps you can create a new user in Keycloak and they will be added to your network once they log in. |
ohhh thx you are the best :) |
Closing this as complete. Thanks all for the suggestions, indeed it was an improvement to the platform |
The readme still mentions auth0 is required. Does that need to be updated now? |
Good catch. Need to be updated. We support generic OIDC since a while already. |
Readme still needs an update. Took me a bit of time to find out I don't need Auth0 for this. |
I understand your reasons for Auth0. have you heard of self-hosted Authentik? it does pretty much the same as Auth0 in the most area such as Oauth2, SAML, LDAP, and third party integration with Google, Facebook, Twitter, Duo, etc.
The text was updated successfully, but these errors were encountered: