External OAuth applications
-
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?
-
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.
-
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?
-
@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.
-
@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.
