Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


  1. Home
  2. Announcements
  3. OAuth support

OAuth support

  • girish
    Staff

    Hi All,
    We are looking into user roles/permissions for the coming release (for example, you can create a user who can invite other users but not administer other parts of cloudron). When we started investigating this, we found it will be simpler for us if we remove OAuth related support from code base.

    For some history, we started out with OAuth from day 1. This is because our vision was to have proper SSO across all apps. Unfortunately, OAuth always requires adding custom integration code into apps. We tried to upstream changes for every app but this was a lot of work and in many cases the PR just rejected or we didn't know the framework/language or it just caught in a lot of code review. We decided this wasn't worth it and went with LDAP which unlike OAuth most apps support and requires no upstream changes.

    Ultimately, none of our apps now use OAuth. It's been gone for 1.5 years now. Besides it looks like SAML is the future and does not require upstream changes for proper SSO. We will consider supporting SAML instead in a future release.

    Note that this upcoming change only affects those who have custom apps using oauth addon. If you are using Cloudron OAuth, please let us know and we can help you migrate.

    4 fbartels 1 Reply
  • fbartels

    @girish said in OAuth support:

    Besides it looks like SAML is the future and does not require upstream changes for proper SSO. We will consider supporting SAML instead in a future release.

    SAML (while having support in enterprise environments) is not the future, it's the past as well. The future would be openid connect.

    2 W 1 Reply
  • W

    @fbartels Can you share more on your reasoning? Im not as familiar with OpenID Connect

    0 fbartels 1 Reply
  • girish
    Staff

    OpenID is great as well if apps support it. IIRC, it specifies the routes and fields that one has to return so it's more standardized.

    2
  • fbartels

    Hi @will,

    SAML is basically "old tech". It's XML based and requires clients to generate keys through openssl which makes it in my experience both complex and difficult to set up for novice admins and also implement for developers. Apart from that SAML only works for browser based workflows.

    Like I said before the one thing SAML has going for it is that its already well supported in enterprise applications. But I recently had a chat with someone involved in quite some university and government projects on the infrastructure side and he told me that he sees a trend to favour oidc over SAML recently.

    An article with a comparison can be found at https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/

    PS: with Kopano Meet there is actually already an OpenID Connect provider present on Cloudron as all authentication is done through OIDC in it. What we use there is Go and React, but I am confident that there is code to be reused for Node as well.

    5 W 1 Reply
  • W

    @fbartels Thanks for the thoughtful reply!

    0
  • iamthefij

    It would seem that supporting Keycloak would be a great way to still only really have to maintain LDAP on the Cloudron side and then add support for OpenID Connect, OAuth 2.0
    and SAML 2.0.

    I've never set up Keycloak though, so I can't speak to it's ease of use or maintaining, but it is often recommended when people talk about FOSS Identity and Access Management tools.

    2
  • girish
    Staff

    keycloak is a really good idea, didn't think about that. By which, i mean if we could have apps that provide additional saml/oidc support to cloudron, that is definitely way better than us re-inventing all this. Some of the universities Cloudron is deployed in uses Shibboleth which I am told support LDAP and OAuth2

    3
  • J

    I've wished for OAuth support for quite a few times already to support SSO to non-Cloudron apps. So in that case, Cloudron would serve as the identity provider for a third-party app. Kind of like Login with Cloudron.

    That would require that one can register third party apps with their client id, client secret and callback URL though.

    I have a little bit of experience with Keycloak. I know that U=using Keycloak would (also) support this use case, provided a Cloudron user has access to the Keycload administration interface.

    1 iamthefij 1 Reply
  • iamthefij

    @jk That actually used to be possible, but the OAuth provider is now gone.

    Adding something like Keycloak or even Shibboleth would add back an OAuth provider.

    1
Log in to reply