Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog


## Introduction

Last week, something exciting happened: We were actually able to physically attend an event hosted by the [Research Center for Digital Sustainability](https://www.digitale-nachhaltigkeit.unibe.ch/index_eng.html) from the University of Bern. The main reason for the event was the publication of this year’s [Open Source Survey](https://oss-studie.ch/), but for us it was also a great opportunity to learn more about how other companies use or develop Open Source, build communities, and define the cultural aspect around Open Source. And if that was not exciting enough: actually being able to talk to other people over a cold beverage was definitely a big plus after the past months.

I want to share some insights and thoughts about the study, conversations and talks from the event, and finally about our Open\* journey with you.

## Open\*

In the [first talk of the event](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092041/01DominicBranderSnowflake-Interoperabilitt_ger.pdf), Dominic Brander introduced us to the term Open\*. That term not only suggests being mindful about including others [1], but also makes it easy to refer to the broader context of Open Source, Open Data, and Open Standards.

I like this term. It makes things easier. And what I realized is that for us, and apparently for others as well, Open Source is not only about letting others see your code, Open Standards is not only about agreeing on a common denominator, and Open Data is not only about getting free data for your school work. It’s much more a cultural thing, for example a culture of trust, enabling collaboration yet not only through interoperability, but of transparency.

I will use the term in this article and most likely in the future.

<sub>
  [1] ‘*’ is also referred to as ‘Gender star’ and is a form to provide gender
  neutrality in a language that otherwise has a grammatical gender.
</sub>

## Insights from Swiss companies

My intention is not to comment on the study, but rather point out some subjectively interesting points for our business and our business area. I realize the study is only available in German, even more motivation to share some insights.

49% of participating companies (N ~150) declare themselves as “heavy users”, using Open Source in more than half of the suggested 28 categories. This figure is up from 29% in 2018. The study offers no more insight on share of total software used within a company, but this is still a good indicator that Open\* solutions are valued broadly.

Interestingly, “Interoperability” is both the top reason FOR and second most important obstacle AGAINST adoption of Open Source in organizations. This point was also discussed by Dominic in his talk: Open* != Interoperability, meaning being an Open* product is not a sufficient condition for being interoperable with every other product. We have to work on interoperability and need to get better at it.

Overall the top 5 objections mentioned against using Open Source:

- Uncertain future of Open Source projects, unclear business model
- Missing integration with other systems
- Lock-ins with current, proprietary system
- Missing features, no matching Open Source alternatives
- Lack of acceptance by end-users, not user-friendly

The authors argue that maintainers/vendors must provide more transparency on the long-term development of their products, coupled with overall more information about the Open Source business model. Likewise the authors urge Open Source communities to become more (end-)customer-centric and generally more accessible.

I fully support that. The same seems to be valid here as for the interoperability argument:  
Releasing your product under an Open License is not sufficient to immediately establish trust and gain a dominant competitive advantage over other solutions out there. Trust and product-leadership also comes from a clear goal with a plan and means to reach and satisfy your users’ needs (aka. “business model”).

Similarly, sharing your project using an Open License and making some processes more transparent out in the open, does not mean these processes are customer-centric. Customer centricity does not mean to collect and work through feedback, but rather to go through a phase of pattern finding, developing innovative ideas for these problem fields, and iterating potential solutions as early as possible with end-users (aka. “innovation process”)

So despite the objections, why are we in the Open\* game?

## Our motivation for Open\*

**Open Standards:**
Thoroughly reviewed, battle-tested protocols and processes are key for developing an application like ZITADEL, that serves as a serious trust anchor and holds sensitive data. We implement open standards wherever possible to guarantee the security and interoperability of our systems.

**Open Source:**
Use of our application is based on trust. Building this trust is demanding, but can be achieved amongst others with transparency and security at the core. Thus our code that runs on our shared-cloud service is shared openly along with our processes, availability strategies and providers (see [Trust](/trust)).

**Open Licence:**
We say “Own your data!”, some others call it “Digital sovereignty”. We both mean the same thing: Reducing vendor lock-in, dependence on a single platform, and the ability to process and store the data wherever you want - even without commercial support. Our software is licensed under Apache 2.0.

**Open Platform:**
We want to focus on what we do best, namely developing and operating an identity and access management system for SaaS-providers. Our users should be able to build their use cases on our platform, and integrate their favorite services with it. That’s why we employ an API-first approach and expose all functions via gRCP, REST and Webhooks.

**Open Community:**
We welcome contributions in every shape and form, and appreciate the time people invest. Eventually the discussions, external challenges, contributions to the platform or our business help us to get better every day and be open for new and innovative ideas.

For us the use of Open\* is much more a mindset that is reflected in our vision, strategy and architecture of our products, than just a process to follow or licence to grant.

What I realized while reflecting on this article is that we might want to figure out how we want to deal with Open Data in the future.

Now to the party-crasher: Sure, we can talk about Open Licenses etc, but should you trust us not pulling a [MongoDB license stunt](https://www.mongodb.com/licensing/server-side-public-license/faq)?

## Thoughts on SSPL license

Another particularly [interesting talk](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092047/07SimonSchlauriRonzaniSchlauri-SSPL_ger.pdf) at the event was held by Simon Schlauri on the Server Side Public License (SSPL) and its implications. The situation is as expected: Organizations can publish their code under an SSPL license, so that a SaaS offering would be conditional to a copy-left license. This is concerning for many users who are not the main target of this license (ie. ‘Big Tech’). Lawyers already found clever ways to circumvent the copy-left part, if you still don’t want to pay a license. Frankly, it’s a messy business.

We have discussed the different options for licenses and decided for an Apache 2.0 license. Our business model is inspired by companies like Gitlab that are known for their great Open Source community and through that also being successful as a company.

## Does Open\* have any value, then?

Just right away - the thoughts mentioned above have non-monetary value on their own. Both for us and our users. Trust in our product and our team holds for us as a company and maintainer the greatest value.

We earn our salaries by offering ZITADEL, our identity and access management platform, as a service and charging a monthly subscription for support and some non-security related features. Moreover we offer managed instances or 3rd level support for customer instances. Yet you can use ZITADEL completely for free either by running it yourself or by using our free tier. Keeping up to date with security risks and operating the system in more complex and highly scalable scenarios (e.g. geo-redundant or hybrid setups), that is where we excel through our knowledge and experience. Hence our slogan “always run a changing system”. And ,at least for now, customers are happy to pay for this.

Regarding company value: From my experience until now I can say that neither the tax office nor investors make a big difference between open and closed source. Both parties are whether you have the ability to generate sustainable cash flows with the product. Sure, a patent would help to secure some kind of competitive advantage for a certain time, but in the SaaS world the proof lies in the scalable customer base.

During the event Peter Balsiger also remarked in [his talk](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092044/04PeterBalsigerRedHat-CommunityEnterprise_ger.pdf) that IBM paid $34bn in 2018 to acquire Red Hat. That has been by far the biggest deal yet, but 2018 was really a [breakthrough year](https://www.wired.com/story/why-2018-breakout-year-open-source-deals/) regarding Open Source deals, affirming that Open Source companies are valuable.

## Afterthought: Contributing to Open Source as non-techie

After the end of the official event, I had a great conversation with Jannis Valaulta. You can check out [his talk](https://www.digitale-nachhaltigkeit.unibe.ch/unibe/portal/fak_naturwis/a_dept_math/c_iinfamath/abt_digital/content/e90973/e1045995/e1046107/e1092040/e1092042/02JannisValaultaAdfinis-DigitaleSouveranitat_ger.pdf) on digital sovereignty (“Own your data!”, remember?).

I posted the question how “non-techies” could approach contributing to Open Source. For me, as someone with an economics rather than engineering background, the contribution to Open Source projects seemed limited, since “I can’t contribute to fixing or improving stuff”. Other areas as Open Data seem much more approachable for me.

His recommendation was to start with contributing in your area of expertise, optimally in an upcoming hackathon. As an example a designer could contribute with graphics, logos or websites during the hackathon. Similarly, someone with an UX background could help to improve acceptance of users, and someone with a business background could support with figuring out the economic feasibility of the solution for both, customers and providers.

That suggestion seems trivial, but for me that was not so explicitly clear. I realize from my own experience that you most likely can’t excel in all areas that are required to operate a successful Open Source business and outside suggestions are always appreciated. So I think, the next time I might just offer my support, being also open to receive a “no thanks”.

## Great, now what?

If you want to learn more about the study and the talks:

- [View](https://oss-studie.ch) and download the study (German)
- [View](https://www.digitale-nachhaltigkeit.unibe.ch/dienstleistungen/auftragsforschung/oss_studie_2021/index_ger.html) and download all slides and view the talks (German)
- Checkout the Association for the promotion of Open Source Software and Open Standards in Switzerland
- Open Source [activity tracker](https://ossbenchmark.com/) of Swiss companies
- [Directory](https://www.ossdirectory.com/) of Swiss open source solutions

_Unfortunately the event was hosted in German only. Translating the website worked for me partially. Let me know in case you are interested but need help with the language part._

If you’re interested in our projects:

- Checkout our [Github](https://github.com/caos) with the two main projects [ZITADEL](https://github.com/zitadel/zitadel) and [ORBOS](https://github.com/caos/orbos)
- Do you want to share or ask something? [ZITADEL Discussions](https://github.com/zitadel/zitadel/discussions) and [ORBOS Discussions](https://github.com/caos/orbos/discussions)
- Can you [help us get better at engaging](https://github.com/zitadel/zitadel/discussions/1919) our Open Source community?
- Do you have [suggestions on how to make it easier to contribute](https://github.com/zitadel/zitadel/discussions/1920) to our project?
- Want to start contributing? Grab a [“good first issue”](https://github.com/zitadel/zitadel/issues?q=is%3Aissue+is%3Aopen--+label%3A%22good+first+issue%22) and checkout [how to contribute](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md)


What is our motivation for Open Source? Does it bring value to our business? Allow me to share some thoughts on an Open Source study and motivation for Open* with you.

The value of Open*


IMO = In My Opinion is a blog format where a author reflects his own opinion

With the recent announcement of Apple at their annual Worldwide Developers Conference (WWDC) 2021, our perception of how secure authentication should work will gradually shift towards a passwordless future.

The new(est) innovation from Apple to get rid of passwords and second factors is called “Passkeys in iCloud Keychain”. It basically works with the WebAuthN API by utilizing the FIDO2 specification (CTAP2) to create a private / public key pair for each login system. This is normally identified by its domain name of the server challenging your device for authentication. For this to work across devices it is necessary to synchronize the private key in some way.

[Edit: The video has been removed from youtube. You can watch it on developer.apple.com](https://developer.apple.com/videos/play/wwdc2021/10106/)

But wait … synchronizing a private key across your devices with a cloud solution does not sound exactly … sane!  
Well, ok. Let's argue for a minute what the “normal” user does anyway. Many users today rely on password managers to synchronize their passwords and sometimes even their second factors. By doing so, they already expose their secrets to some provider, for example Google, Apple, Microsoft, 1Password, and so on. Even if those providers claim that the secrets are encrypted, it is not a penny better from a security perspective than the synchronization of a private key with the same process. In the end, all private keys, passwords and OTP seed secrets are all **secrets** which allow access to your resources.

But then again, some of you might argue: “I totally control the sync process with a software I run on my own!”  
Well that does not really change the statement above because you end up using a device from one of those vendors anyway and most of them are closed source, so you have absolutely no guarantees that they don’t steal your credentials on the OS level anyway (some exceptions apply - looking at you Linux and to some degree Android).  
To make things worse on an OS or even browser level. Something, like a malicious browser extension or trojan horse, could steal things like access_token or cookies, which broadens the threat model a lot towards OS and browsers.

Oh and to make things worse… Out of band processes like OTP, SMS-TAN and email codes don’t help this effort. If you gain access to either the user's device, OS, or browser, then your whole security model is broken anyway. This is because a lot of today's users just use one device in which they login and also store, receive or generate their second factor.

Ah and yes don't even get me started about those pesky banking authentication apps!

So with this in mind is it still a bad thing to sync the private key?

Well, in my opinion, even with all the downsides like synchronization of private keys (secrets in general) we still gain an **improved user experience** and **phishing resistance**, which I find important these days **without any additional risk** (remember you have them anyway). Also, we reduce the attack surface by **preventing credential reuse** by the user.

So if you ask me: The tradeoff made here by Apple does outweigh the risk. And if you think this risk is too high for you, then just do not use iCloud Passkeys (and password managers in general) and stick to hardware keys.  
If you really care about security you would end up with mTLS (mutual TLS) anyway because this is the only way to mutually authenticate connections and mitigate Man-in-the-middle risk more or less completely (which FIDO2 does not). But this is a topic for another time.

If you want to test iCloud Passkeys today you are best off to use iOS 15, iPadOS 15 or macOS Monterey. Optimally you have multiple devices to see whether the keys get synced across your devices with iCloud Keychain.

As of today more and more systems and services offer the use of passwordless authentication methods. For example your Microsoft Login can be used in this way. Popular Open Source IAM Solutions like Keycloak also give you the option to use passwordless. Our IAM as a Service project ZITADEL does also provide support for the password authentication future.

But remember: Passkeys in iCloud Keychain are **not production ready yet** (technology preview) and are intended for testing only. So for your own sake, please register a fallback hardware key like the ones from our friends at SoloKeys or YubiKey. We recommend you to register multiple keys anyway.


Apple spearheads the push to a passwordless future. But is their proposal to sync your private keys with their iCloud a good idea?

IMO - Passkey in iCloud Keychain


## What is ZITADEL

ZITADEL is a "Cloud Native Identity and Access Management" solution built for the cloud era. ZITADEL uses a modern software stack consisting of Golang, Angular and CockroachDB as sole storage and follows an event sourced pattern.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-01.png"
  width="100%"
  alt="ZITADEL Architecture"
/>

We built ZITADEL not only with the vision of becoming a great open source project but also as a superb platform to support developers building their applications, without need to handle secure user login and account management themselves. By platform we mean a system where multiple parties can integrate custom use-cases for digital identities on top of solid core features. To enable easy integration into your business case, nearly all functions can be accessed via an API. With this we achieve a proper separation of concern and don’t need to integrate custom code within our codebase.

## What features does the platform provide?

### Single-Sign-On / Single-Sign-Out

Use the convenience of a single sign-on (SSO) solution to login with every possible service. ZITADEL enables SSO via standard protocols such as OpenID Connect. Services that cannot be directly integrated can be integrated with identity aware proxy or web application firewalls (WAF). Session management is therefore handled identity-based within identity access management (IAM) and no longer solely in the application. In addition, third-party cloud applications can be easily connected in this way.

### Passwordless / Multi-factor authentication

Although you can use password policies and a range of 2FA and MFA options with ZITADEL to reduce security risks during login, even complex passwords can be compromised, for example through phishing, while user experience suffers greatly from cumbersome passwords and looking up secrets. ZITADEL allows your users to configure passwordless Login based on WebAuthN & CTAP (FIDO2). Passwordless works on all browsers and platforms, requires only one gesture such as FaceID, Fingerprint or PIN, and is phishing resistant through public-key cryptography.

### Identity Brokering

Identity Brokering enables you and your customers to reuse existing identity providers. For example, if you rely on Microsoft's AzureAD for identity management, then you can use ZITADEL’s Identity Brokering feature to link your existing account from AzureAD to your ZITADEL account. The benefits of this feature is that a user can link multiple external identities to it’s ZITADEL identity. Moreover, Identity brokering enables you to grant roles to the brokered users and disable their accounts if the need arises.

### Role Based Access Control

To manage the users' access to projects connected to ZITADEL it supports the use of Role Based Access Control (RBAC). RBAC allows you to design a sophisticated role catalog for each of your projects and granting granular access to users. To integrate these roles into your application you can simply integrate them by utilizing well established protocols like OAuth 2.0 and OpenID Connect. ZITADEL also lets you configure whether you want to assert the roles into access tokens or simply rely on the userfinot and introspect endpoints.

### Delegation

ZITADEL allows you to “delegate” roles of your projects to other organizations. With this feature you can enable other organizations to self-manage their users and the effective role they possess of your project. For example if you create an eCommerce service and you want to delegate the management of a specific tenant to your customer you could easily create a role “tenant owner” which you could grant to the customers organization.

### Strong Audit Trail

Traceability is an important basis for an IAM, which is why ZITADEL offers you an audit trail of all operations of an account and its actions. The audit trail is firmly anchored in the ZITADEL because the internal data model does not save it separately but derives it from an event stream. You have the ability to export the audit trail for advanced analytics or storage to other systems.

### API’s

To make for a great IAM platform ZITADEL provides close to all of its functionalities as APIs. Most important for integrators is the Management API: It provides all features to manage Organisations, Users, Projects for a certain Organisation. Furthermore OpenID Connect 1.0 and OAuth 2.0 are available to integrate your projects Authentication and Authorization requirements. Two more API’s that are available are the IAM and Auth API. The IAM API can be used to configure the whole IAM, this is mostly used in self-deployed (ZITADEL Enterprise) or managed deployments (ZITADEL Enterprise Cloud). Authentication and user information can be accessed through the Authentication API.

## How ZITADEL compares to other solutions

Let’s compare ZITADEL to other well established solutions with a strong focus towards Developers or Open Source.

### Auth0

Auth0 is a great IAM platform to integrate with your projects. Their developer support is exceptional and the API is well thought through. However we find that some things are not ideal, such as pricing, Closed Source, Audit Trail and improper on-premise support.

Where Auth0 is more mature

- More Protocols Supported (e.g SAML 2.0)
- Customization Support (Rules, UI, and so on)
- More stable API’s
- A lot of documentations and howtos

Where ZITADEL excels

- Runs on any cloud provider and on-premise (Cloud-Native)
- Built for multi-tenancy and [self-service delegation](https://zitadel.com/docs/guides/manage/console/organizations/)
- Better Audit Capabilities
- Tiered pricing depending on SLA and non-security requirements

### Keycloak

Keycloak is a mature IAM System with a lot of great features. It is also Open Source with an Apache 2.0 license (like ZITADEL) and has a well established reputation.

Where Keycloak is more mature

- More Protocols Supported (e.g SAML 2.0)
- Better customization (Private Labelling)
- Big Community

Where ZITADEL excels

- Built for Cloud-Native
- Better Audit Capabilities
- Multi- Cloud / Datacenter Support
- Less Resource Requirements

## Platform ecosystem

We think ZITADEL is a great platform for third parties (and ourselves) to integrate business requirements on a robust platform and enable people to build business value instead of focusing on secure Authentication and Authorization implementations.

In this chapter we will provide some use-case where ZITADEL can help you excel.

### Network Integration, Identity Aware Proxy (Zero Trust)

If you use ZITADEL, you can easily integrate your network equipment (Reverse Proxy / WAF) with ZITADEL for things like secure authentication. For example you might want to enforce multi-factor authentication when a user is not at a trusted site. Your identity aware proxy could easily (re)authenticate the user when someone leaves a trusted site by prompting for a more secure authentication method. ZITADEL will then proceed with ensuring the more secure method.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-02.png"
  width="100%"
  alt="Zero Trust"
/>

### Custom User Registration

If you have special requirements for your user registration (KYC, eHealth, eGovernment), you can easily rely on ZITADEL to build your own registration process by integrating your project with the ZITADEL management API. By building your integration you can reuse existing features to manage identities from our platform and combine them with your unique registration requirements.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-03.png"
  width="100%"
  alt="Custom User Registration"
/>

### Business Process integration (SaaS, MSP)

When building a service for your customers you may want to integrate your access management process into your order management. For example, if you have a SaaS solution where a customer can set up a new tenant by himself, you can delegate the ability to manage their own users directly to the customers. This may greatly reduce support requests from customers to setup users and access rights. With ZITADELs unique self-service capabilities it's even possible to let your customers register their existing identity solutions on their own.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-04.png"
  width="100%"
  alt="Business Process integration"
/>

### Custom Lifecycle Requirements (HR Systems)

If your business already has some systems in place that are responsible for managing your Human Resources or Business Processes, you can easily integrate them with ZITADEL. For example, if you have an HR System which already manages the employee lifecycle, you can use ZITADEL to handle the users identity, but leave the business process in the proper domain - within your HR System. With this approach you can reuse your employee process (joiner, mover, leaver) without leaking business processes into the IAM platform. We think that an IAM platform should not be the component in your architecture which executes business processes. Because if you implement business processes from domains like HR, CRM into the IAM Domain, you will eventually create a IAM which can not be easily replaced even if you use standard interfaces.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-05.png"
  width="100%"
  alt="Custom Lifecycle Requirements (HR Systems)"
/>

### Custom Access Management Requirements (ITSM)

Quite a lot of companies already rely on IT service management (ITSM) systems like ServiceNow to handle their fulfillment processing (access request, account reset, etc.). In such cases it makes sense to leave the IT service workflows in the tool that is optimized for business processes and integrate ZITADEL as an access Management system. Such an integration allows you to fully integrate your IT services process. For example the account of a user could be locked from the ZITADEL management interface and the unlock process could be built as a workflowinto your ITSM. This helps you build and maintain lean processes with low implementation and change cost.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-06.png"
  width="100%"
  alt="Custom Access Management Requirements (ITSM)"
/>

### Custom Sync of data (Sync any data source)

ZITADEL’s APIs enable you to manipulate and synchronize data from any system. For example, you can sync your applications users list with ZITADEL and even change user data from within your application. All of this without relying on ZITADEL’s management interface (console). If you care about a deep integration of the user experience this is a great way to enable your project. Furthermore some applications require an up-to-date list of all users for their processes. These applications can easily query ZITADEL for said data.

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-07.png"
  width="100%"
  alt="Custom Sync of data"
/>

## How people use ZITADEL

Most of the time, our customers choose to use our platform's core features like Authentication and Authorization by utilizing protocols like OpenID Connect and OAuth 2.0. But in some cases they integrate even deeper with our API to improve their time to market, operational efficiency and security. Read about what people have already built in this chapter.

### Integration Case - Task Management

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-08.png"
  width="60%"
  alt="Hygeia"
/>

One of our customers built a SaaS Service for tracing pandemics. Right now this solution is used to trace the SARS-CoV-2 spread in some parts of Switzerland.
The special integration in this case is that the workers who use the solution need to be able to assign work to entitled people. To accomplish this, the software utilizes a service account to query ZITADELs management API in a scheduled manner and syncs this list into their database. With this they are able to provide an up-to-date list of all entitled users. Further ZITADEL enables their development by providing an IAM as a Service model, where CAOS takes care of all operation security questions.

Kudos to [JOSHMARTIN](https://joshmartin.ch/) for helping us through the pandemic by providing the government with a progressiv application that really enables the tracing effort.

**Used Features**

- Authentication (incl. MFA, Passwordless)
- Authorization
- OpenID Connect / OAuth 2.0
- Management API, Query Granted Users
- Service Accounts

**Tech Stack**

- Elixir
- Phoenix Live View

**Resources** <br></br>
[joshmartin.ch/en/projects/kanton-st-gallen-contact-tracing/](https://joshmartin.ch/en/projects/kanton-st-gallen-contact-tracing/)

### Integration Case - eCommerce Framework

<img
  src="/blog/2021-05-04-our-vision-for-zitadel-09.png"
  width="60%"
  alt="Velox"
/>

The great people of [sly](https://sly.ch) are building a modern microservice oriented headless eCommerce Framework called [VELOX](https://velox.swiss) and choose ZITADEL as the solution for handling all of their authentication and authorization needs.

Kudos to sly for creating such a great and adaptive eCommerce solution!

**Used Features**

- Authentication incl. multi factor
- Authorization
- Single Sign On
- OpenID Connect / OAuth 2.0
- Management API
- Service Accounts

**Tech Stack**

- Java

**Resources** <br></br>
[velox.swiss](https://velox.swiss)

### Integration Case - multiple ASP.net Core Projects

The Zurich located development agency called [smartive](https://smartive.ch/) utilizes ZITADEL for their projects. As they often rely on ASP.net Core to build award winning projects they wanted to improve their time to market. To integrate ZITADEL with the existing Microsoft authorization ecosystem, they implemented the .net library and open sourced it. Go checkout the library on [Github](https://github.com/zitadel/zitadel-net).

Kudos to Christoph Bühler for implementing this!

**Used Features**

- Authentication (incl. MFA, Passwordless)
- Authorization
- Single Sign On
- OpenID Connect / OAuth 2.0 (incl. JWT Profile and introspect support)
- Management API
- Service Accounts

Tech Stack
ASP.NET Core

Resources
https://github.com/zitadel/zitadel-net

## Future Enhancements (subject to change)

We will improve ZITADEL over time with new features. To give you a small hint of what we are planning to release, have a look at the following list.

- API Docs with Swagger / OpenAPI - [Since creating this blog we released this feature](https://zitadel.com/docs/apis/introduction#swagger-documentation)
- Outbound Webhooks
- SCIM 2.0 API
- Expose Authentication Functions as API
- Conditional Access Rules API

If you have ideas of question feel free to engage with us on [Github Discussion Board](https://github.com/zitadel/zitadel/discussions)

## TL; DR Why you should consider ZITADEL your goto IAM Platform

ZITADEL is a proper **Open Source** project, offers competitive and fair **pricing**, is built by an experienced **team** and a **committed company** and has a **high velocity for developing new features** and constantly improving security.

**In short ZITADEL is the identity & access platform for your business!**

Feel free to contact us on these channels

- [hi@zitadel.com](mailto:hi@zitadel.com)
- [twitter.com/zitadel](https://twitter.com/zitadel)
- [github.com/zitadel/zitadel/discussions](https://github.com/zitadel/zitadel/discussions)

If you consider contributing we would also be happy to welcome you!


We built ZITADEL not only with the vision of  becoming a great open source project but also  as a superb platform to support developers building their applications, without need to handle secure user login and account management themselves.

Our Vision for ZITADEL


<div className="my-4">
  <YouTube videoId={"6FGDaqF3scg"} containerClassName={"youtube-container"} />
</div>

## Topics covered

- What makes ZITADEL better than other IAM services?
- Why did you choose Cockroach DB?
- What is CQRS and how do you use it in ZITADEL?
- Why use a spooler in an event-sourcing workload?
- How does ZITADEL avoid bad data?
- What are challenges of Kubernetes?
- What is ORBOS?
- How to use GitOps? What are the benefits?
- How to solve DNS problems from running Kubernetes in multiple regions?
- How to use CloudFlare's magic WAN?
- How to handle hybrid-cloud challenges?
- Why use geo-partitioning?
- Secondary indexes in Cockroach DB

## CockroachDB & ZITADEL

We use [CockroachDB](https://www.cockroachlabs.com/) as our storage. Check out their great product!

Read our joint Case-Study: [ZITADEL is building an IAM-as-a-service platform with CockroachDB & CQRS](https://resources.cockroachlabs.com/case-study/zitadel).

## Further resources

- [ZITADEL Architecture](https://zitadel.com/docs/concepts/architecture/software)
- [ORBOS - GitOps everything](https://github.com/caos/orbos)
- [Cloudflare Magic WAN](https://www.cloudflare.com/magic-wan/)
- [DNS Chaining | Cockroach Labs](https://www.cockroachlabs.com/blog/experience-report-running-across-multiple-kubernetes-clusters/)


Our live stream with Cockroach Labs on how we built ZITADEL.

How we built it with Cockroach Labs


<div className="my-4">
  <YouTube
    videoId={"coupAc7TmWM?start=3310"}
    containerClassName={"youtube-container"}
  />
</div>

## Topics covered

- About CAOS
- What makes ZITADEL special? Our Challenges & Goals
- How we run ZITADEL in GitOps mode with ORBOS
- What is ORBOS?
- Which resources do we manage with GitOps?
- What did we learn?
- What's the plan for the future?

[Have a look at the slides](https://docs.google.com/presentation/d/1Byg6C5xd3MeEDUWNY2r_fcIj9zBbI2qTCgBjenTTYxM/edit)

## Cloud Native Bern

A great community for companies in Bern (and far beyond), working on Cloud Computing

https://www.meetup.com/cloudnativebern

https://cloudnativeday.ch/

## Further resources

- [More about GitOps @ CAOS](/blog/dev-gitops-at-caos)
- [ORBOS - GitOps everything](https://github.com/caos/orbos)
- [ZITADEL - Cloud-Native IAM](https://github.com/zitadel/zitadel)
- [ZITADEL Architecture](https://zitadel.com/docs/concepts/architecture/software)


Our talk at the Cloud Native Bern Meetup about how to run our cloud-native IAM with GitOps

Blog.

The value of Open*

IMO - Passkey in iCloud Keychain

Our Vision for ZITADEL

How we built it with Cockroach Labs

Cloud Native Bern Meetup, January 2021

Why

Explore

Company