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

Read the blog

Sign up

Login

Pricing

Jobs

Blog


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


Ever since we have officially launched our IAM-Platform in May of 2021, we have had the pleasure to serve hundreds of customers, who have put their trust in us. As a company that always strives for innovation in an ever-changing digital world, our biggest goal is to provide our customers with the best possible user-experience and the most value for their money by constantly keeping ZITADEL up-to-date: In this article, we describe 6 great upgrades coming soon to our platform, that help making this goal a reality.

## 1. More social login options

Whether Google, Microsoft, or Apple ID - Most of us have already used some of our social identities to facilitate sign-ups on third-party applications and websites. This login method not only saves valuable time by not requiring the completion of a registration form, but also spares you the effort of remembering yet another password. This year ZITADEL will strive to **heavily expand the number of its Identity Providers**, assuring its users a comfortable login via their preferred social identity. Whereas thus far, ZITADEL has exclusively supported OIDC compliant providers, this restriction will soon be completely removed in order to provide a wider range of options.

A list of social identity providers soon available on ZITADEL:

- Apple ID
- Microsoft Live
- Github
- Gitlab
- Microsoft Tenants (AzureAD)

… And hopefully many more to come!

## 2. SAML 2.0 - New protocol alternative

In 2021, ZITADEL officially implemented **OpenID Connect (OIDC)**, a highly accessible authentication protocol, excellently suited for HTML5/JavaScript applications. Despite it being an ideal choice in terms of user-friendliness, scalability, and lightweight handling, as a new protocol, OIDC has yet to evolve in terms of establishing a more complex security system.

To allow our users the choice of a viable alternative, we are planning to **additionally introduce the other adopted industry standard for authentication, SAML 2.0** (Security Assertion Markup Language). Like OIDC, SAML allows a service provider to delegate the authentication and authorization of users wishing to access it, to a central authentication server (identity provider). Both standards are utilized in various SSO solutions, however, SAML is universally more trusted in enterprise- and government-scale activities due to its age.

This new, simultaneous access to both protocols will give you more options on which method of authentication you want to use. 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 different purposes**, the standards can diverge between each of your applications. For instance, while OIDC is the ideal choice for mobile-centered apps, SAML finds its primary implementation in web programs, where complex identity data is required. Whichever features you prioritize; the range of possibilities is wider than ever!

## 3. Improvements based on prototype feedbacks

The key to ensuring a highly accessible and frictionless user experience is to **focus on satisfying the audience**. To achieve this goal, it is essential to have the audience **test and evaluate the product first-hand**: This method is called prototyping. Ideally, every new iteration of the product (or in this case: website) should be reviewed by diverse members of the user-base and optimized accordingly. After all: Evaluating prototypes can spark new ideas for future innovations.

In December of 2021, we invited a group of users (aged 16-44) of varying digital-affinities, to test the registration flow, including the existing 2-Factor-Authentication of ZITADEL. Upon carefully reviewing every feedback, we could identify some common user pain points that are impairing the authorization experience. For this reason, in 2022 we will **improve the registration process by implementing the following changes**:

- Ensuring higher accessibility by removing exclusionary language (Technical jargon).
- Providing support for users with help and information texts.
- Adding “passwordless” as a registration method - no more passwords needed.
- Clearing user flow where next actions are clearly highlighted.
- A new, optimized user interface for the existing management website.
- Smaller optimizations of buttons and descriptions, minimizing possible confusion.

## 4. Accessible and exportable Usage Metrics

As a platform working with sensitive data, it is especially important for ZITADEL to be constantly improved to meet tomorrow's increasing standards. With the help of usage metrics, we are able to continuously measure the platform's effectiveness and thus rapidly identify and fix potential inefficiencies. These metrics are **not only excellent tools of risk reduction, but also help us improve operational quality**, thus keeping ZITADEL sustainable.

In 2022, we will **display the most important usage metrics together with useful business metrics in our Console**. Such metrics are shown as a sequence of data points over an interval of time, and include:

- Number of active users
- Number of successful vs. unsuccessful login attempts
- Number of new registrations

