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 the 21st century, a significant share of our conversations is held virtually, via text messages. Not only does this fact apply to interpersonal conversations between acquaintances or friends, but also service-related negotiations such as parcel deliveries, newsletter subscriptions, or even payment requests. Due to the normalization of these sorts of messages, people tend to be less hesitant when clicking on links that come from a seemingly trusted sender. A serious problem arises, however, when the attached URL redirects you to a malicious site. In this article, I will discuss the phenomenon of smishing and how to protect yourself from falling victim to it.

## What is smishing?

The word “smishing” is derived from a combination of “SMS” and “phishing”. “Phishing” describes the phenomenon of being deceived into giving sensitive information to a disguised cybercriminal and “SMS” indicates that the deception is carried out via text messaging. Smishing is therefore essentially a newer breed of the infamous spam emails, however, due to the perceived intimacy of a personal text message, SMS scams have a higher chance of going unnoticed.

To further take advantage of your confidence in text message safety, attackers tend to assume the identity of well-known companies people are used to receiving legitimate messages from, such as DHL, Netflix, or Apple. Smishing text messages usually depict a situation that due to their urgency, are known to grab the victim’s attention, such as a package delivery notification, a purchase confirmation, or a credit card suspension notice. The ultimate “goal” of smishing is to trick unsuspecting people into giving away their personal or financial information. In many cases, simply clicking the provided link can initiate a download process of viruses or malware, which the cybercriminal can use to access all data and information stored on your phone.

![](/blog/2022-05-11-smishing-01.png)

## The most common threats of smishing texts

Based on what we already know about this phenomenon, smishing is more than a simple prank-SMS. What some people do not realize, however, is how severe the risk of clicking a simple URL can be. Most commonly, the attacker will exploit the acquired data for one or more of the following purposes:

### 1. Stolen money

