netbirdio
OIDC login provider support
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.
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. I can't give any clear delivery date yet.
Btw, would you be willing to participate in implementing this integration?
I would like to turn off the authorization page in the management console altogether
I can add basic authorization to reverse proxy https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/
That would be of a great help @jhult . Thank you! There are a few things to consider.
Let's have a chat? You can ping me in Slack https://join.slack.com/t/wiretrustee/shared_invite/zt-vrahf41g-ik1v7fV8du6t0RwxSrJ96A
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 https://github.com/wiretrustee/wiretrustee/issues/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.
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 ! We will also need to check how we could replace the Auth0 in the frontend part.
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 :)
@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. https://github.com/netbirdio/dashboard/blob/main/src/App.tsx
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. https://github.com/bjerkio/oidc-react
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 ...
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.
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).
This is actually unrelated to the OIDC, I guess I confused you a bit with my previous message.
But I got your point. I'd be willing to ping you to discuss things once we started working on this.
Hey guys, We came across Zitadel -> https://github.com/zitadel/zitadel It looks like an excellent option for us, except that they don't yet support a device flow that we need for our interactive login feature when registering a device with SSO -> zitadel/oidc#141 It is OIDC compliant, so it will work once we support OIDC. Just curious about your opinions.
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. Most of the work has been done by @mlsmaycon and there are some bugs to fix. It is coming soon!
https://github.com/netbirdio/dashboard/pull/60
Hey everyone! I brought some good news :) We have just merged #60, thanks to @mlsmaycon! We introduced a generic OIDC library within this PR and achieved compatibility with Auth0. We haven't tested any other IDP yet, but the library is OIDC compliant, so we don't expect any big issues. Go ahead if you'd like to try it with keycloak or any other solution! Feedback is very welcome, and feel free to document the steps, we will then publish them on our docs website :)
We will be also working on documentation in the following days.
Cheers, Misha
FYI: I'm working on some generic OIDC adjustments here https://github.com/netbirdio/dashboard/pull/66
Just tested Keycloak :)
Hey everyone. The Keycloak integration guide is there, check it out! https://netbird.io/docs/integrations/identity-providers/self-hosted/using-netbird-with-keycloak
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://<YOUR-KEYCLOAK-HOST-AND-PORT>/realms/netbird/.well-known/openid-configuration
unfortunately I have 404 not found. What can I do wrong?