Additionally we will improve reporting capabilities, thus making **data more easily readable and exportable for your administrators**. One example of such a report is a list of users for a given organization. With the new reporting capabilities you can add a column showing whether a user has enabled 2FA, filter that column by users who have not yet enabled 2FA and export the values to a structured data format.

## 5. Your own instance - New customized domain and data location

At ZITADEL, we strongly believe that security features should not cost extra. Accordingly, all our tiers include unlimited IAM resources and all required security features. So far, when you wanted to operate a complete ZITADEL instance, and not only single organizations, our customers had to **upgrade from a public cloud service to a dedicated ZITADEL instance** or self-host their ZITADEL; therewith only customers of dedicated ZITADEL could enjoy the benefits of complete autonomy over where this system is operated, on which domain it runs, when it should be updated and which default settings should be stored. Whereas this upgrade granted our customers some notable privileges over those potentially constrained by the limitations that come with a shared system, **this advantage will no longer be a feature you have to pay for**.

In 2022, we will launch an **upgrade to every subscription-tier**, that gives you the maximum value for your money: Not only will every subscriber, regardless of their tier, be **granted a virtual instance**, you will now be able **fully configure your own instance policies for each of your organizations** instead of relying on the ones previously predetermined by ZITADEL.

**The benefits of this change include:**

- **A domain that's yours only** - now you can let users login on subdomain such as login.mycompany.ch
- Send transactional emails from your own Mail server
- Choose where your data is stored and processed - whether Switzerland, Europe or global GDPR compliant regions, the location is yours to pick.

In view of these major upgrades that will be made available for every subscription-tier, you might be wondering what further benefits a higher tier could provide. Alongside more customization possibilities, which are already a given, subscribers of our **STANDARD** and **ADVANCED plans** will receive **dedicated private instance**, completely independent from a shared system: Not only will a private instance grant you data isolation from those of other customers, it will also supply **more deployment options regarding infrastructure providers** (such as Azure, AWS and Scaleway) and a wider selection of **data regions**.

## 6. It will be easier to develop ZITADEL

Building a local development environment that mirrors production can be a truly time-consuming workflow. In 2022, we are planning to introduce some significant improvements that should lift some weight off of developers shoulders, by **facilitating the overall process**; implementing new features will soon be easier than ever!

**Following new changes will facilitate the development process:**

- Quickstart will be made possible by executing a single command that will automatically run every asset which was formerly needed to be launched manually (including CockroachDB).
- The ZITADEL binary will be provided for different operating systems and architectures in addition to container images.
- By soon making our product roadmap publicly accessible, you will be able to gain an insight into the features we are planning to implement, as well as the ones currently in development.
- The Documentation will be enhanced with new guides and the decision making will be made public.

## The takeaway

As we have entered a new year, we would once again like to thank you for having put your trust in ZITADEL in 2021. Hopefully, we can successfully express our gratitude to our loyal customers by always improving our platform to make it the best it can be. The team is looking forward to another successful year and we hope to hear your opinion on our new changes!

