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


In 2010, only two years after Facebook's social login launch, 250 million users and two million third-party websites started using this new login alternative. With the introduction of many contemporary social identities over the years, it is no surprise that more and more platforms are continuously expanding their supply of available authentication options. The popularity of the social-login method is evident, given its convenient and user-friendly nature: It saves its users valuable time by not requiring the completion of a registration form and also spares them the effort of remembering yet another password.

As an authentication platform with the goal of the best possible user experience, ZITADEL strives to eliminate login inconveniences by **heavily expanding the number of its Identity Providers**: Very soon, every user will be assured a comfortable login via their preferred social identity. Whereas, thus far, ZITADEL has exclusively supported OIDC-compliant providers, it will soon remove this restriction to provide a **broader range of options, such as Apple ID, Microsoft Live, Github, Gitlab, and Microsoft Tenants (AzureAD).**

Besides the obvious advantage of increased login convenience, social logins were also proven superior in **enhancing business growth**. To adequately explain this unexpected correlation, it is essential to know how social logins work and how they benefit end-users and companies alike.

## How do social logins work?

Though there are many different providers for social logins (such as Facebook, Google, or Twitter), they all provide authentication in a near-identical fashion.

For them to work, the user must follow these simple steps:

- Upon entering the application or website, the user can **choose his preferred social network provider** (for example, Facebook).
- The website or app sends a **login request to the selected provider** directly, or ZITADEL relais this request to the chosen identity provider.
- Once the social provider confirms the user's identity, the user will **get access to the application**, and the registration process is completed. The selected method can now be used to log in at any time.

![](/blog/2022-06-15-social-logins-01.png)

## The benefits of social logins 

Implementing social logins can heavily enhance the user experience of an application. Some of the most notable **benefits for end-users** include:

- **Easy sign-up and sign-in:** Logins via Apple ID, Microsoft Live, or other identity providers are simple and only involve clicking a few buttons. This method is more convenient for the user than filling out a long registration form and manually logging in.
- **Less password reliant:** We all must remember an overwhelming number of passwords. Using a social login means users don't have to create and keep track of even more credentials. Thus, failed login attempts will be heavily reduced, and users will be less hesitant to sign up.
- **Raise trust:** A social login on your page provides a recognizable and uniform login method. Users will feel more comfortable sharing their data with unknown pages via identity providers they already trust.
- **Better mobile experience:** Dealing with passwords and usernames on your smartphone can be frustrating. Social logins help to make the mobile experience more enjoyable.

