Now available: OpenID Connect for ownCloud

With integrating OpenID Connect (OIDC), ownCloud unifies a lightweight authentication with a rich ecosystem of security features.
open id connect owncloud extension

We are happy to announce that the extension OpenID Connect 1.0.0 is now available in the ownCloud Marketplace. It has been battle-tested in active use at a number of customer projects with up to 200,000 users. Now, we officially release it as a community extension under GPLv2 that can be used in any and all ownCloud installations.

What it is

OpenID Connect is the open standard for single sign-on identity and access management. With ownCloud, it can be used for user authentication and client authorization against an external Identity Provider (IdP) like Keycloak, Ping Federate, ADFS, Azure AD, Kopano Konnect and others. There is already native support for OpenID Connect in the ownCloud Desktop Client 2.7, ownCloud iOS App 11.4, ownCloud Android app 2.15, the ownCloud Classic web frontend and the upcoming ownCloud Web frontend.

Why OpenID Connect

To give a little more context , let’s have a look at the history of ownCloud and user authentication. ownCloud has come a long way with user authentication and single sign-on. In the most basic setups, users logged in with basic authentication (username/password). Typically that is done for internal ownCloud users or backed by a LDAP/AD user directory.

As we have discussed some time ago when we released the OAuth2 extension, offering only basic authentication is not considered state-of-the-art anymore. In today’s world of multiple devices and applications that work together there are simply too many drawbacks. Clients have to store user credentials, users have to log in to each application they use separately. Furthermore, you can’t uniquely identify or selectively disconnect devices on the server and there’s not much administrative control over sessions and devices. And more sophisticated technologies have already emerged.

Adopting SSO through SAML2

Early on, ownCloud implemented support for single sign-on with the SAML/SSO Integration extension, addressing huge demand for single sign-on capabilities, both for security and for usability reasons. Back then, SAML 2.0 was the de-facto standard, especially in the research and education sectors. The extension provided native support for all clients on the Desktop and for the iOS and Android apps. By the time, this was a huge step forward as it enabled the use of specialized Identity Provider software for user authentication (security) and offered a way to integrate ownCloud into single sign-on environments (usability).

Tricky to build, hard to maintain

Supporting SAML 2.0 natively on all client platforms was not an easy feat for our engineers. As SAML has originally been designed for browser-based applications, we encountered many issues, especially around expiring tokens that forced users to re-authenticate every couple of hours, creating a negative experience for users. Also, the lack of administrative capabilities for client management and security policies contributed to us realizing that SAML 2.0 is not exactly a perfect fit for our single sign-on requirements.

Tokenizing it with OAuth2

In 2017, we released the OAuth2 server-side extension, implemented on all client platforms. Until today, OAuth2 provides for secure, token-based client authorization against ownCloud Server.

Disconnecting clients selectively

With this technology, actual user credentials do not have to be stored on the clients anymore and clients can be uniquely identified as well as selectively disconnected, if necessary. On the client side too OAuth2 helped a lot as it plays nicely with SAML 2.0: When connecting an ownCloud client using OAuth2, the SAML 2.0 flow can take place using only the browser until the user is authenticated against the ownCloud Server.

Relieving the clients

From that point on, OAuth2 takes over again, supplying its tokens to the client, effectively allowing authentication of users against a SAML 2.0 Identity Provider, while at the same time making native SAML implementations in the clients obsolete. This also means we could remove native support for SAML from all client platforms, facilitating client maintenance by a lot and improving the user experience nicely.

Open questions

While a great improvement on SAML, the OAuth2 implementation is very lightweight, its client management is user-based and it doesn’t provide support for more sophisticated security policies. Furthermore, its use is limited to client authorization. The web login as part of the OAuth2 flow still uses basic authentication, or SAML. ownCloud providers can, with OAuth2, only benefit from professional Identity Provider features like Multi-factor Authentication and other security features while combining it with SAML.

