search

kanidm / kanidm

Kanidm: A simple, secure and fast identity management platform
Mozilla Public License 2.0
2.6k stars 176 forks source link

Public clients require origin URL to be known ahead of time #2181

Open pontaoski opened 11 months ago

pontaoski commented 11 months ago

For some apps, the origin URL may not be known ahead of time; e.g. in the new Matrix auth model where users can bring their own clients that do anything from being an SPA to being a desktop client that needs to spin up localhost to being a mobile client that uses its own URI scheme.

It would be nice to use Kanidm for such apps.

pontaoski commented 11 months ago

... I guess this is what OIDC's Dynamic Client Registration is supposed to be for? Matrix seems to support it, at least.

Firstyear commented 11 months ago

I'm not planning to add OIDC dynamic client registration, it opens too many issues.

So yes, we do need to know the origin ahead of time. Is your intent to make it so that there is only one oauth2 public server registration in Kani?

The reason I have resisted being able to have multiple origins in oauth2 is we need to know a URL to redirect users to from the app-links portal. But as you've mentioned, localhost being poped on a desktop, and app-ids on android really confuse this.

ctr49 commented 2 months ago

Is the assumption that kanidm will not be supporting OIDC dynamic client registration / OAuth 2.0 Dynamic Client Registration Protocol still valid?

I also have a use case for it and would like to make sure before I have to implement an ugly workaround.

Firstyear commented 2 months ago

The thing is that dynamic client registration exists for service providers like google, microsoft, facebook and others who are trying to become the "central" authentication entity on the internet. They want people to blindly trust their authentication services and want people to just arbitrarily register new oauth2 clients to their services for this reason.

But we aren't in that boat - We aren't trying to be the internet's central ID provider, we are trying to be something that works for environments that demand a higher level of control and isolation for their identity. Be that home labs or security sensitive enterprise.

In these environments we need to ask what dynamic client registration offers? In our view, it's very little given that the creation of a named public client or a basic client is so trivial. The people who are deploying clients should be in contact with your identity teams to make sure it's done right and linked to the correct access groups.

If anything, dynamic clients are a potential security risk as people can yolo deploy random clients and miss out on the potential to use group mapped scopes and claims etc. This leaves dynamic clients missing out on potentially critical authorisation controls being applied.

So my question to you is "what is your use case"?