Unsolved External OAuth applications

[iamthefij]

Cloudron used to support acting as an OAuth provider for external applications, and it’s referenced in the documentation, however I can no longer find the setting. Is that still available?

[nebulon]

Thanks for the hint, we have to update the documentation. The functionality is still there, however we have more or less deprecated it. So you should not rely on that for now.

[girish]

Is it better that Cloudron becomes an OAuth provider (this is functionality which we have but is hardly used and hence we are considering deprecating) or that Cloudron is able to use an external OAuth provider for authentication?

[iamthefij]

@girish for what I’m trying to do, it’s best to be a provider.

There are some applications that just aren’t suitable to host on my Cloudron due to memory limitations. I’d like to not manage my credentials separately. Public facing LDAP would be more convenient, but higher risk. A public OAuth provider would be enough for me to use for proxy auth from my other server.

[fbartels]

@girish said in External OAuth applications:

Is it better that Cloudron becomes an OAuth provider

Instead of just Oauth, OpenID Connect should be what you need to implement. Sadly it's not as widely adopted as it could be, bit with built in service discovery it's the better technology (both for then provider and the client implementation).

At my place of work we have been implementing an OpenID connect provider (https://github.com/kopano-dev/konnect) and have already won some other projects interest in bundling our provider (for example Unicention and owncloud). Our provider is go based, so it might not match the rest of your architecture, but it also has an ldap backend (so could easily be integrated as an app) and you could either mod the bundled sign in app, or wrote your own and let it handle the login flow through the services rest API.

[yusf]

I just discovered that the OAuth provider feature is not available anymore, just as I was to implement it for a custom LAMP app. Is it too much maintenance or is there a chance of reviving it?

[nebulon]

The OAuth feature is still there, but only used for the dashboard itself at the moment. It used to be used by some other apps, but slowly those were moved to LDAP since the OAuth flow often breaks the app's login handling or was at least confusing. Also I should mention that some apps implement OAuth into a signup flow and will create local accounts based on the OAuth outcome, which in turn often would not allow email change propagation or worse, password resets to reset some local account password. So there are various complications, which do not exist in most LDAP backends in apps.

[yusf]

Thanks for clarifying the painpoints of such approach, I'll reconsider.

[iamthefij]

There are trade-offs with every solution though.

With LDAP, 2FA needs to be built out in each application or added via some form of LDAP proxy (I think this was discussed on GitLab or Rocket.Chat somewhere). With OAuth, the provider can handle that.

Also, OAuth only requires access via HTTP(S). I would like to use Cloudron as a single source for my identity, but that's impossible today since I can't use it as an OAuth provider or securely access LDAP from any other server.

I totally understand a preference towards LDAP, if available, but removing the option for OAuth does impose limitations.

A while back I started working towards my own workaround by building a Cloudron app that provides a VPN interface and proxy to the Cloudron LDAP server. I decided against that and to instead just host an instance of Authelia from within Cloudron, but I've since run into a wall there as well.

I'm not dead set on any particular solution, but would be great to have some mechanism to use Cloudron as SSO for all my services.