Due to its many perks, it is no surprise that countless end-users prefer to confirm their identity via a social login option: According to a study by ["loginradius,"](https://www.loginradius.com/blog/identity/social-login-infographic/) 70.69% of people aged 18-25 prefer social login over the traditional registration form. Accordingly, this simplified login method **can significantly enhance business growth by helping companies increase the number of customers creating accounts, thus** expanding their potential customer base. Not only are Social Logins effective in gaining new users, but also in retaining the existing ones: As claimed by ["Janrain" and "Blue."](https://paperform.co/ebook/Industry-Research-Value-of-Social-Login-2013.pdf), **65% of consumers are more likely to return to a website that automatically welcomes them through social login**.

Apart from higher conversion rates, **social logins further help your company by:**

- **Reducing stress on Support Teams:** The support team will spend less time dealing with security alerts or password requests from failed login attempts by switching to passwordless with social login.
- **Increasing login verification:** Social Logins add a layer of verification to login attempts by requiring confirmation from the chosen identity provider. Accordingly, it is more resilient to spam or harmful logins.
- **Reducing bounce rates:** Customers are more likely to abandon a site if they must fill out the traditional long registration form. The bounce rate can be reduced by making social login a possibility.
- **Simplifying Checkout:** For e-commerce applications, the simplicity of social logins can heavily increase the checkout experience. Thus, enabling them can lead to fewer abandoned carts and more purchases.

## Social logins via ZITADEL

Since every user has a preference for social networks, it is crucial for authentication solutions, such as ZITADEL, to provide a **broad selection of social identity providers**. By introducing a heavily expanded selection of social login templates, ZITADEL allows your application's users to sign in or up with just a few clicks, using their preferred identity.

It is advised to integrate your applications with an identity management platform like ZITADEL, which **can broker to many different identity providers out-of-the-box** instead of integrating providers individually in your apps. When using a central identity broker, you don't need to worry about maintaining your code across different technology stacks, as well as you get the added benefit of a central audit log and user repository.

ZITADEL will support **seven identity providers** (Google, Apple ID, Microsoft Live, Github, Gitlab, and AzureAD) that users can **individually configure and enable**. To maximize the previously mentioned benefits of social logins, it is advised to set up more than just one sign-up option on your platform.

These formerly mentioned social login methods are included in ZITADEL's basic plan and are therefore **entirely free for all users**.

Furthermore, the software doesn't require you to fully integrate every login provider separately: As an **[identity broker](https://zitadel.com/features#brokering)**, ZITADEL acts as a **trusted intermediary service** c**onnecting your projects with different identity providers** so that you only have to link the external identity providers to it. This feature is especially beneficial since embedding numerous Identity Providers directly into your apps is complex to maintain, time-consuming to set up, and hinders single-sign-on of users.

## The Takeaway

Social logins provide benefits to both your organization and your users. It boosts conversions, reduces the stress on your support teams, and simplifies the checkout for e-commerce brands. By expanding the number of supported identity providers, ZITADEL will ensure that all your users can effortlessly sign up for your platform with their preferred social identity.

We would love to hear your input on [which social logins](https://github.com/zitadel/zitadel/issues/2998) we should integrate first.

Should you have questions regarding social logins or any related (or unrelated) topics, please contact us anytime on our ZITADEL Discord Server. Alternatively, you can reach us on our Twitter, Linkedin, Github pages, or our website.

Don't forget to give us a star over on GitHub if you like the project. Thank you for the support.


Besides their obvious advantage of increased login convenience, social logins were also proven superior in enhancing business growth. To explain this correlation, it is essential to know how social logins work and how they benefit end-users and companies alike.

Social Logins: The Unexpected Drivers of Business Growth


One of the most common tasks when developing a software is establishing an authentication and identity management system. Whether that system only consists of a sign-up form and a login page or a more complex infrastructure, **the number one priority should always be a** **seamless functionality**: Errors in the implementation can have **catastrophic consequences**. To assure that your software is secure and working as intended, your **identity management system should be implemented and managed by experts** with in-depth knowledge on the topic.

Companies on the lookout for an authentication server have the possibility to **buy functionality from third-party identity and access management (IAM) solutions**, such as ZITADEL. Most of these vendors consist of highly qualified IT-experts who are universally entrusted to **guarantee a safe and error-free IAM system** for software products. Despite a large supply of these purchasable solutions, some firms still choose to build their own authentication server in hopes of saving money or due to distrust in pre-built applications. While a **self-developed solution** might work for some, there are various **potentially unknown drawbacks** that companies should consider before settling for this method. In this article, I will discuss the risks and disadvantages of building your own authentication server.

## Common shortcomings of self-built Authentication Servers

### 1. Security Issues

The most significant risk of building your own authentication server lies in its generally **higher probability of security issues**. Since keeping your users’ data safe is among the greatest responsibilities of a platform and the primary task of an IAM server, it is essential to make sure an adequately established security system is a given. One of the most obvious advantages IAM vendors have over DIY developers is the possession of a **dedicated team with IT and engineering expertise**. The members of these teams can utilize their knowledge to create the **best possible security system** based on their diverse experiences. Additionally, IAM vendors commonly offer **advanced security features**, such as support for multi-factor authentication (MFA) and security keys. Another security aspect where third-party IAM solutions prevail is **error prevention**: They can **prevent attacks more easily due to their large user base**, whereas a custom-made solution does not possess enough data to recognize suspicious patterns.

### 2. Not as cheap as you think

Contrary to popular belief, you will likely find that **building your own authentication server is not cheaper in the long run**. While you initially save some money by not having to purchase the solution itself, it will quickly be **compensated by the cost of development, maintenance, troubleshooting, upgrades, and the resources** themselves that are needed for these procedures. It is also worth noting, that since your main product is likely in an unrelated field to the IAM itself, the inevitable **shift in your working context would entail additional costs**. When considering a handcrafted solution, it is therefore beneficial to evaluate if the needed investments over the lifetime of your product are ultimately less than the amount you would have to pay for the one-time fee of the purchasable alternative.

### 3. Complex and Time-consuming

When creating anything from scratch, you should probably reckon with a lengthy production process. The same principle applies to developing a server; given that authentication solutions **require lots of API programming and complex security features**, fully building one might take at least a year as a full-time job. Since the server will handle sensitive data, the development of an adequately functioning security system also involves **constant testing and optimizing**, which should not be neglected to save time. The need for handcrafted features also extends to the product phases beyond the initial development: Keeping your application functional and up to date requires you to **additionally establish a maintenance system** that will serve this purpose. Purchasing an already established IAM solution would therefore likely **save you several years of time, and money spent on essential resources**.

## What you can do instead

In conclusion, even if you are an experienced programmer or your company possesses a dedicated IT-team, you will likely find that **your time and effort will be better spent developing and optimizing your main product**. Afterall, facilitating the job of software developers by not having to worry about building a dedicated authentication server on top of programming every other aspect of their application is the primary reason third-party IAM solutions exist. **Buying functionally is therefore our clear recommendation if you strive for maximized security and wish to save time and money**.

Should you be worried about being restricted by the ready-to-use features of a third-party IAM platform, **ZITADEL customers** have the possibility to choose a **self-hosted deployment option**. While this method still requires more resources compared to the software as a service alternative, it allows you to have full control over your authentication system without having to create a whole server from scratch.

## The Takeaway

If you wish to receive a pre-established IAM solution instead of having to handcraft it yourself, **ZITADEL ensures** **the best possible authentication server** with its flexible pricing options, diverse deployment options, generous range of features, guaranteed high security and unlimited identities for all instances.

Should you have questions regarding authentication servers or any other related (or unrelated) topics, feel free to contact us anytime on our ZITADEL [Discord Server](https://zitadel.com/chat). Alternatively, you can reach us on our [Twitter](https://twitter.com/zitadel), [Linkedin](https://www.linkedin.com/company/zitadel/) or [Github](https://github.com/zitadel/zitadel) pages or on our [Website](https://zitadel.com/contact).

If you like the project, don't forget to [give us a star over on GitHub](https://github.com/zitadel/zitadel/stargazers). Thanks for the support.


Despite a large supply of purchasable solutions, some firms choose to build their own authentication server. While this solution might work for some, there are various potentially unknown drawbacks that you should consider before settling for this method.

The Truth About Building Your Own Authentication Server


## Definition of serverless

When people talk about serverless it is oftentimes not clear what they mean exactly. So let&apos;s begin with shining a light on what we think of when we talk about serverless.

For us, serverless is the possibility to run ZITADEL without the need to manage the underlying computing, networking and storage.

From our perspective there are two options we would classify as serverless: Firstly, function as a service (FaaS) offerings and secondly container as a service (CaaS) or you can call the latter serverless containers. Some serverless containers are run on top of managed Kubernetes offerings with the help of Knative.

## Why we think serverless is a thing

Since our early days we committed ourselves to containers and Kubernetes to run and deploy ZITADEL. Be it with customers or our public cloud offering. In the last few months three points, which needed to be addressed, did come to our attention because we asked ourselves how we could reduce our operation expenses while still being able to scale.

### Easier global scaling

As mentioned earlier, we run ZITADEL distributed across the globe to give our customers the best latency available. But with the rising need for new points of presence, we experienced that the management (updating, scaling, …) of multiple Kubernetes clusters gets quite annoying. Not even taking into account that we also needed to deploy our observability toolings and ZITADEL at scale as well.

### Easier deployment for developers

Many of our users did ask us, if it is possible to run ZITADEL without Kubernetes, especially for small deployments or developers who want to run ZITADEL locally.
We totally understand that it is not feasible for many people to operate Kubernetes. Even with platforms like Ranchers k3s and kubeadm, alongside the hyperscalers offerings from Google&apos;s GKE over Amazon&apos;s EKS to Microsoft's AKS.

### Kubernetes compatibility

While we want to provide alternatives to Kubernetes usage we still want our customers to have the option of running ZITADEL on their existing clusters.

With those three points in mind we set off to create a solution that can improve the way somebody can run and scale ZITADEL to new heights.

## How we are (working on) harnessing serverless

Although we are not yet running our production with a serverless service, we have been testing one for many months with our internal environments. We chose to thoroughly test Google's serverless containers offering which is compatible with Knative which is called “Google Cloud Run”. This, because it allowed us to address all of the three goals which triggered this journey.

**Scaling**: We can deploy ZITADEL across the globe (> 26 Regions) with a few lines of Terraform within mere minutes

**Deployment**: We can run a dedicated ZITADEL with little fixed cost with “Google Cloud Run” and “CockroachDB Cloud serverless” offering

**Compatibility**: While being fully serverless, ZITADEL still stays completely compatible with Kubernetes

Customers that wish to self-host ZITADEL can either choose to leverage the Google Cloud Run setup, as we use it in our cloud service, or use any of the alternatives, namely running on any CNCF-compliant Kubernetes or even as binary.

## The challenges

To make ZITADEL run great on serverless offerings we needed to address some challenges.

**Scheduled Tasks:** Some of the processes of an IAM happen on a scheduled basis and we need a way to address this without relying on an external system. So as of today we recommend keeping at least one instance of ZITADEL running. With Cloud Run this can be easily solved by setting the “minimal instance” property to something like > 0.

**Async Tasks:** When ZITADEL is invoked some of the requests are run asynchronously. To cater for this it makes sense to tell the serverless platform to allow CPU usage after a request finished. With Cloud Run you can enable “always-on” CPU allocation. This allows ZITADEL to finish certain tasks. For example writing traces, calculating read models and so on.

## The gains

**Observability:** Although not serverless specific, the integration of Cloud Run in Google's observability stack is impressive. For example out of the box opentracing works and provides the traces from the load balancer towards ZITADEL.

**Scaling:** Cloud Run allows you to scale horizontally (more containers) and/or vertical (more CPU/Memory) in combination with the cloud load balancer it even allows to create multiple deployments in parallel to even further scale either inside or across multiple regions.

**Worldwide:** As already mentioned with a few lines of Terraform it is possible to run ZITADEL across multiple regions with ease. All of this without the need to manage the deployment target.

**Testing:** Cloud Run already allows A/B testing where a percentage of requests are steered towards a newer version. While this is useful we use this feature in conjunction with the load balancers capabilities to route certain domains to a specific release.

**Cost:** Even though ZITADEL is configured to be always running with at least one container, Cloud Run makes for a cost effective solution. This is because the initial cost of running a new datacenter is relatively low (less than $60 per region).

## What will improve with ZITADEL v2

As you might be aware, [we are currently working on a major update of ZITADEL](/blog/six-ways-zitadel-will-improve-2022). Some of that work is specifically geared towards improving ZITADEL for serverless containers as well as the option to run it locally without any containers as self-contained binary.

With the release of v2 we will add support for the following features:

- Serverless Deployment to Google Cloud Run
- Support for [CockroachDB serverless](https://www.cockroachlabs.com/get-started-cockroachdb/) DB

To improve the life of developers who want to run a local ZITADEL we also release the following improvements

- Self-Contained Binary so that ZITADEL works without running in a container
- Additional CPU Architectures (ARM64)
- Additional OS support (MacOS, Windows)

## When is v2 due to release

The initial release of v2 is just around the corner and is aimed towards the end of April - early May.

If you are interested in participating in our early adopter program and the new pricing, [please send us a message](/contact).

## What&apos;s next

We will soon publish the new pricing and some more blogs and information about the v2 of ZITADEL on our website that we will also link in this section. So stay tuned.

If you want to catch us live you will find us at the following events in the near future:

- [Swiss Cyber Security Days](https://swisscybersecuritydays.ch/), April 6./7. 2022, Fribourg, Switzerland
- [Deutscher Startup Pokal](https://www.eventbrite.de/e/deutscher-startup-pokal-digitales-2-halbfinale-security-tickets-164279774227), April 7. 2022, Online
- [Cloud Native Computing Switzerland](https://www.meetup.com/Cloud-Native-Computing-Switzerland/events/279925165/), May 12 2022, Zurich, Switzerland

Of course if you want to get in touch, feel free to [contact us](/contact) or join [our chat](/chat).


With the rise of serverless and our need to scale, we wanted to explore the possibilities and values that modern serverless platform provides.

A serverless future


With the **introduction of the authentication standard SAML 2.0** coming soon to ZITADEL, you will be granted the possibility to choose between the **two most trusted identity protocols**: The previously implemented “OpenID Connect (OIDC)” and the new addition “Security Access Markup Language (SAML)”.

To help you determine which protocol is best suited for your use case, this article carefully explains the similarities and key differences between the two standards and what they each have to offer.

## Similarities

Both SAML and OIDC provide a **means of authentication**: They are responsible for **securely transmitting user information** between the system that is doing the authentication (the Identity Provider) and the service or application the user is attempting to access. Both standards offer centralized authentication, also called **single sign-on (SSO)**, which allows the user to **access multiple applications using a single login credential** (username, password, token etc.). This process helps users to spare the time they would spend registering to multiple apps one-at-a-time, by maintaining a centralized database. A notable example of a SSO solution is Google: Using a single account, it is possible to access a wide variety of applications, such as _Gmail_, _Youtube_ and _Google Drive_.

## Differences

After having inspected what the two standards have in common, it is important to examine the characteristics that set them apart. While the key goal of SAML 2.0 and OIDC is identical, the **approach used to authenticate users differs in method and technology**.

Given the notable age difference between the protocols, the younger standard (OIDC) was developed with scalability and a simpler implementation in mind, to meet the expectations of today’s users, whereas SAML had more time to effectively establish a wider range of security features. To help us illustrate the main dissimilarities between the two standards more clearly, we have created the **following table that provides an overview of these differences**:

<table>
  <tr>
    <th>&nbsp;</th>
    <th>SAML2.0</th>
    <th>OIDC</th>
  </tr>
  <tr>
    <td>
      <strong>Security</strong>
    </td>
    <td>
      More trusted due to its exceptionally high security level, however even
      the basic security-features need to be implemented individually.
    </td>
    <td>
      A newer protocol, which is actively being improved based on new threat
      vectors. Easier to adhere to 'best practice' code flows.
    </td>
  </tr>
  <tr>
    <td>
      <strong>Implementation</strong>
    </td>
    <td>
      Generally complex to implement and maintain; not recommended for mobile
      applications.
    </td>
    <td>
      Very simple to implement and commonly used for mobile applications and
      single-page apps.
    </td>
  </tr>
  <tr>
    <td>
      <strong>Message format</strong>
    </td>
    <td>
      Sends heavy-weight XML messages for authentication via SOAP, a protocol
      layer on HTTP.
    </td>
    <td>
      Passes light-weight JSON Web Tokens (JWT) or opaque tokens via RESTful API
      communication to exchange authentication information.
    </td>
  </tr>
  <tr>
    <td>
      <strong>User consent</strong>
    </td>
    <td>
      Consent flow requires hard-coding and is therefore not a built-in part of
      the protocol.
    </td>
    <td>
      Offers a built-in layer of authorization (consent flow) that asks a user
      to consent to what the service provider might access.
    </td>
  </tr>
  <tr>
    <td>
      <strong>Authentication process / Connectivity</strong>
    </td>
    <td>
      To provide authentication, IdP and the relying party must be configured to
      know each other
    </td>
    <td>
      IdP and the relying party don’t have to identify each other; faster and
      more resource-friendly
    </td>
  </tr>
  <tr>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>
      <strong>Biggest Strengths</strong>
    </td>
    <td>
      Can offer the highest possible security, as there is a lot of customizable
      functionality, but only as long as the implementation covers certain
      security threads.
    </td>
    <td>
      User-friendliness, interoperable with SPA and mobile applications, ongoing
      maintenance of the standard.
    </td>
  </tr>
  <tr>
    <td>
      <strong>Biggest Weaknesses</strong>
    </td>
    <td>
      Lengthy and complex implementation and maintenance of each feature
      one-by-one: higher risk of errors and malfunction.
    </td>
    <td>
      Offers less features than SAML (f.e. dynamic specification of proxy IdPs
      is not fully supported).
    </td>
  </tr>
  <tr>
    <td>
      <strong>Commonly used by:</strong>
    </td>
    <td>
      Enterprise- and government-scale activities working with sensitive data.
    </td>
    <td>
      Businesses highly prioritizing performance-friendliness and an additional
      implementation in mobile-applications.
    </td>
  </tr>
</table>

## Which tool is best for you?

In conclusion, **none of the two standards can be classified as the objectively better option**: Ultimately, both will serve their main purpose of authentication in a safe and secure manner and are therefore **equally well suited for traditional Web Applications**. However, they do have their own respective advantages and disadvantages, which usually makes one of them the more practical choice depending on the specific usage context. To make a calculated choice on whether you should implement SAML or OIDC, it is essential to **evaluate the core values, preferences, and the target audience of your organization**. Accordingly, the final decision is only yours to make.

Given the previously mentioned differences between the standards, we can however give you some **recommendations on the use cases** for SAML and OIDC respectively:

- OIDC is probably the better choice if you do not want to invest in learning XML, or you need to work with Mobile- or SPA-type Applications or REST APIs. Also for green-field projects OIDC is typically the better pick between the two.
- If your application already has tools and libraries supporting SAML, then it is advised to continue with. SAML is also recommended if your business deals with sensitive data and requires the highest possible security.
- Should you be completely torn between the two standards, our general recommendation is to go with OIDC; due to its user-friendliness and easy implementation you will likely find it easier to pick up and maintain.

If you would like to enjoy the benefits of both standards to their fullest, you also have the possibility to adopt a **hybrid usage**: Since the two protocols serve the same purpose, but you’re not restricted to use the same protocol for all your applications, the best-used protocol can change for each of your organization’s applications.

In ZITADEL you can have both OIDC and SAML 2.0 applications within one project, sharing the same roles and user authentications. With token exchange between the two protocols, it will be **possible to use both seamlessly for federated authentication across different client types**.

## How to proceed

Should you have questions regarding SAML and OIDC or any other related (or unrelated) topics, feel free to contact us anytime on our ZITADEL [Discord Server](https://zitadel.com/chat). Alternatively, you can reach us on our [Twitter](https://twitter.com/zitadel), [Linkedin](https://www.linkedin.com/company/zitadel/) or [Github](https://github.com/zitadel/zitadel) pages or on our [Website](/contact).

Did you know that ZITADEL is OpenID Connect certified? [Read more](/blog/openid-connect-certification).

**SAML 2.0 will be available on ZITADEL starting at the end of March 2022.** Visit [zitadel.com/roadmap](https://zitadel.com/roadmap) for more information.


To help you determine which protocol is best suited for your use case, this article carefully explains the similarities and key differences between the two standards and what they each have to offer.

SAML vs OIDC: Which Protocol is Best for Your Organization?


Access tokens, as the name suggests, are an essential part of Identity and Access Management (IAM) Services: They are used to grant access to client resources. Since they contain such sensitive data, access tokens must be kept confidential in transit and in storage; the respective application should therefore ensure that the token is not accessible to other apps on the same device.

Access tokens come in different formats, all of which have their respective uses. So far, ZITADEL has allowed **JSON Web Token (JWT) Profile** for authentication of Service Accounts. This month, we are expanding the possibilities of our platform by introducing **Personal Access Tokens (PAT)** that can be enabled along with an existing JWT profile.

In this Article, I will explain **why we have chosen to introduce PAT** in addition to JWT, **which audience this change will benefit** and **how PAT can be implemented** into the ZITADEL console.

As a first step, it is essential to know what JWT and PAT have to offer.

## JSON Web Tokens (JWT) and their application

JSON Web Token (JWT), is a compact and **self-contained** open standard used to **share security information between a client and a server** in a structured format (JSON). It is commonly used as an access token (for authorization and securing APIs) by specific protocols such as OAuth 2.0.

The use of access tokens is that they must be passed upon every request of an application to access routes, services, or resources (f.e. APIs) to confirm the user's authorization. Some solutions **might not support JWT Profile for Machine-to-Machine (M2M) communication**, although it is the preferred method to authenticate Service Accounts in terms of security.

## Personal Access Tokens (PAT) and why they are needed

Personal Access Tokens are **opaque tokens**, i.e. no information can be extracted from the token itself, that enable granular access to a specific resource. This procedure is generally useful for interrogation with 3rd-party systems that use the respective platform to store records, and don't want to proxy all the protected resources via their system. In the case of ZITADEL, PATs were implemented to **provide an alternative method of authentication for Service Accounts**.

Although not as secure as JWT Profile, PATs are helpful for service users that have **trouble integrating their Service Accounts with the preferred method**. If this type of problem arises, it is advised to enable PAT along with JWT Profile. The token will grant access to all rights assigned to the user (within ZITADEL itself (manager roles) or in other projects by user grants). You should always limit the lifespan of a PAT and refresh regularly (e.g. every 30 days) to minimize security risks.

## How to set up PATs on the ZITADEL console

Should you be interested in using Personal Access Tokens, it is vital to know how it is done. In this chapter, we show you a step-by-step tutorial on how to enable PATs on the [ZITADEL Console](https://console.zitadel.ch/).

Upon signing into the ZITADEL Console, navigate to the Menu on the left of your screen. On the top left, **select the organization** you wish to assign the token to (here: Test2). Next, click on the menu item **“Service Benutzer / Service User”**.

![](/blog/2022-03-03-new-personal-access-token-01.png)

Clicking the “Service Benutzer / Service User” menu item should lead you to the page pictured below. To create a new Access Token, scroll down to the option called **“Access Tokens”** and click on the button **“+Neu / +New”**.

![](/blog/2022-03-03-new-personal-access-token-02.png)

A small new window should pop up on your screen, asking you to **define a custom expiration for the token** you are about to generate. If you wish for your PAT to **only be valid through a specific timespan**, enter the desired expiration date into the input field or select it using the calendar icon on the right, then click the button **“Hinzufügen / Add”**.

![](/blog/2022-03-03-new-personal-access-token-03.png)

Whether you chose to enter an expiration date or not, upon pressing the **“Hinzufügen / Add”** button, another small window should be revealed. The message in red will **warn you to copy the long token code, for you will not be able to access this code again**. To do so, **click on the clipboard icon** next to it. Once the code is copied, you can close the small window by pressing the **“Schliessen / Close”** button.

![](/blog/2022-03-03-new-personal-access-token-04.png)

Following the previously listed steps should result in the creation of a Personal Access Token for your desired organization. Finally, the copied token code can be embedded **as a bearer token in the authorization header** into the ZITADEL application via a third-party service.

See our [documentation](https://zitadel.com/docs/) for more details.

![](/blog/2022-03-03-new-personal-access-token-05.png)

## In Conclusion

If you are a service user and have trouble with integrating your accounts with JWT Profile, consider enabling a Personal Access Token along with JWT Profile.

Should you have questions regarding PATs, JWTs or any other related (or unrelated) topics, feel free to contact us anytime on our ZITADEL [Discord Server](https://zitadel.com/chat). Alternatively, you can reach us on our [Twitter](https://twitter.com/zitadel), [Linkedin](https://www.linkedin.com/company/zitadel/) or [Github](https://github.com/zitadel/zitadel) pages or on our [Website](https://zitadel.com/contact).


In this article, we will explain why we have chosen to introduce PAT in addition to JWT, which audience this change will benefit and how PAT can be implemented into the ZITADEL console.

New Personal Access Tokens (PAT): A game changer for Service Users


In our ongoing efforts to ease the integration of applications to ZITADEL we already certified the first Go library for OpenID Connect for relying party usage back in July 2021.
And today we are happy to announce that ZITADEL has been officially certified by the OpenID Foundation for the “Basic OP” profile.

These certifications prove that ZITADEL implements the OpenID Connect protocol according to the specifications and that your relying party is guaranteed to work, if it follows the specification.

If you are interested in more details you can checkout ZITADEL [here](https://github.com/zitadel/zitadel), our Go library [here](https://github.com/zitadel/oidc) or visit the [OpenID Certification page](https://openid.net/certification/)


We are happy to announce that ZITADEL has been officially certified by the OpenID Foundation for the “Basic OP” profile.

OpenID Connect Certification


## Tl;dr

Kubernetes clusters along with all the tooling needed for operating a production grade service should be disposable just like its nodes and pods are disposable. This principle enables you to re-architect your whole infrastructure, solve a lot of your present problems and have a good sleep at night for your services’ full lifecycles.

Treating clusters as cattle enables you to run many small clusters, e.g. one for each domain and environment. As a result, you are comfortable with all day-two operations like keeping the Kubernetes, tooling, operating systems and package versions up-to-date, because you have perfect isolation and similar environments.

In order to achieve this similarity, you choose to follow the GitOps pattern, not only for your service deployments to be reproducible. Also the desired states for the tooling, the Kubernetes installation itself, CPU, memory, networking and storage you just declare in Git and let operator binaries do their work. With comprehensive GitOps, you have your day-one and day-two operations automated. And you get disaster recovery for free.

By relying on Vanilla Kubernetes instead of a complex platform orchestration machinery like OpenShift or Rancher and by having your infrastructure providers abstracted, you are free to choose and instantly change your vendors. If there is something wrong with the pasture grass, you just move your cattle somewhere else.

Having the reproducibility from GitOps combined with the flexibility of abstracted infrastructure providers and Vanilla Kubernetes makes treating clusters as cattle really easy. This way of automation enables you to run many small, isolated, secure and service oriented platforms whenever and wherever you need them. Luckily, we invented this wheel called [ORBOS](https://github.com/caos/orbos) already. It’s Open Source Software and free to use for everyone.

## The Shaping of Our Philosophy

We at CAOS AG founded our startup roughly two years ago. Back then, most of us worked on a self-developed Identity and Access Management System (IAM) at an E-Government company. As this IAM has grown in users and traffic, we found that we could massively improve the quality of our highly critical service, if we operated it ourselves on top of Kubernetes. As our company didn’t have any Kubernetes cluster available at that time, nor any experience with Kubernetes, we created and maintained one ourselves using Tectonic, which back then belonged to CoreOS (now RedHat). There is not that much to bootstrapping a new small cluster and we had a quick performance gain with all the convenience Kubernetes has to offer.

Soon, developers from other domains of the company started deploying their applications on our cluster too. It was inevitable that at some point in time we ran into pod limits and other problems that came with the cluster’s scale. Experiencing these issues from a service provider's perspective made us wonder if there isn’t a better solution. We concluded that dedicating a Kubernetes cluster to a service, including the infrastructure and tooling, improves a provider's ability to guarantee its quality. We saw our chance to go to market with a brand new Cloud Native IAM [ZITADEL](https://zitadel.com/) on our own, distinguishing it from other IAM vendors' products by including the automation for small and dedicated Kubernetes clusters.

If you need arguments for running many small clusters instead of a big one and solutions for doing so without increasing your operational costs, read on.

<div className="team-members">
  <img src="/blog/2021-06-30-cattle-not-pets-03.jpeg" alt="Florian" />
  <img src="/blog/2021-06-30-cattle-not-pets-04.jpeg" alt="Christian" />
  <img src="/blog/2021-06-30-cattle-not-pets-05.jpeg" alt="Silvan" />
  <img src="/blog/2021-06-30-cattle-not-pets-06.jpeg" alt="Fabienne" />
  <img src="/blog/2021-06-30-cattle-not-pets-07.jpeg" alt="Max Peintner" />
  <img src="/blog/2021-06-30-cattle-not-pets-08.jpeg" alt="Stefan" />
  <img src="/blog/2021-06-30-cattle-not-pets-09.jpeg" alt="Elio" />
  <img src="/blog/2021-06-30-cattle-not-pets-10.jpeg" alt="Michael" />
  <img src="/blog/2021-06-30-cattle-not-pets-11.jpeg" alt="Jürg" />
  <img src="/blog/2021-06-30-cattle-not-pets-12.jpeg" alt="Livio" />
  <img src="/blog/2021-06-30-cattle-not-pets-13.jpeg" alt="Max Panne" />
</div>

From left to right: Florian Forster, Christian Jakob, Silvan Reusser, Fabienne Gerschwiler, Max Peintner, Stefan Benz, Elio Bischof, Michael Wäger, Jürg Rinaldi, Livio Amstutz, Maximilian Panne

## Isolate Your Domains

Doing DevOps means that dev and ops engineers have a common goal, which is providing good service quality. The ops side traditionally needs to run many services from many domains with different quality requirements on the same infrastructure and platform. This makes it hard to serve the developers the exact infrastructure they need. Imagine each domain has its own production cluster and a set of test clusters. The clusters are guaranteed to never interfere with each other on the operating system level through NFS volumes, resource consumption and the like.

If the tech stack is siloed along its services all the way down to the infrastructure, not only can each stack be precisely tweaked to the domains and services needs. The tweaker is also more confident in doing so, because he is absolutely sure his tweaks have no unforeseen negative impacts on other domains. If something goes wrong, then not the whole company is at risk that the lights go out, but the blast radius is limited to that domain only. The improved confidence leads to more security updates, feature updates and configuration optimization of the infrastructure, tooling and the API Gateway.

<img
  src="/blog/2021-06-30-cattle-not-pets-01.jpg"
  width="100%"
  alt="Fireball Comparison"
/>{" "}

Fireball_comparison_pic.jpg found on [wikipedia.org](https://en.wikipedia.org/wiki/File:Fireball_comparison_pic.jpg)

## Manage Your Desired States Only

You might be thinking that the operational costs would grow almost linearly with the number of clusters. And that’s true for all tasks that you manually execute. Manual tasks are not only expensive and error prone, they also lead to hardly reproducible states which decreases your confidence and performance when doing day-two operations. So you are forced to automate each of them. Currently, the GitOps pattern is gaining adoption for Kubernetes workload deployment. But it’s very suitable for the platform and infrastructure as well. With GitOps, you focus on automating day-two operations and let a system reconcile its current state based on a declared desired state. If anybody changes something in the system, the reconciling operator reverts the changes immediately and brings the system back to its desired state. So with GitOps you are guaranteed to have a self healing and reproducible system over time.

In [this blog post](https://blog.atomist.com/kubernetes-clusters-pets-or-cattle/), David Dooling from Atomist is advocating the GitOps pattern for solving the reproducibility problem too. But he focuses on storing the Kubernetes resources declarations in Git and relies on managed services and third party CLI tools for bootstrapping new clusters. I think this doesn’t scale well if you want to run many small clusters instead of few big ones. If you need to reproduce a cluster along with its infrastructure, you need the desired infrastructure state to be declared somewhere, preferably in a provider independent way. The other point is, that when storing a mess of hundreds of Kubernetes resources in Git for many clusters in a “copy-and-own-way”, your clusters will start to behave differently from each other over time until their differences are not manageable anymore.

[ORBOS](https://github.com/caos/orbos) fills this gap. Our ORBOS operators interpret their self defined desired states and translate them into cloud and Kubernetes resources. This abstraction layer not only leads to having just a fraction of YAML stored in Git, also the differences in cloud provider infrastructure is as minimal as possible and transparent in their YAML. With ORBOS, you can scale to thousands of clusters without having to employ tons of engineers. [Here](https://github.com/caos/orbos/blob/master/examples/orbiter/gce/orbiter.yml) you find an example YAML for the infrastructure and [here](https://github.com/caos/orbos/blob/master/examples/boom/boom.yml) is a dead-simple one for the platform tooling that omits all default values.

<a href="https://github.com/caos/orbos">
  <img
    className="hidden dark:block"
    src="/blog/2021-06-30-cattle-not-pets-14.png"
    width="30%"
    alt="ORBOS Logo dark"
  />
  <img
    className="block dark:hidden"
    src="/blog/2021-06-30-cattle-not-pets-15.png"
    width="30%"
    alt="ORBOS Logo light"
  />
</a>

## Easily Recover from Disasters

When a cluster goes down, you need to be able to bring back your service’s last state from scratch. To prepare for this, you have to make your workload’s state declarable. This means for example, that all database schema changes should be tracked, tied to your services version and re-executable at any time in an idempotent way. For example, we built a ZITADEL operator that uses [Flyway](https://flywaydb.org/). Check it out on [GitHub](https://github.com/zitadel/zitadel). When your whole workload is declared, you can easily replicate it to another cluster. But in a disaster recovery case where the whole cluster goes down, you might be in trouble getting the declarations out of the broken cluster. Here is where GitOps is helping out again, because with GitOps, you have your desired state declarations stored out-of-band. For learning more about our understanding of using GitOps for workload deployment, checkout [Christian Jakob's blog post](https://zitadel.com/blog/dev-gitops-at-caos/) in German.

Now, combine that with a GitOpsed tooling, platform and infrastructure described in the previous chapter. If done right, a comprehensively “gitopsed” environment is absolutely bulletproof in almost all failure cases. As GitOps comes with perfect reproducibility, you can test if you’ve done it right as much as you want just by replicating your systems. Congratulations, from here on, you can just kill your cattle instead of taking them to a doctor like they were pets. For being bulletproof in not almost all but really all failure cases, read on.

<div className="giphy-wrapper">
  <iframe
    src="https://giphy.com/embed/QMHoU66sBXqqLqYvGO"
    width="100%"
    height="100%"
    frameBorder="0"
    className="giphy-embed"
    allowFullScreen
  ></iframe>
</div>
<p>
  <a href="https://giphy.com/gifs/this-is-fine-QMHoU66sBXqqLqYvGO">via GIPHY</a>
</p>

## Avoiding Lock-Ins

Cattle care less about its owner or territory than pets do. A Cluster on Google Compute Engine should be seamlessly reproducible with other cloud providers and also on-premises if your requirements for prices, data policies, locality etc. change. If you use managed Kubernetes clusters like GKE or AKS, you will have many fancy and integrated features like monitoring or networking. This is comfortable but comes at the cost of a vendor lock-in causing much headache when you try to move to another provider. Especially in cases of critical networking or hardware failures you are glad if you have multiple infrastructure providers abstracted so they are at your disposal immediately.

Also, your workload and Kubernetes API should not rely on the cluster and infrastructure management systems. The operator you use should utilize a generic tool like Kubeadm to maintain the clusters lifecycle and avoid depending on critical API server intermediating components that also need energy and time investments. Without these additional moving targets, you are way more safe from getting locked in to the operator vendor. For example, if you would like to stop using ORBOS and move to another infrastructure and platform management, the only thing you have to do is to delete its deployments. If the operator is stopped or the operator throws errors, neither your service quality nor the Kubernetes API is affected.

<a href="https://kubernetes.io/docs/reference/setup-tools/kubeadm/">
  <img
    src="/blog/2021-06-30-cattle-not-pets-02.png"
    width="20%"
    alt="Kubeadm Logo"
  />
</a>

kubeadm-stacked-color.png found on [kubernetes.io](https://kubernetes.io/docs/reference/setup-tools/kubeadm/)

## Real World Experience

Implementing our GitOps operators definitely took some time and energy. But in return, it enabled us to scale massively and maintain many clusters now. Each cluster is perfectly monitored in a centralized Grafana Cloud instance. If something goes wrong, we fix the operators' code and roll it out to all clusters. Instead of accidentally fixing the same issues again and again, we improved the maturity of our operators incrementally. Now they are in a solid state where they just work and let our customers and us have a good sleep each night.

Treating clusters as cattle enabled us to expand our business model in selling our IAM service [ZITADEL](https://zitadel.com) too. We are not only a Software-as-a-Service provider but also deliver the whole automation needed to run instances dedicated to customers in isolated environments of their choice too. It is crucial for many companies to have full control over all user data stored in our IAM solution, so they often need dedicated instances deployed in their own data centers. An IAM is a mission critical central system that has high quality and scalability requirements to the infrastructure. With our automation, customers yet do not have to assign engineers to the task of operating our product. So the costs that our product causes over time keep being limited and calculable, thanks to our GitOps operators. This gives us a significant advantage over our competitors.

Apart from selling ZITADEL, ORBOS also gave us the opportunity to offer maintenance and support for dedicated Kubernetes clusters. Also, there is a tech company that is running about twenty Kubernetes clusters using ORBOS, split along its domains. Another software agency is running their services on multiple ORBOS managed Kubernetes clusters dedicated to end customers.


I’m sure you know the phrase “treat NODES as cattle, not pets”. It means that we’d rather just replace a “sick” instance by a new healthy one than taking it to a doctor. We take it to another level and say “treat CLUSTERS as cattle, not pets”.

Treat Kubernetes Clusters as Cattle, Not Pets


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

All posts/ #engineering