Should you have questions regarding these improvements 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) (btw. our new handle is just zitadel), [Linkedin](https://www.linkedin.com/company/zitadel/) or [Github](https://github.com/zitadel/zitadel) pages or on our [website](https://zitadel.com/).


In this article, we describe 6 great upgrades coming soon to our platform, that help making this goal a reality.

6 New ways ZITADEL IAM will improve in the year 2022


<a href="https://joshmartin.ch/" target="_blank" rel="noreferrer">
  <img
    src="/blog/2022-01-05-success-story-joshmartin-hygeia-01.svg"
    width="80%"
    alt="Logo of joshmartin"
  />
</a>

[JOSHMARTIN](https://joshmartin.ch/) developed a service for health departments to make tracing of cases , such as SARS-Cov-2 spread, more efficient. ZITADEL was used for secure authentication of users and enabling customers to self-manage their data, settings, and access.

## Key outcomes

- Release of Hygeia within one month with very few resources
- Compliance with strict data governance
- Hosted login and self-service access management for customers provided by ZITADEL

## Challenge

JOSHMARTIN built Hygeia right in the middle of the SARS-CoV-2 pandemic to support efficient contact tracing. The departments for health required a solution for collection and processing of personal data for contact tracing during the pandemic. Data should be accessible only to authorized personnel from the responsible department and should remain in Switzerland at all times. Due to the rapid spread of the pandemic, time-to-market and efficient development was crucial.

## Solution

Some developers of JOSHMARTIN have tried out ZITADEL already before the development of Hygeia and are also familiar with other solutions such as Auth0 that have been used for other projects. Eventually it was decided to go with ZITADEL because of the fast and competent support, as well as data is stored and processed in Switzerland exclusively.

Multiple segregated health departments, each managing their own users, are using Hygeia. For each health department a separate organization was set up and JOSHMARTIN granted the project Hygeia to customers’ organizations. With this setup each department can self-manage their users and access to the application on their own. As this is already built into ZITADEL, minimal development was required for this authorization.

<img
  src="/blog/2022-01-05-success-story-joshmartin-hygeia-02.png"
  width="80%"
  alt="Mockup of an Mac Display showing a browser with a screen of the Hygeia App"
/>

The rigid guidelines on information security required to strictly manage access to the application. This meant on the one hand to provide secure authentication with 2FA and on the other hand fast synchronization of user information and their access rights.

JOSHMARTIN used ZITADEL’s default login flow and allowed customers to manage their own settings regarding the login page and authentication methods. A service account is used to lifecycle users periodically even after the initial provisioning to the application. Highest accuracy was achieved by validating not only the session at the introspect endpoint with each call, but also request user information and roles from the user-endpoint without application-side caching.

The project was implemented when ZITADEL was still in a closed beta version. The teams worked closely together to ensure security, optimal integration, and performance of the systems.

## Result

JOSHMARTIN went live with the first version of Hygeia only one month after project initiation, with only 2 developers and 1 project manager. ZITADEL provides a secure login, user management, and self-service authorization for the multi-tenancy service.

## Future Plans

Hygeia is currently being used by three cantonal health departments. JOSHMARTIN is working towards a greater adoption of Hygeia in other cantons, also through expanding capability to trace not only SARS-CoV-2 cases.

## Testimonials

<img
  src="/blog/2022-01-05-success-story-joshmartin-hygeia-03.jpg"
  width="30%"
  alt="Portrait of Jonatan Männchen on black background"
/>
“What I like is that I can reach out to someone and receive fast and competent feedback
on the request. The team really cares about it.” - Jonatan Männchen

## About the solution

Hygeia is an application for collecting and processing personal and case data in connection with pandemic diseases.
To learn more about the solution and further links at [joshmartin.ch/en/projects/kanton-st-gallen-contact-tracing/](https://joshmartin.ch/en/projects/kanton-st-gallen-contact-tracing/)

Code BEAM V Europe 21 featured a talk about the development of the solution on [YouTube](https://www.youtube.com/watch?v=7ypfyCOfwLo).

Hygeia is cross-licensed under the Business Source License and the Apache License and is available on [https://github.com/jshmrtn/hygeia](https://github.com/jshmrtn/hygeia).

## About Joshmartin

Joshmartin GmbH
Neugasse 51
9000 St. Gallen  
[https://joshmartin.ch](https://joshmartin.ch)

- Specialize in business automation on the web platform
- Focus on finance, insurance and medical sectors in Switzerland
- Team Size: 7

[Download this story.](/blog/2022-01-05-success-story-joshmartin-hygeia-04.pdf)


JOSHMARTIN developed a service for health departments to make tracing of cases , such as SARS-Cov-2 spread, more efficient.

How JOSHMARTIN released a multi-tenancy service for tracing Covid-19 cases in one month with ZITADEL


Most of the common Identity and Access Management solutions have a pricing model based on the amount of users.

In our opinion this model leads to shortcuts in security, such as account sharing amongst users, which should be avoided for higher security and traceability. Also, we believe that security features should just be available and should not cost you extra.

That’s why we decided to develop a price model, where you pay per organization, for the degree of customization, and the guaranteed service level agreement (SLA).

## What does that mean?

In our public cloud service we configured some default settings, which we believe make sense for most of the clients. You can create a single or multiple organizations for which you can choose an individual pricing tier. With higher tiers the organization has more configuration options and a higher guaranteed SLA.

- What you get with every tier of the cloud service:
- Unlimited number of users
- Unlimited number of projects and applications
- 24x7 operations
- Access to our APIs

And a variety of important features such as 2FA/MFA, Passwordless, M2M, Identity brokering etc. are included in all tiers. ZITADEL is a bit different here than what you might be used to from other providers. For security features, we make recommendations through default settings. This might lead in some cases to the fact that you may need to upgrade your subscription to get more customization and thus be able to diverge from best practices.

Lastly you benefit from our [security](https://zitadel.com/pricing#Security) measures that we implement to protect our services.

Let’s go through the different tiers that are available as public cloud service.

## Free Tier

The free tier is perfect when you just start developing your application and like to integrate authentication for no budget. You are still in your local environment and you can test all the features and get a feeling on how ZITADEL works. The thing you are missing in this tier is customization options for your login flow and SLA, but at this point of your project this will probably not be relevant.

## Why upgrade to Outpost?

As soon as your project gets more concrete and may already be in a test environment an upgrade makes sense. You will be able to add some customization and we will also help you with our email support. At this point also the SLA of 99.50% is included.

Some of the features you’ll get that may be important at this point:

- Custom Domain verification: Verify your domain so your users can use it for the login name (e.g. road.runner@caos.ch)
- Private Labeling: Customize your login and emails by uploading your logo and font and configure your corporate colors
- Identity Providers: Change the default configuration and configure your own identity providers, so your users can use an existing account (e.g Microsoft, Azure AD, etc.)
- Audit Log retention for one month

## Why upgrade to Starbase?

Your application is almost finished and you are planning to go live. At this point you should think about how much support and SLA is important. We will provide you with a private chat channel to get in touch with us for your support request where you will have a response time of four hours as well as the SLA will be increased to 99.90% availability.

Starbase will also allow you to configure some more customizations:

- Private Labeling: Customize the messages your users get on initialization, password reset, email verification, etc.
- Add some custom metadata values to your users (Key-Value Store)
- Lockout Policy: Change the user lockout settings
- Audit Log retention for seven months

## Why upgrade to Fortress?

This tier is for customers who require reliable and fast support response. We give you the warranty of responding within an hour and a phone number on which you can reach us. Also if your application should have high availability you should think about upgrading because the SLA will go up to 99.95%.

Moreover this tier gives you the maximum of customization and personalization that ZITADEL can offer. For example you can overwrite any of the texts in the login interface and use all available settings for your organization.

This tier will also include features that we feel cater rather towards legacy implementations, which are typically used in enterprise applications. SAML 2.0 Identity brokering, which will be available early next year, is one of those features that is included only in tier.

You also get 13 months of audit log retention, which is important in case you actually are affected by a breach and need to investigate. You will also benefit from advanced reporting and analytics.

In short: You’ll get everything that we can provide - personal support and all features.

## Why would you need a dedicated instance?

We offer a lot in the public cloud instance. You are, however, constrained by the limitations that come with a shared system.

These limitations include on the one hand performance considerations. Your traffic is subject to our rate [limit policy](https://zitadel.com/docs/legal/rate-limit-policy). We always monitor the performance of our systems to guarantee best availability to all customers, but still you might have to deal with ‘noisy neighbours’.

In the future this may be further mitigated by further technical measures to guarantee Quality of Service, especially in the higher-priced tiers, or certain performance packages for individual organizations.

Still, further constraints might include location of your data, infrastructure provider requirements, flexibility in updates and backups, or concerns over performance. That’s where our dedicated instances come into play.

A dedicated instance is a complete ZITADEL system in which you can decide everything yourself. You decide where this system is operated, on which domain it runs, when it should be updated, and which default settings should be stored.

## When do I need more Organizations?

If you have a B2C case you will probably be fine with only one organization. In this organization you will maintain all your projects and applications as well as all your users. In this case you can decide which tier suits best for your project and upgrade on your organization.

But what if you have a B2B case?  
In a B2B case our recommendation is to create an organization for yourself and your project and some for each of your customers. To decide which tier suits your own organization just follow the questions above.

Now each of your customers can decide if they are fine with the default settings (free tier) or if they need some customization. If they need some customization they can decide by themselves which tier suits them. If your customer already has its own organization you can just grant your project to the existing one, that’s managed by your customer.

Having an organization for each of your customers enables you to delegate the authorization management to them. You can find a simple example of a customer portal with delegated authorization on our [GitHub repository](https://github.com/zitadel/zitadel-nextjs-b2b).

The following chart should provide you some visual help on how to structure your organizations, depending on your use case.

<img
  src="/blog/2021-11-24-why-should-I-upgrade-my-zitadel-01.png"
  width="100%"
  alt="Flowchart explaining how you can structure your ZITADEL organizations"
/>


Most of the common Identity and Access Management solutions have a pricing model based on the amount of users. In our opinion this model leads to shortcuts in security.

Why should I upgrade my ZITADEL?


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


## Description

We were busy since our last Into the CAOS and want to share some updates around ZITADEL and what is planned in the near future.

We will also talk about new features such as Metadata, Actions, new policies as well as what did not go so well.

<br />
<div className="my-4">
  <YouTubeExtended
    videoId={"RZJkNX7s7Zk"}
    containerClassName={"youtube-container"}
    stopsTitle="Topics covered"
    stopList={[
      { name: "Highlights from the past weeks", time: "1:50" },
      { name: "Metadata", time: "5:20" },
      { name: "Handling External Identity Providers", time: "7:06" },
      { name: "Actions", time: "9:00" },
      { name: "Lockout policy", time: "17:00" },
      { name: "Query Side", time: "21:06" },
      { name: "Question to Lockout policy", time: "25:21" },
      { name: "Native Backup", time: "28:19" },
      { name: "OpenAPI/Swagger", time: "30:10" },
      { name: "Issues and learnings", time: "33:29" },
      { name: "New languages", time: "39:38" },
      {
        name: "How to use ZITADEL for Product vs. Organizations",
        time: "42:36",
      },
      { name: "Roadmap", time: "54:31" },
      { name: "Penetration test", time: "58:40" },
    ]}
  ></YouTubeExtended>
</div>

## References

- [Swisscom Cybersecurity Startup Challenge](https://www.swisscom.ch/en/magazine/start-up/startup-challenge-security/)
- [DINAcon Awards](https://awards.dinacon.ch/gewinner2021/)
- [API Documentation](https://zitadel.com/docs/apis/introduction/)
- [Internationalization Documentation](https://zitadel.com/docs/guides/manage/customize/texts#internationalization)
- [Smartive - Built with ZITADEL](https://zitadel.com/blog/success-story-smartive-bin)
- [Pentest results](https://zitadel.com/blog/pentest-results-h1-2021)

## Discuss features

- [Discussion: Metadata on Orgs](https://github.com/zitadel/zitadel/discussions/2454)
- [Discussion: Project settings](https://github.com/zitadel/zitadel/discussions/2263)


We were busy since our last Into the CAOS and want to share some updates around ZITADEL and what is planned in the near future.

Into the CAOS | No 2.


During the first half of 2021 an external specialist conducted a security analysis of ZITADEL. We want to show you the results, what we already did and what we’re planning to do in the future.

## TL;DR

The overall result was rated as good with only one high issue, which we already mitigated partially. Other issues were minor but nonetheless important for us and were fixed within a few days. Others still need more thinking from our side to find a solution that not only solves the immediate risk, but also gives the users a real benefit. Until then a lot of the findings can be mitigated from the users themself by using either Passwordless (WebAuthN) or at least by protecting their accounts with a second factor (2FA).

## Findings

In the following section I will give you a short summary and comment on the highest ranked issues. The number indicates the external assessment according to the Common Vulnerability Scoring System (CVSS).
[You can find the full report here.](/blog/2021-11-11-pentest-results-h1-2021-01.pdf)

### 8.1 Data not Encrypted at Rest (CVSS 8.2 / High)

> “The ZITADEL Console web application does not encrypt data at rest. An attacker with access to the database, can access the stored secret and personal identification information data.”

Although ZITADEL does not encrypt its database, the storage (hard disks) is encrypted. Furthermore, ZITADEL either hashes (bcrypt) or encrypts (AES) certain events for example passwords, OTP Secrets, private keys or temporary codes.

### 8.2 Failed Login Attempts Not Displayed (6.5 / Medium)

> “The ZITADEL Console web application does not display failed login attempts after a successful authentication. An attacker may profit of this missing control, since a user will not know, that he was subject to an attack.”

We certainly lack a corresponding display and we’re planning to have such in the near future. For the moment a user is able to see these and all other events that have occurred on his user on the “Personal Information” page in the “Activity” section:

<img src="/blog/2021-11-11-pentest-results-h1-2021-02.png" width="60%" alt="" />

To mitigate the risk of an attacker attempting to log into your account, we highly recommend using Passwordless (WebAuthN) or at least protect your account with a second factor (2FA) for example Universal Second Factor (U2F) or One Time Password (OTP). ZITADEL allows managers to enforce the use of multi factor or passwordless authentication.

### 8.3, 8.4, 8.6 Missing Protections for Username / Password Authentication

I would like to take a look at the three points together, because the focus is on protecting authentication using usernames and passwords. To say it in advance, these can be mitigated considerably by using WebAuthN or at least a 2FA mechanism:

- 8.3 Missing Protection Against Online Guessing (6.5 / Medium):
  > “The ZITADEL Console web application does not protect user accounts with an application layer mitigation mechanism against automated brute-force attacks. An attacker with access to the login page can perform an online brute-force attack to guess a user’s password.”
- 8.4 Consider Restriction of Common or Compromised Passwords (6.5 / Medium):
  > “The ZITADEL Console web application does not offer the option for IAM Administrators to restrict the usage of common and compromised passwords. An attacker can be successful using a wordlist based brute force attack to takeover user accounts.”
- 8.6 Username Enumeration Possible (4.3 / Medium):
  > “The ZITADEL Console web application login allows enumeration of usernames, due to a warning that is showed after entering a non-existing username. An attacker with access to the login page can perform an online brute-force attack to enumerate existing usernames.”

To mitigate against brute-force attacks at least on a network layer, we use an IP-based rate limiting for our cloud service and dedicated instances. While we also provide a possibility to create a lockout policy, we do not recommend using it, as it also enables attackers to Denial-of-Service a user. Therefore a reasonable solution would be to use Captchas and prompt users to solve it when a user fails to enter a correct password multiple times.

When using a weak password an attacker's chance to take over an account is even higher. Giving organisation administrators the possibility to restrict certain passwords or make users aware that the password they use, might be weak or compromised will be an enhancement we plan to implement in the future.

We’ve discussed a lot whether we should show a warning that the entered username does exist or not. But the fact that a user can authenticate using external identity providers (e.g. Google) somewhat made it obsolete, because when the user enters their username, we might have to redirect them to their identity provider, which will disclose the fact that the user exists. Moreover, a malicious user who already has access to ZITADEL might gain access to this information anyway (e.g. through the client application).

### 8.5 IAM Policies Not Enforced (5.3 / Medium)

> “The ZITADEL Console web application fails to disable user registration and password
> authentication on the server-side. An attacker who knows the technical details, on how to
> register a user, can register a user without access to any projects or organization
> information.“

A registration of a user, which would not have been allowed is certainly a problem and we fixed it. However, there are possible measures and facts that mitigate this issue. First of all a successful registration only allows a user to authenticate, which he might already be able to do so in another organisation, but no authorization to any project is granted by default. So if applications do their supposed authorization checks, they will not have a problem. As the user will not get any manager role within ZITADEL, he will as well not gain access to any information of other users of his organization.

### 8.7 Verbose Error Messages (4.3 / Medium)

> “The ZITADEL Console web application shows verbose error messages in the HTTP Header Grpc-Message. This information can be helpful for an attacker to mount further attack steps.”

Due to the fact that ZITADEL is OpenSource, a lot of this information can be obtained anyway. But we definitely see room for improvement here, especially from a usability aspect and we will continuously improve this.

### 8.8 Consider Usage of Refresh Token (3.3 / Low)

During the security analysis, refresh tokens could not be tested because we were still implementing them. We released this feature the following week (see [v1.8.0](https://github.com/zitadel/zitadel/releases/tag/v1.8.0))

### 8.9 Logout Does Not Terminate Session (3.3 / Low)

Although this was only rated as low (3.3), we wanted to solve this issue quickly. We also found a bug where we would terminate the session and delete it from the database table. But when we did a query, we would make sure to apply newer events to the found session (using the event sequence of the found session). At first glance this totally makes sense, because the projection might be a little behind and a new session might not even be in the database, yet. The problem was that exactly this piece of code did not handle the logout event. This was an [easy but important fix](https://github.com/zitadel/zitadel/releases/tag/v1.10.5) we provided a couple of days after the security test. It also demonstrated to us that we need more automated tests on the query side of our APIs.

## What we are planning to do

We have a fast forward strategy and while we’re releasing a lot of new features frequently , we need to keep code and application security in mind. Therefore, we want to challenge our security from the outside more often and plan to do such security audits at least every six months. Moreover we have a [basic responsible disclosure policy](https://github.com/zitadel/zitadel/blob/main/SECURITY.md) that we want to expand further over the near future, most likely coupled with an official bug bounty program.

Furthermore we will have to use the potential we gain through our CQRS / Eventsourcing architecture and generate use case based reports, e.g. present a user not only failed login attempts but also other relevant events that have taken place since the last successful login, such as gaining or losing access to a project and so on.

And last but not least, we are going to push passwordless authentication (WebAuthN) further as this solves a lot of problems regarding compromised or weak passwords.


During the first half of 2021 an external specialist conducted a security analysis of ZITADEL.  We want to show you the results, what we already did and what we’re planning to do in the future.

Pentest Results H1 / 2021


<a href="https://smartive.ch/" target="_blank" rel="noreferrer">
  <img
    src="/blog/2021-10-25-success-story-smartive-bin-01.svg"
    width="100%"
    alt="Logo of smartive AG"
  />
</a>

[smartive](https://smartive.ch/) replaced the existing backend of the bin mobile app for the [bin cooperative’s eLearning platform](https://www.bin.ch/de/leistungen/elearning.html). The app makes teaching materials and books digitally available to apprentices and simplifies teaching thanks to sophisticated tools like highlighting and drawing. They integrated ZITADEL for authentication and authorization to rely on established standards, which saved them at least two weeks of initial development time and even more in maintenance.

## Key outcomes

- Migrated five thousand users to ZITADEL
- Full integration within eight hours
- Predictable pricing independent of user count

## Challenge

smartive had to replace an existing backend, because it was outdated and didn’t rely on standards. The goal was to implement the same functionality as before. Using state of the art technologies and to rely on standards wherever possible was the main focus. Using an external IAM solution was the right choice to minimize development impact. The migration process must be as smooth as possible, because most students already used the first version of the app.

## Solution

In ZITADEL the bin app has one organization that contains projects for the development and productive environment. All the users are managed by the bin organization which means that they have a @bin.ch account for their login. Since these users already existed in the previous system they had to be migrated to ZITADEL.
The books a student is allowed to use are controlled by roles defined on the project and assigned to the user.

Implementing the migration process that imported all users into ZITADEL was an easy task, as the ZITADEL API was straightforward to use. Because ZITADEL follows the API first approach, all the data from the existing system could be migrated with a migration script that was executed once for each environment.

<img
  src="/blog/2021-10-25-success-story-smartive-bin-04.png"
  width="100%"
  alt="Login screen of ZITADEL with bin logo and red colors"
/>

## Result

Right in time for the new semester, smartive was able to deliver the new app. With the integration of an existing IAM instead of a custom implementation they saved several weeks in development time and even more in maintenance. The predictable pricing, independent of user count, and the fast feedback from ZITADEL support contributed to the success of the project.

## Future Plans

smartive is currently working on an extension, such that the bin app becomes a platform for multiple publishers. With multi-tenancy out of the box, ZITADEL is still the perfect match for their future endeavors.

## Testimonials

<img
  src="/blog/2021-10-25-success-story-smartive-bin-02.png"
  width="30%"
  alt="Portrait of Christoph Bühler in a red shirt on blue background."
/>
“I appreciate the proximity to the ZITADEL team, they react quickly and provide competent
support.” Christoph Bühler, Software Engineer

## About the solution

The bin-app is part of the eLearning offering provided by bin-Genossenschaft (Bildungsnetz Schweizer Schreiner). More information and further links to the solution can be found at https://www.bin.ch/de/leistungen/elearning.html

## About smartive

smartive AG  
Pfingstweidstrasse 60  
8005 Zürich  
https://smartive.ch/

- Industry: Software Development, Agency
- Team Size: 22
- Clients: Bin, Migros, Schweizerische Eidgenossenschaft, Frontify
- German-speaking Switzerland

[Download this story.](/blog/2021-10-25-success-story-smartive-bin-03.pdf)


smartive replaced the existing backend of the bin mobile app for the bin cooperative’s eLearning platform with ZITADEL.

How smartive implemented a mobile app with ZITADEL for thousands of students

Our talk at Siemens Open Source event on May 25, 2021

Open Source @ Siemens


## Description

The team behind ZITADEL shares what we developed over the summer, what issues we encountered on the way, and what is planned in the near feature.

<br />
<div className="my-4">
  <YouTubeExtended
    videoId={"b95LK2oiIiw"}
    containerClassName={"youtube-container"}
    stopsTitle="Topics covered"
    stopList={[
      { name: "Team", time: "5:25" },
      { name: "Privatelabeling", time: "8:00" },
      { name: "Passwordless", time: "12:03" },
      { name: "Query Optimization", time: "17:00" },
      { name: "Postmap rings 😂", time: "20:50" },
      { name: "OIDC RP Certification", time: "21:33" },
      { name: "Sentry", time: "26:10" },
      { name: "New Nextjs template / example", time: "32:05" },
      { name: "Quick Demo Privatelabeling in Console", time: "33:12" },
      { name: "Issues and how we solved them", time: "37:05" },
      {
        name: "Upcoming: Extending external identity providers",
        time: "56:05",
      },
      { name: "Next up: What’s coming to ZITADEL", time: "1:01:28" },
    ]}
  ></YouTubeExtended>
</div>

## References

- [Software Architecture / Query Models / CQRS](https://zitadel.com/docs/concepts/architecture/software)
- [Certification OIDC RP Library in Go](https://github.com/zitadel/oidc)
- [Examples / Templates](https://zitadel.com/docs/sdk-examples/introduction)


The team behind ZITADEL shares what we developed over the summer, what issues we encountered on the way, and what is planned in the near feature.

Into the CAOS | No 1.


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

## Description

In this short interview with Gregory Blaser we introduce our consulting partner Blaser Meewes & Partner, in short bmparter. Bmpartner is a boutique-consultancy in Switzerland, with focus on in IT strategy and delivery management. They specialize in large and complex IT projects, IT strategy consulting, and digitalization of sales departments and client facing business units.

Gregory Blaser provides more detail about bmpartner, why identity & access management is relevant for their clients, and how the partnership with CAOS strenghtens the value for clients. He highlights three important points at the end of the inverview for customers that want to tackle their identity & access management challenges: Don't underestimate the challenge and address it early on, break with old patterns whenever possible, and build internal know-how during the process.

## Topics covered

- Introduction (00:00)
- About bmpartner (00:15)
- The ideal client (01:22)
- Relevance of identity & access management (02:17)
- Partnership with CAOS (04:54)
- Important points in IAM projects (06:32)

## bmpartner

[bmpartner](https://www.bmpartner.ch/) is our consulting partner. We work together to deliver complex and large scale IT strategy and implementation projects. CAOS provides additional expertise in the field of identity and access management. [Gregory Blaser](https://www.bmpartner.ch/team/gregory-blaser.html) is managing partner of bmpartner.


We introduce our consulting partner Blaser Meewes & Partner

Blog.