Last but not least, according to the OAuth2 specification, tokens never expire. This can be undesired for security reasons. Generally, from a client perspective in an OAuth2 setup, ownCloud Server acts as the Identity Provider. This leads to a certain decoupling, causing an actual SAML 2.0 Identity Provider to loose control over authorized clients. Sadly, the implementation does not provide the tools needed for appropriate security and management capabilities to balance this situation.

OpenID Connect replaces the legacy mechanisms

The answer to all the questions and issues discussed above is OpenID Connect (OIDC). Built as an authentication layer on top of OAuth2, OIDC allows ownCloud providers to use single sign-on with the professional Identity Provider of their choice while keeping all the benefits that OAuth2 provides.

Benefits of using ownCloud with OpenID Connect

  • Increased security by shifting user authentication to an external IdP
  • Seamless integration into single sign-on (SSO) environments as well as with third party products
  • Centralized client management within the Identity Provider for all native connections
  • Enterprise-grade security through the use of authentication security features (e.g., multi-factor authentication) and policies (e.g., automatic token expiration on certain conditions) provided by Identity Providers

Sophisticated security

Made also for non-web clients, OIDC provides a great SSO experience with the ownCloud clients as well as the web interface. Simultaneously, it allows service providers to put even the most sophisticated security measures in place, only limited by the capabilities of the chosen Identity Provider. Devices can be managed centrally, authentication security features can be used and enterprise-grade security can be realized by employing security policies like automatic token expiration when devices leave the company wifi, for instance.

Client support

  • ownCloud 10 Web: Available with the OpenID Connect app
  • Desktop: 2.7.0
  • Android: Available since 2.15
  • iOS: since mid 2019

The way forward & legacy support

For all the benefits we have decided to go forward focusing completely on OIDC. Still, ownCloud Server 10 will continue to support all discussed standards and mechanisms. The upcoming ownCloud Infinite Scale will support OpenID Connect only. For those who still require SAML or other mechanisms, there are Identity Providers that provide ways to bridge between other standards and OIDC.

Sneak peek into the future

We are making good progress with the new, modernized ownCloud Server that goes by the name ownCloud Infinite Scale. The first step in the transition are new versions of the ownCloud clients that are compatible with the new backend and the new authentication technology OIDC, some of which are already released.

Then, we will release our shiny new browser interface called ownCloud Web to be used with the ownCloud 10 Server, but also compatible to ownCloud Infinite Scale. After that, the upcoming ownCloud Server 10.6 will, in combination with the OIDC extension, provide the components needed to create a bridge deployment consisting of the two Server generations ownCloud 10 and ownCloud Infinite Scale to enabling full migration on a user-by-user basis.

OpenID Connect will play a key role in this milestone as it connects the old and the new world in terms of user authentication. For now, you can only use OIDC in ownCloud 10 when LDAP/AD is used as a user backend. For users created in ownCloud, we first need a bit more magic to make it happen.

Oh, and: To make the transition as easy and seamless as possible for all ownCloud deployments out there without Identity Providers, ownCloud Infinite Scale will ship with Kopano Konnect, an OIDC Identity Provider (IdP) developed by our friends at Kopano. It also helps enable OIDC in ownCloud 10 to make your deployment ready for the new ownCloud if it does not already feature an external IdP.

To check out the OIDC extension, visit the marketplace page.

Patrick Maier

Über den Autor

Patrick Maier is Senior Product Manager at ownCloud and has been overseeing the development of Infinite Scale since the idea was first conceived.

Patrick Maier elsewhere:

Patrick Maier

Oktober 26, 2020

Ready to see what’s next?

Having trouble viewing or submitting this form?

Contact Us

We care about protecting your data. Here’s our Privacy Policy.

Read now:

Digital Sovereignty: Shared Values of OSB Alliance, ownCloud

Data security and user control: Public vs. private cloud

In this interview with IT-Zoom, Tobias Gerlinger, CEO and Managing Director of ownCloud, discusses why public cloud is not the right place for sensitive data, and what measures enterprises can implement to protect data and exercise full user control.

mehr lesen
Infinite Scale in the Press

Infinite Scale in the Press

A list of resources featured in various publications tracing the journey of Infinite Scale so far and delving deep in to the technology that makes up its core.

mehr lesen