The most obvious reason a criminal would want to access your online information is to defraud you out of money: The attached link is therefore often used to intercept a one-time passcode (OTP) most banks use for step-up authentication. Alternatively, they might simply send their unsuspecting victims a warning about an unpaid bill in favor of a fake recipient. Sadly, many attackers found success in this “business”: [The median of the loss reported by complainants was $800.](https://www.aarp.org/money/scams-fraud/info-2020/smishing.html)

### 2. Identity Theft

Theft does not exclusively happen to tangible objects; it can also happen to a person’s entire identity. Some scammers use the accessed data to claim the identity of their victim, for various diverging causes apart from stealing money, such as filing phony health insurance claims, committing tax fraud, or even reselling your data to other criminals.

### 3. Installed Viruses

Another threat smishing poses is the installment of unsolicited malware. The message might encourage you to download a seemingly trusted app, which could be used to collect sensitive data from your phone, such as credit card details stored in other apps. Additionally, a phone infected with malware or viruses can become completely unusable.

### Pegasus: A real life smishing example

To showcase just how dangerous the consequences of smishing can be, we are taking a look at the real-life example of the “pegasus incident”. Pegasus is a spyware that can be installed on any kind of smartphone device, intending to harvest its data from apps. While the software was intended to be used to investigate potential terrorists and criminals, multiple cases of its misuse to surveil anti-regime activists, journalists, and political leaders have been reported.

As software capable of zero-click exploit, Pegasus requires no user interaction to operate: As an example, the spyware could be covertly installed on the phone of a [technology lead at Polygon](https://citizenlab.ca/2022/04/catalangate-extensive-mercenary-spyware-operation-against-catalans-using-pegasus-candiru/), by taking advantage of a previously unknown security vulnerability in Apple’s iMessage. The Pegasus infection link was disguised as a boarding pass link for a Swiss International Air Lines flight the victim had purchased. As a result of a simple click on the URL, the spyware was granted unlimited access to every information stored on the iPhone.

![](/blog/2022-05-11-smishing-02.png)

While this incident of a fraudulent boarding pass link would likely fly under the radar for many, luckily, more **amateurish smishing attempts targeted at civilians are easier to identify**. In the next chapter, we discuss some common signs of a potential smishing attempt.

## Signs that you are getting “Smished”

To protect yourself from smishing, it is essential to be able to recognize the threat coming your way. Luckily, there are some signs to look out for, when receiving a suspicious text message. If the text is guilty of at least one of these common signs of smishing, that is a warning signal that you need to take measures to protect yourself:

- The message is asking you to click on an URL with a domain that does not correspond to the company name. Furthermore, shortened URLs (f.e. starting with bit.ly, cutt.ly, and shorturl.at) are generally not trustworthy in the context of SMS messaging.
- The message is very generic – Legitimate senders generally include the package number, your bank’s name, or your name/nickname, depending on the context.
- The message contains spelling- or grammatical errors - Texts from service providers are usually automated, so the possibility of a typo would be extremely low.
- The number of the sender and that of the service provider they claim to be, do not match. Moreover, when you receive a message from bigger service providers, (f.e. banks, post offices, or delivery services) they will mostly have their company names displayed instead of their numbers.

![](/blog/2022-05-11-smishing-03.png)

## How can you protect yourself?

Whether you already received an illegitimate message or not, smishing can happen to everyone. However, there are plenty of measures you can take to protect your data; if you have received a suspicious message, keep these simple tips in mind to avoid falling prey to text message fraud:

- Do not open the attached link
- Replying or calling them is counterproductive – Doing so confirms that your number is in use, making you a potential target for more attacks
- Never share any of your data (passwords, address, etc.) via text
- Limit sharing your phone number on social media to decrease the number of potential scammers getting their hands on it
- Block the number and/or report the scammer to your country’s Trade or Communications Commission or the police
- When in doubt, ask the service to confirm the delivery of the message in question. However, make sure to do so via the contact information you can find on their official website; do not call the number that sent the message.
- Enable [Multifactor Authentication](/features#multifactor) to prevent unwanted logins to your account.


What if a text message you received is not what it seems?  This article discusses the phenomenon of smishing and how to protect yourself from falling victim to it.

Smishing - How to Recognize Dangerous Text Messages


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


<a
  href="https://money-key.ch/"
  target="_blank"
  rel="noreferrer"
  className="hidden dark:block"
>
  <img
    src="2022-04-27-success-story-money-key-02.svg"
    width="80%"
    alt="Logo of money key"
  />
</a>
<a
  href="https://money-key.ch/"
  target="_blank"
  rel="noreferrer"
  className="dark:hidden"
>
  <img
    src="2022-04-27-success-story-money-key-01.svg"
    width="80%"
    alt="Logo of money key"
  />
</a>

[Money Key](https://money-key.ch/) is a digital web and voice application that allows entrepreneurs and financial managers easy access to their financial information. Due to the interconnected nature of the business relationships, Money Key uses ZITADEL as the identity platform to provide authentication, self-service and delegation of authorizations to their B2B customers.

## Key outcomes

- Small invest in identity management by using core B2B features
- Using Organizations for each customer to enable SSO and self-service
- SaaS service with data location Switzerland

## Challenge

Money Key is a digital web and voice application that connects to your accounting system. Fiduciaries and companies log into their web solution to review financial information via interactive reports and voice chat. The hierarchical relationship between trustees and their customers poses some challenges with regards to multi-tenancy and self-service.

The proof of concept used a social login provider to authenticate users with the application. As the maturity of the product evolved, it became clear that there needed to be a better solution, not only for authentication, but mainly also for authorizing the different B2B customers. A decisive criteria was a provider from Switzerland and ideally hosting of the SaaS in Switzerland.

## Solution

![Screenshot of Money Key application showing liquidity KPIs of a demo account](/blog/2022-04-27-success-story-money-key-04.png)

When looking for alternative solutions, the option to build an own solution was out of the question. The investment would have been too high and taken away valuable time in creating core business value.

ZITADEL was introduced to Money Key by their initial implementation partner, [Paixon](https://paixon.ch/), who has been using the identity platform for other solutions already. It seemed like the ideal solution for the B2B use case in addition to being a hosted cloud offering from Switzerland.

Money Key likes the fact that ZITADEL is organized around the concept of Organization, which can delegate access management to other Organizations and the flexibility of how ZITADEL Organizations can be used.

The solution required delegation of access roles through a hierarchy of Organizations where a product owner can administer the primary customer group, that is the trustees, who can self-manage their own company customers.
The application’s business logic creates new Organizations and internal users for new customers programmatically by connecting to the ZITADEL Management-API.  
The big advantage is that each entity has the possibility to act as its own administrator and set/edit the different users on different levels. Hence Money Key keeps its focus on offering new features and on the other hand its clients get the flexibility to manage the users on their side.

Money Key relies on the ZITADEL state-of-the-art security and benefits from features like two-factor authentication and password reset, which is easy to use as a consumer as well as administrator. It is possible for customers to use a social login (e.g. Google), as originally intended, which is related to ZITADEL identity management via Account Linking.  
At the moment they are missing the option to use their own domain for login and in emails to customers. This feature will be released to the Public Cloud service in May 2022.

## Result

Money Key was able to get a first working version of their B2B service within six months, with first customers using the application since the end of 2020. Following the success of the initial feedback, development continues with ZITADEL as the identity platform.

During the early phase it is quite important that the costs are only a small part of the overall product revenues. The availability guarantees and the pricing was convincing and Money Key is happy to have the option to buy additional support after initially scaling their growth.

## Future Plans

With a strong IT team at their disposal, Money Key is working towards integrating with various accounting software providers, such as Sage (Infoniqa), Bexio or Abacus, but also growing strategic partnerships to make life as data-driven entrepreneur easier. The goal for 2022 is to expand in the german-speaking part of Switzerland, soon followed by the german-speaking countries around.

## Testimonials

<img
  src="/blog/2022-04-27-success-story-money-key-03.jpg"
  width="30%"
  alt="Portrait of Ernest Ukaj"
/>

> “We needed a better solution for authorizing customers. We did not want to build this on our own, but focus on our core competencies.” - Ernest Ukaj, Founder and CEO

## About the solution

Money Key is a digital web and voice application that connects to your accounting system. The financial manager tool is a fiduciary and financial assistant in one and provides quick and understandable insight into your company's finances through intuitive usability.

## About Money Key GmbH

Money Key GmbH  
Industriestrasse 28  
CH-9100 Herisau  
[money-key.ch](https://money-key.ch/)

Money Key GmbH is currently part of the MYK Group, that offers fiduciary, audit and tax consulting services, with a special focus on SMEs and start-ups. Right now they are finalizing agreements with further Business-Angels/Investors. Currently Money Key has 5 employees and productizes their solution not only in Switzerland but also internationally.


Money Key is a digital web and voice application that allows entrepreneurs and financial managers easy access to their financial information. Money Key uses ZITADEL as their B2B identity platform.

Money Key built a financial manager tool for fiduciaries and entrepreneurs with ZITADEL


At ZITADEL every customer is granted **their own virtual instance with unlimited identities**, that allows them to **fully configure their instance policies**. This includes choosing a deployment option which is most suitable for the unique needs, security requirements, budget, and resources of each individual organization.

In this article, we will discuss our Software as a Service (SaaS) deployment option, alongside our self-hosted alternative to help you find the right solution for your project or business.

_We are currently working on version 2 of ZITADEL, as described in our [last Blog “A Serverless Future”](https://zitadel.com/blog/a-serverless-future). With this new version of our cloud service, customers will get their own virtual instance of ZITADEL. In the meantime we are more than welcome to provide you with a dedicated installation manually. Get in touch with us._

## Software as Service (SaaS) – For the need for convenience

Our public cloud option is ideal for any user who is intrigued by the idea of a **hosted** deployment model that is **ready-to-use** the moment you obtain it: Unlike the self-hosted alternative, SaaS is **pre-configured and automated**, thus sparing you the time and money spent on implementing, managing, and maintaining your platform. Accordingly, a virtual instance will **automatically upgrade** with new product improvements, and security fixes without your intervention.

You also do not have to worry about expanding your infrastructure when your service gains new customers or sees usage spikes. Thanks to the SaaS model of ZITADEL **both scaling and resource allocation are being handled by us**. Another notable benefit lies in the possibility of **global or regional deployment**: An infrastructure built to manage traffic from a global audience or constrain data to only a certain location, depending on your needs. Both scenarios are possible through our SaaS service, while we optimize and guarantee **low latencies and high availability**.

With the cloud service you benefit from the **operational security** aspects, such as DDoS and DNS protection. ZITADEL itself is an **open source platform** and the same open source releases are deployed to our cloud service. With that you are able to analyze and validate the code of our application. We even go beyond that and publish the results of our [penetration tests](https://zitadel.com/blog/pentest-results-h1-2021) done by external auditors, as soon as we have mitigated any issues.

Despite it excelling in terms of security and convenience, the pay-as-you-go subscription method of SaaS allows for a **relatively low total cost of ownership**.

There are certain weaknesses relying on a SaaS deployment, which are easily outweighed by the convenience of a pay-as-you-go subscription for most customers. While most customers are satisfied with our infrastructure in terms of cloud provider and data location options, some want to **choose their own infrastructure providers or data location**. In this case self-hosting is a good option or a **dedicated instance of ZITADEL**, which is operated by us with respect to the custom terms and conditions of the client. Both options are also viable in case a customer requires **more flexibility of upgrade cycles or backup frequencies**.

A newly arose weak point in today's software is supply chain risk, where our **OpenSaaS model provides extraordinary transparency** of code, dependencies, and processes, yet a customer still relies on the quality of our technical and organizational measures to manage information security. We are continuously improving our information security and working towards a ISO27001 certification by the end of this year. In case you **want to have more control over the technical and organizational measures**, you should choose to **self-host ZITADEL** and get technical support through us.

Lastly, a further weak point in the SaaS deployment method lies in its **limited customization options**. While companies mostly offer a wide variety of templates to choose from, their number can&apos;t compete with the infinite customization possibilities that come with building your own platform. We do not recommend building your own identity management system, rather we **promote the platform approach** of ZITADEL, where customers can easily extend functionality of the platform by **loosely coupling new components**. This is supported by ZITADEL&apos;s API-first approach, SDK&apos;s in various languages, and **programmatic extensibility** through ZITADEL Actions.

**The summed-up benefits of SaaS include:**

- Receive a pre-configured and implemented platform – no need to bother with updates, backups, maintenance, and troubleshooting
- Operational security provided
- Availability guarantees and automatic scaling
- “Pay as you go” model with low total cost of ownership (TCO)
- Global and region specific deployment options
- Technical support - we are here to help

## Self-hosted – For the need for full control

As the name suggests, unlike the SaaS solutions which are operated by a third-party provider, self-hosted deployment is **hosted by you** on your infrastructure. In the case of ZITADEL, companies or individuals can deploy our software on their preferred cloud provider or install it as an on-premise solution; Both of these options allow them to take **full control over all aspects of their software**, instead of having to rely on our infrastructure and our technical and organizational processes. ZITADEL is based on **cloud-native principles** and is designed to be deployed as containers, which makes it straightforward to run and operate on almost any platform.

Self-hosting is an excellent choice if you have the resources to set up and **host your own instances** of ZITADEL on **custom infrastructure** with your company's needs in mind. If implemented correctly, the features of a self-hosted platform even have the **potential to surpass the security possibilities of SaaS**, making it an ideal alternative for firms working with sensitive data. However, since the **responsibility of adequately hosting the platform lies solely in the hands of the company**, a lot more effort and risk-taking is required for the implementation and operation of the platform. To lift some of this weight off your shoulders, **ZITADEL offers self-hosters commercial technical support with an SLA**.

Since the setup cost and maintenance are the most obvious downsides of self-hosting, we recommend choosing this solution if your company **already possesses internal resources to handle the hosting** **and is ready to pay the investment and upkeep**. Should your firm struggle with some technical aspects of self-hosting, our community or our team, respectively, is happy to aid regarding any of these issues.

With this said, we strongly discourage self-hosting your identity platform without in-depth IT-knowledge; since the security measures must be manually installed and maintained, **mistakes in the implementation can potentially lead to inadequate protection from intruders**.

**The summed-up benefits of self-hosting include:**

- Manage your platform with full control in your own cloud or hardware
- Be in control of your technical and organizational measures
- Fully customizable platform
- Self-hosters can get commercial technical support with an SLA
- Highest possible security, if implemented accordingly

## Which option to choose?

In conclusion, while both deployment options have their respective advantages, the **self-hosted alternative will most likely only benefit companies that aim to fulfill some very specific requirements**. Should your organization lack an internal staff with in-depth IT knowledge, the serious dangers of faulty implementation are most likely not worth risking. Accordingly, **the advantages of SaaS outweigh those of self-hosted options for most organizations** and are therefore generally the recommended path to take. Should you be on the fence regarding your choice, we created **this chart as a guide**:

<div className="dark:hidden">
  ![](/blog/2022-04-13-saas-vs-self-hosted-01-light.png)
</div>
<div className="hidden dark:block">
  ![](/blog/2022-04-13-saas-vs-self-hosted-01-dark.png)
</div>

## The Takeaway

Whether SaaS or self-hosting is the better choice for your organization, ZITADEL ensures **the best possible deployment experience** with its flexible pricing options, generous range of features, guaranteed high security and unlimited identities for all options.

Should you have questions regarding SaaS, self-hosting 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&apos;t forget to [give us a star over on GitHub](https://github.com/zitadel/zitadel/stargazers). Thanks for the support.


We discuss our Software as a Service (SaaS) deployment option alongside our self-hosted alternative to help you find the right implementation for your business.

SaaS vs Self-hosted – How to Choose the Right Deployment Option


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


## Description

The ZITADEL team gives an overview of what happend over the last months and what our roadmap for 2022. This is a highlight video from a [livestream](https://youtu.be/IyJrAf9JOJc) on February 24, 2022.

We will talk about Actions, Personal Access Tokens, E2E Testing, SAML2.0, and of course our rehaul of our cloud offering "V2" - and many more topics.

<br />
<div className="my-4">
  <YouTubeExtended
    videoId={"3Cu_on1GzGY"}
    containerClassName={"youtube-container"}
    stopsTitle="Topics covered"
    stopList={[
      { name: "General Updates", time: "0:15" },
      { name: "Personal Access Tokens (and Demo)", time: "1:15" },
      { name: "ZITADEL Actions (and Demo)", time: "3:24" },
      { name: "Query Side / Event sourcing", time: "4:26" },
      { name: "Issues: User Register Flow", time: "5:20" },
      { name: "Issues: Global Organization", time: "7:10" },
      { name: "End-to-End testing", time: "8:24" },
      { name: "Roadmap: V2 of ZITADEL", time: "9:40" },
      { name: "Roadmap: Developing ZITADEL / Community", time: "13:49" },
      { name: "Roadmap: UI overhaul of Console", time: "14:38" },
      { name: "Roadmap: SAML2.0", time: "16:39" },
      { name: "Roadmap: Reporting", time: "17:41" },
      { name: "Roadmap: Login providers", time: "18:09" },
    ]}
  ></YouTubeExtended>
</div>

## References

- Watch the [full recording](https://youtu.be/IyJrAf9JOJc) of the livestream
- Explore our [roadmap](https://zitadel.com/roadmap)
- More about our plans for 2022 in our Blog ["6 New ways ZITADEL IAM will improve in the year 2022"](/blog/six-ways-zitadel-will-improve-2022)
- Read about ["New Personal Access Tokens (PAT): A game changer for Service Users"](/blog/new-personal-access-token)
- Our blog about ["SAML vs OIDC: Which Protocol is Best for Your Organization?"](/blog/saml-vs-oidc)
- Find a link to the new [Rust SDK](https://zitadel.com/docs/sdk-examples/introduction#libraries)
- Track the progress of the initial release of [ZITADEL CLI](https://github.com/zitadel/zitadel/issues/3182)


Meet the team behind ZITADEL. We share what we have done over the last months and our plans for 2022. Highlights from our livestream on Feb 24, 2022.

Into the zitadel/zitadel | No 3.


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.

Blog.