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
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.
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
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.
- 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.
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.