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


## Key Outcomes

- **Leveraging Real-World Tools for Practical Learning:** The CAS Frontend Engineering Advanced course run by smartive uses ZITADEL, an open-source Identity and Access Management platform, providing students with hands-on experience in working with industry-grade tools. This exposure gives students practical understanding and skills applicable to their professional careers, making their learning experience highly relevant and impactful.

- **Simplified Authentication and Security:** ZITADEL's straightforward setup and comprehensive free tier made it an ideal choice for managing the authentication and security of the API used in the course. This ease of use allowed students to focus more on learning advanced web development topics and less on configuring security tools, enhancing the overall efficacy of the course.

- **Effective Management of User Access:** With ZITADEL, smartive was able to manage and control user access to the course's shared API effectively. Despite accessing a shared resource, ZITADEL's configuration allowed each student to have a personalized experience. Students were expected to create their own ZITADEL account to access the API and set up authentication for their individual front-end applications.


## Introduction

[smartive](https://smartive.ch/), a leading IT services company, conducts the [Certificate of Advanced Studies (CAS) Frontend Engineering Advanced Course](https://www.ost.ch/de/weiterbildung/weiterbildungsangebot/informatik/software-engineering-testing/cas-frontend-engineering-advanced?li_fat_id=aca37124-dfc7-4d1e-ae8e-dbc432c034d1&cHash=1fffb9398099735c3d77acb6bd4a8005) at the [Eastern Switzerland University of Applied Sciences (OST)](https://www.ost.ch/). The collaboration emerged from a longstanding relationship between smartive and OST, as several smartive team members are alumni of the university and have previously been invited to deliver guest lectures. The opportunity for smartive to take a lead role in the course materialized when OST invited them to design and conduct an entire course. 

### About The Eastern Switzerland University of Applied Sciences (OST)

[The Eastern Switzerland University of Applied Sciences](https://www.ost.ch/), also known as OST, is an institution steeped in history, having brought together 170 years of tradition in education and research. Founded by the six cantons of St.Gallen, Schwyz, Glarus, Appenzell Ausserrhoden, Appenzell Innerrhoden, Thurgau, and the Principality of Liechtenstein, OST has positioned itself as an essential educational hub for Eastern Switzerland and Liechtenstein.

OST is a public institution, independent in its functioning, characterized by its own legal personality and the right to self-administration. At its heart, OST is a cooperative venture, sustained by the shared vision and commitment of the various founding regions.

In terms of its impact and reach, OST is a significant player in the region's educational landscape. The university hosts around 3,800 students across six departments, furthers the professional competencies of approximately 1,500 individuals via executive education, and advances the field of academic research with more than 1,000 ongoing research projects.


### About smartive

[smartive](https://smartive.ch/) is an IT services company based in German-speaking Switzerland, renowned for its bespoke digital products and comprehensive IT solutions. With a diverse portfolio ranging from startups to the largest employers in Switzerland, including notable clients like Bin, Migros, Schweizerische Eidgenossenschaft, and Frontify, smartive stands as a hallmark of IT innovation and digital transformation.

The company's services span from the conceptualization of an idea to its realization into a live digital entity. Specializing in web apps, APIs, and DevOps, smartive has been setting up brand new products, analyzing existing solutions, and providing ongoing support and development for projects since 2012.


### About the Course

The [Certificate of Advanced Studies (CAS) Frontend Engineering Advanced Course](https://www.ost.ch/de/weiterbildung/weiterbildungsangebot/informatik/software-engineering-testing/cas-frontend-engineering-advanced?li_fat_id=aca37124-dfc7-4d1e-ae8e-dbc432c034d1&cHash=1fffb9398099735c3d77acb6bd4a8005) offered at the OST University is designed for individuals with experience in frontend engineering aiming to progress to a "Senior Frontend Engineer" position. Admission requires a minimum of two years of professional experience in a development team and a recognized tertiary degree. The course spans nine months.

The structure of the course involves the completion of three sub-projects, where students have the opportunity to build a 'Twitter Clone'. This provides practical experience and allows students to demonstrate their ability to independently set goals and develop their projects.

The course delves into Design Systems, offering students an understanding of the fundamentals, how it evolves from Bootstrap, recent developments in CSS, and updates on JavaScript frameworks. Students also gain insights into the areas of Architecture and Cloud DevOps, which include frontend engineering with Next.js, mastering TypeScript/React Hooks, understanding various APIs, managing data and state, and optimizing performance with Progressive Web Applications (PWAs).

A significant component of the course is Cloud DevOps, where students explore frontend security, OpenID Connect (OIDC), Continuous Integration/Continuous Deployment (CI/CD), and concepts of Cloud Native Applications and serverless computing.


### About the Students

The course attracts students with a background in computer science or web development. The students' experience levels vary, but most of them possess substantial professional experience in their respective fields. Some students come to the course seeking to update their skills, having used older practices for web development and are keen to learn how to apply modern methodologies.

Professionally, many of these students are already working as front-end engineers. Their experience with programming languages and frameworks is diverse. Some students come with a strong foundation in languages like Java or PHP, while others already have experience with more modern frameworks like Angular or React. 


## Problem

One of the fundamental aspects of this course is the use of an Identity and Access Management system—a component that is central to a major assignment requiring the development of a NextJS application. The course focuses on teaching students about API access, front-end security, state management, and design tokens among other advanced topics.

Throughout the course, students create a real-world project in a one-to-one context with all the topics covered. An identity and access management provider that supports OpenID Connect (OIDC) must be utilized in the login and security segment, where students learn how OIDC works and how it is implemented in the provider.


## Solution

### Why smartive picked ZITADEL

smartive chose to incorporate ZITADEL into the course for a multitude of reasons:

Being a free-to-use system, ZITADEL eased potential budget constraints for the course. Compared to its competitors, ZITADEL eliminated the need to negotiate educational agreements or struggle with complex onboarding processes. The fact that smartive had prior experience with ZITADEL was also a contributing factor, as they were familiar with how to navigate and utilize ZITADEL effectively.

Everything the students needed was available right out of the box on the free tier, making it more than sufficient for the course's nine-month duration. This served as an ideal way to showcase OIDC, login, and security operations in a practical setting.

Compared to in-house solutions, ZITADEL presented a clear advantage with its open-source nature. Universities often rely on sophisticated enterprise authentication schemes like Shibboleth, but integrating such a system into the course could have resulted in a considerable amount of work. 


### How ZITADEL is Used in the Course

ZITADEL is used to facilitate a practical assignment that tasked students with building a web application, specifically a Twitter-like platform named "Mumble." This hands-on approach required ZITADEL primarily for its security features and OIDC part of the course.

In this context, the students' application needed to interact with an API created by smartive, simulating a real-world software development environment. The API underpinned the entirety of Mumble's functionality, managing tasks like creating posts (or 'mumbles'), deleting and liking posts, and following other users. It also facilitated real-time updates of activities on the platform via server-sent events. This approach exemplified an API-first methodology, mirroring ZITADEL's own implementation.

To access and interact with this API, students had to create a ZITADEL account. This process simulated an authentic software development experience, where front-end applications must interact with authenticated APIs securely. Since the API can be hosted as a separate project, students can create their own project for their Mumble application, only needing to specify the API project's resource ID as the audience from their client side. This will allow them to manage their front-ends and redirect URIs independently.

<figure>
  <img
    src="/blog/2023-07-27-success-story-smartive-ost-01.png"
    width="100%"
    alt="smartive OST Diagram 1"
  />
  <figcaption>
    Figure 1: Use of ZITADEL for User Management and Authentication
  </figcaption>
</figure>

Each cohort of students, typically comprising 20 to 25 individuals, is granted access to a ZITADEL instance for the duration of the course. Despite the small class size, ZITADEL is used intensively, generating significant traffic. This hands-on experience with ZITADEL forms a critical part of the learning process, enabling students to familiarize themselves with real-world security solutions.

## Learning Curve 

The foremost challenge faced by the students was learning how to create a front-end application, specifically, grasping how to implement certain features, such as setting up Proof Key for Code Exchange (PKCE) and redirecting URLs.

However, it is important to note that the learning curve associated with these challenges was somewhat anticipated, given that most students did not have prior experience with comparable technologies. 

## Future Plans

smartive has clear future plans for the CAS Frontend Engineering Advanced course, aiming primarily to enhance the course content and teaching methodologies. One central focus is the topic of login and security, a crucial aspect of any advanced web development course. This focus won't change, as it forms a core part of the real-world project-based learning approach that the course employs.

The emphasis on OIDC and web application security is expected to persist, as these aspects remain critical in the evolving landscape of web development. The year 2023 and beyond will likely see these topics retaining, if not growing, their importance.

## Testimonials

<img
  src="/blog/2023-07-27-success-story-smartive-ost-02.jpg"
  width="400px"
  alt="Portrait of Christoph Bühler"
/>

“ZITADEL is the right choice to show students how OIDC works. It adheres to the spec and has a generous free tier such that the students can fiddle around with the system.” - [Christoph Bühler](https://www.linkedin.com/in/christoph-b%C3%BChler-a3a262270/), Software Engineer at [smartive](https://smartive.ch/) and Course Lecturer at [OST](https://www.ost.ch/)

## Further Reading

Explore the [documentation](https://zitadel.com/docs/guides/solution-scenarios/frontend-calling-backend-API) on accessing secure back-end APIs via a front-end application after users log in. The guide presents a solution scenario that demonstrates how a front-end application can call a secure back-end API. It explains the steps to implement this workflow, detailing how to manage user access and effectively handle tokens.


Smartive and OST have enhanced the user experience in their Advanced Frontend Engineering Course by utilizing ZITADEL.

ZITADEL in the Classroom: A Look at smartive's and OST's Advanced Frontend Engineering Course


Have you ever made a reckless decision in a hectic situation that you later regretted? We know you did. And sadly, so do cybercriminals.

There are countless bad decisions made online every day. Whether they are made accidentally or due to being misguided, just a single wrong click can lead to devastating consequences. **MFA Fatigue Attacks aim to take advantage of this irrational decision-making** to deceive users into **bypassing or circumventing [Multi-Factor-Authentication (MFA)](https://zitadel.com/features#multifactor)**, thus jeopardizing the security of their accounts.

This article discusses MFA Fatigue Attacks targeting MFA systems with push notifications and how we can mitigate them.

![MFA Fatigue Attacks Illustration](/blog/2023-07-07-mfa-fatigue-attacks-01.png 'MFA Fatigue Attacks Illustration')

## MFA with Push Notifications

Since **Push Notifications are commonly used as a second factor** in two-factor authentication (2FA) or multi-factor authentication (MFA) systems, you have likely already encountered this verification method. Like other Multi-Factor Authentication methods, it adds an **additional layer of security to user accounts** by mandating an extra verification factor in addition to the traditional username and password login approach. The popularity of Push Notification reliant MFA can generally be accredited to its **relatively robust security and convenient user experience**.

Verifying your identity with this authentication method is very simple: When attempting to log in to a service or application that has this type of MFA enabled, **you receive a push notification on your registered device** (such as a mobile device or tablet) instead of a code. This notification **contains information about the authentication request**, including the device and location. Upon reviewing these details in the authenticator app, **you can allow or decline the login attempt**, which helps you block malicious actors from accessing your data.

While **Multi-Factor Authentication with push notifications** is significantly safer than single-factor password-based login, it is **not impervious to all cyberattacks**. One of the most common techniques threat actors use to bypass this MFA method is an **"MFA Fatigue Attack"**.

## What are MFA Fatigue Attacks?

MFA fatigue attacks, also known as MFA exhaustion, 2FA fatigue, MFA push spam, or prompt bombing refer to **a type of [2FA bypass attack](https://zitadel.com/blog/2fa-bypass-attacks) that exploits** the usability challenges associated with **Multi-Factor Authentication using push notifications**. However, instead of relying on brute force or deception techniques, 2FA fatigue attacks **take advantage of the flaws in human decision-making**.

If the attacker has **already acquired someone's login credentials**, they can **initiate a login attempt**, automatically sending a push notification to the victim's registered device. Should the victim **deny the authentication request** (as usual), the attacker simply repeats the process. The attack aims to **continue sending these login requests to the user's device** until they eventually **give in out of frustration or by accident**. Accordingly, **increasing the frequency** at which the user is sent MFA requests can significantly **enhance the attack's success rate**.

### The Psychology Behind MFA Fatigue Attacks

Upon learning about the concept of MFA Fatigue Attacks and their relatively high success rate, a commonly asked question might arise: **Why do some victims eventually accept the authentication request** if it was clearly triggered by a malicious actor?

There are some people who even **[unthinkingly accept the first MFA push notification they receive](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/defend-your-users-from-mfa-fatigue-attacks/ba-p/2365677)**, possibly as a force of habit. Surely, some might also **press the wrong button by accident** or perhaps think that **a bug causes the spamming of the notification**. The behavior of the third category of victims, who seemingly deliberately accept the approval request after it keeps on invading their devices, is rooted in a **psychological phenomenon called decision fatigue**.

If a machine were asked the same question repeatedly, it would always provide the same response since that is what it was pre-programmed to do. However, **unlike machines, humans do not always operate rationally** - especially in overwhelming situations.

When users are unwillingly prompted to decline the same MFA push notification over and over again, their **sensible decision-making abilities often suffer due to their growing botheration with the repetitiveness**. This phenomenon of decision fatigue **increases users' likelihood of taking shortcuts** or ignoring security protocols: For example, instead of declining the MFA prompt yet again, **the user would begrudgingly select "Allow" to finally make it disappear**. Obviously, doing so would only solve a minor inconvenience while simultaneously making way for an infinitely bigger problem: **having their personal information compromised**.

## How to Mitigate MFA Fatigue Attacks

### Change your Password

Whether or not an attack has previously been attempted on your account, **consider creating a strong password** to reduce the likelihood of it being guessed or cracked. Ideally, this password should include **at least one uppercase letter, one number, one symbol, and a total of 9 characters**.

While an MFA Fatigue Attack may be mitigated if the attacker does not know your login credentials, having to remember **a long and complicated password significantly decreases the user experience**.

### Switch to Another MFA Method

Another way to avoid falling victim to MFA fatigue attacks is to **enable a different MFA login method** on your account instead. We recommend **switching to a [FIDO U2F authentication technique](/blog/authentication-methods)** whenever your platform allows it.

U2F leverages **public-key cryptography**, which makes it **far safer and less vulnerable to 2FA bypass attacks** than other MFA methods (such as One-Time Passwords (OTP)). This FIDO protocol uses **security devices known as U2F tokens as the second factor**. These tokens can be embodied in various form factors, such as a **USB device (f.e. Yubikey), a Near Field Communication (NFC) device, or a BlueTooth LE device**.

This option, akin to changing to a safer password, may temporarily solve the problem of MFA fatigue attacks. However, these MFA systems **still rely on passwords** as their primary authentication factors, which are **highly subjectable to various attack vectors**. Thus, as long as passwords are part of your login process, **your account remains subject to various 2FA bypass attacks**.

Fortunately, the constant evolution of security standards led to the development of **safer authentication protocols that do not incorporate passwords** into their systems.

### Go Passwordless with Passkeys

The **ultimate solution** to eradicating MFA fatigue attacks is to **switch to a passwordless authentication method**. By eliminating passwords from their authentication process, passwordless systems are **far less susceptible to cyberattacks**, such as [phishing](https://zitadel.com/blog/social-engineering#:~:text=1.%20Phishing%20and,card%20suspension%20notice.), [social engineering attacks](https://zitadel.com/blog/social-engineering), and brute-force attacks.

**Passwordless protocols, such as [FIDO2 (aka FIDO 2.0) passkeys](https://zitadel.com/blog/authentication-methods#:~:text=1.%20FIDO2%20Passkeys,devices%2C%20wearables%2C%20etc)**, depend entirely on exchanging public-private keys between a user's device and the server that authenticates the user, thus ensuring **highly secure access to all virtual identities**. The risk of MFA is significantly mimized, since **the FIDO request needs active initialisation on the device that raises the prompt**. Therefore, **another person can not initiate the verification of the second factor** for the user since their device does not hold the passkeys. Furthermore, passwordless systems enable a **smoother authentication experience** due to their waiver of the knowledge factor.

![Secure Authentication with Passkeys](/blog/2023-07-07-mfa-fatigue-attacks-02.png 'Secure Authentication with Passkeys')

## Secure Authentication with ZITADEL

Successful 2FA bypass attempts, such as MFA fatigue attacks, can have devastating consequences. However, choosing a **robust and secure authentication method** can significantly reduce the chance of falling victim to a cyberattack.

With **ZITADEL as your company's Identity and Access Management (IAM) solution**, your end-users have a plethora of **[highly secure authentication methods](https://zitadel.com/blog/authentication-methods)** to choose from. Furthermore, due to the platform **not supporting MFA with push notifications**, the chance of an MFA fatigue Attack is off the table.

To ensure that your end-users can verify their virtual identities in the safest and most convenient way possible, we **highly recommend that they either set up a FIDO U2F token or a FIDO2 Passkey** as their preferred authentication method.


This article discusses MFA Fatigue Attacks targeting MFA systems with push notifications and how we can mitigate them.

How MFA Fatigue Attacks Compromise User Security


## Introduction

The current technological landscape has sparked a substantial shift in security strategies, steering us away from traditional perimeter-based models and towards a zero-trust approach. The embrace of multi-cloud infrastructures and remote work has further catalyzed this transition. An essential part of the shift to zero trust that often goes undiscussed is the move from coarse-grained to fine-grained security.

**[ZITADEL](https://zitadel.com/)**, a global and scalable identity and access management platform, provides robust default capabilities for managing access control through Role-Based Access Control (RBAC) and Delegated Access, laying a solid foundation for efficient and scalable access management. Yet, as we journey towards a zero-trust mindset, the limitations of coarse-grained security become increasingly apparent. The traditional RBAC system may grant an editor the rights to modify all documents, but interconnected and dynamic work environments require more fine-grained control. What if we want to grant editors access to edit documents related only to a specific project, within a certain time frame, or access only to a specific document? This is where fine-grained authorization steps in.

Fine-grained authorization enables access decisions based on various attributes such as user roles, specific attributes, actions they are trying to perform, and even contextual factors such as the time or location of access. Such nuanced access control is critical in modern applications.

In this article, we will delve into how ZITADEL responds to the growing demand for fine-grained authorization patterns. By leveraging ZITADEL's roles, meta-data, and actions, you can achieve a level of granularity and precision in access control that meets the demands of a zero-trust environment. Furthermore, ZITADEL can also integrate with external authorization services. Let’s explore!

## The Need for Fine-Grained Authorization and its Potential Benefits

<figure>
  <img src="/blog/2023-06-15-fine-grained-authorization-02.jpeg" width="100%" alt="fine-grained-auth" />
</figure>

Fine-grained authorization goes beyond traditional access control models by allowing access decisions to be based on more specific and varied factors. For instance, access might be granted based on the user's specific attributes, the resource they're trying to access, their location, the time of day, or any combination of these and more.

The key benefits of implementing fine-grained authorization are enhanced security, greater flexibility, regulatory compliance, and improved auditability. Thus, adopting a fine-grained authorization strategy can offer both enhanced security and operational advantages.

### Decoding Fine-Grained Authorization Techniques

Implementing fine-grained authorization isn't a one-size-fits-all proposition, and each organization may require a unique approach based on its specific use cases, existing infrastructure, and security requirements. Nonetheless, several common techniques and methodologies serve as the foundation of most fine-grained authorization strategies. Here, we'll decode some of these essential techniques.

- **Policy-Based Access Control (PBAC)**: A powerful tool in the fine-grained authorization arsenal is PBAC. This approach uses specific policies, typically written in declarative language, to decide whether a user or system should have access to a particular resource. Policies can factor in an extensive range of conditions, providing a granular level of control.

- ** Attribute-Based Access Control (ABAC)**: This technique expands upon the traditional role-based access control (RBAC) method. In ABAC, permissions are assigned based on user attributes, such as department or job title. This model provides more flexibility, as access decisions can be made based on a variety of user attributes and environmental conditions.

- **Relationship-Based Access Control (ReBAC)**: ReBAC is a recent evolution in access control models. It introduces the concept of relationships between subjects (users or groups) and objects (resources), allowing for even more specific access controls. This model can provide a powerful tool for multi-tenant applications, where resources need to be shared based on complex relationships.

- **Risk-based Access or Conditional Access**: Some applications may need to alter their behavior based on where a user is logged in from, what region the application is running in, or the day/time an operation is invoked. This is often due to regional differences in service levels or compliance requirements.

- **Fine-Grained Security Logging and Events**: The evolution towards fine-grained security also applies to security logging. Instead of merely recording logins, it's now crucial to log every access decision an application makes during a user's session. This helps identify and rectify over-provisioned or misconfigured permissions more effectively.

## ZITADEL’s Current Authorization Mechanisms

ZITADEL is a cloud-native Identity and Access Management solution (IAM) that provides various security mechanisms to secure applications and services. It employs a range of different authorization strategies, including Role-Based Access Control (RBAC) and Delegated Access.

### Role-Based Access Control (RBAC) and Delegated Access

ZITADEL employs RBAC as a primary mechanism for assigning and managing user permissions. In RBAC, permissions are associated with roles, and users are assigned to these roles. For example, you have the option to enforce access to resources by defining roles in the form of functional user roles (e.g., admin, editor, reader) or related to an application feature (e.g., book:read, book:edit). This approach provides a simple way to manage user access based on their roles within an organization.

The delegated access feature further extends this capability by allowing roles to be delegated to other organizations. This means you can provide an external organization with certain permissions within your system. This is particularly useful for organizations that work closely together or have a hierarchical structure.

These features provide a strong base for controlling access in various contexts. However, they may not be sufficient or can get too complicated for more complex authorization requirements that require a finer level of control, which leads us to the topic of implementing fine-grained authorization in ZITADEL.

## Extending ZITADEL's Existing Capabilities for Fine-Grained Access Control

Despite the comprehensive features that come with ZITADEL, there may be instances where a more customized or fine-grained approach is needed. Currently, the most effective way to implement fine-grained authorization in ZITADEL is by using custom application logic for smaller projects, or for larger scale projects, leveraging an available third-party tool such as [warrant.dev](https://warrant.dev/), [cerbos.dev](https://cerbos.dev/), etc. These tools can integrate with ZITADEL, further enhancing your capacity for nuanced, fine-grained authorization.

### Leverage the Actions Feature, Custom Metadata, and Claims for ABAC

ZITADEL goes beyond the static nature of RBAC with its dynamic [**Actions**](https://zitadel.com/docs/apis/actions/introduction) feature, designed to facilitate the implementation of attribute-based access control (ABAC). In contrast to RBAC, which assigns access rights based on a user's role, ABAC is a more flexible method that evaluates a set of attributes associated with the user, action, and resource for each access request.

In ZITADEL, the Actions feature can be used to create a post-authentication script that checks for specific user attributes and denies access if necessary. You can also use Actions to create custom claims that can further enhance your ABAC system. This powerful feature opens up the possibility for advanced authorization models, such as denying access to a resource based on the user's location, time of access, or any attribute that you can define and evaluate.

ZITADEL allows administrators or authorized developers to set custom metadata on users and organizations, further enhancing your ability to create fine-grained access control. Even aggregated claims are possible, where you request additional information from a third-party system and return the claims in the user information. This could be information from a CRM system, a training or certification tool, an HR system, or any other relevant source. Moreover, ZITADEL can handle application-specific resources such as shipping orders, IoT devices, and documents, and manage the policies defining access to these resources based on certain attributes. These attributes include User-Sub, Roles, Claims, IP, Tenant/Organization, and others.

## A Use Case

<figure>
  <img src="/blog/2023-06-15-fine-grained-authorization-01.jpeg" width="100%" alt="The roles in a media company" />
</figure>

In the fast-paced world of digital media, ensuring the right access to the right resources for the right employees is crucial. For a media company employing a host of journalists and editors, each with differing levels of experience and responsibility, the challenge lies in effectively managing access rights across various applications.

Let's consider such a media house. Here, the primary roles are journalists, who write articles, and editors, who review, edit, and publish these articles. The employees are further categorized based on their experience levels: junior, intermediate, and senior.

Let’s assume the media house has two primary applications in use. The first is a Newsroom Application, where journalists write their articles, and editors review, edit, and publish them. The second application is an HR Application. This handles all employee-related data and tracks their progress within the organization, including promotions and experience level changes. For example, when a journalist gets promoted from junior to intermediate, this change is recorded in the HR application. Access to certain features in the Newsroom Application needs to be strictly controlled. Junior journalists should only write articles, intermediate and senior journalists should be able to review articles, and only editors, particularly those with higher experience levels, should have the rights to edit and publish articles.

To manage these varied and complex access requirements, the media house utilizes ZITADEL, which they use for their general identity and access management needs. The goal here is to use ZITADEL's capabilities to ensure that access rights are correctly attributed according to both an employee's role and the seniority level, providing a clear separation of responsibilities within the media house.

Let's see how we can create a Flask API that upholds these access controls and how to configure ZITADEL to handle these authorization needs.

### The Application

Let’s assume that the main operational application within the media company is the Newsroom Application, a Flask-based API. The Flask API acts as the primary interface where journalists write articles and editors review, edit, and publish these articles. The API has been designed with specific endpoints that correspond to these permissions, enforcing role and experience-based access control.

Here are the primary endpoints that map to the permissions:

- **write_article**: This resource endpoint is exclusively for **journalists** to write articles. **All journalists**, regardless of their experience level, have access to this resource.
- **edit_article**: This resource endpoint is specifically for **editors**. It enables them to edit the articles written by the journalists.
- **review_articles**: This resource endpoint provides access to review articles, which is a responsibility given to **senior journalists**, and both **intermediate and senior editors**.
- **publish_article**: This resource endpoint is for publishing articles, a task designated to **intermediate and senior journalists**, and **senior editors**.

Each of these endpoints is accessible based on a combination of role and experience level, ensuring the right people have the right access.

Under the hood, the Flask API uses JWT (JSON Web Tokens) for authentication and authorization. When a user makes a request, they must provide a valid JWT as part of the request's Authorization header. This token is then decoded to verify its validity and to extract any custom claims.

[Custom claims](https://zitadel.com/blog/custom-claims) are key to this use case. They contain additional information about the user, in this case, the user's role and experience level. When a request is made to the API, these claims are extracted from the JWT and used to determine if the user has the necessary permissions to access the requested resource.

### Configure ZITADEL and Create the API

- Let’s first set up ZITADEL for this use case as explained in the [Set up ZITADEL](https://github.com/zitadel/example-fine-grained-authorization#1) section.
- Next, set up the API as explained in the [Set up the API Project](https://github.com/zitadel/example-fine-grained-authorization#2) section.
- Finally, test the API as explained in the [Run and Test the API](https://github.com/zitadel/example-fine-grained-authorization#3) section.

You can find all source files and instructions [here](https://github.com/zitadel/example-fine-grained-authorization).

### The Application Logic

<figure>
  <img src="/blog/2023-06-15-fine-grained-authorization-03.png" width="100%" alt="Application Flow" />
  <figcaption>
    Figure 1: Interactions showcasing the application of fine-grained authorization in a real-world Newsroom Application
  </figcaption>
</figure>

**User Role Assignment at Onboarding**: As part of the user onboarding process, each user is assigned a role. The role could be that of a `journalist` or `editor`. This role assignment is crucial as it is the basis for access control in our system.

**Experience Level Management by HR app**: Beyond the user role, the system also considers the user's experience level. The experience level (`junior`, `intermediate`, `senior`) is determined and managed by an HR application. When a change occurs in a user's experience level, it is updated as metadata in ZITADEL. It's worth noting that the system assumes a 'junior' level by default when no experience level is specified in the token claims.

**Token Validation**: [auth.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/auth.py) is responsible for token validation. When a request hits the API, [auth.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/auth.py) validates the token by calling ZITADEL's token introspection endpoint. If the token is valid and active, it is then decoded and printed for inspection. The decoded token (containing the user's role and experience level) is then made available globally using the Flask g object.

Note: Although JWTs can be validated locally using JWKS, we chose to use ZITADEL's token introspection endpoint for enhanced security and real-time token validity. This approach enables immediate revocation, simplifies implementation by centralizing control, and reduces the risk of security vulnerabilities. This helps ensure our API's authentication and authorization processes remain robust, accurate, and in sync with the current server state.

**Fine-Grained Access Control**: The Python Flask application is responsible for authorizing access to resources based on a user's role and experience level. It leverages a predefined access control list that maps each resource endpoint to the user roles and experience levels authorized to access them. This list serves as the rulebook for granting or denying access to resources. Each time a user attempts to access a resource, the function `authorize_access` checks if the user's role and experience level meet the access requirements for the requested endpoint. If they do, access is granted; if not, the function returns a message stating that access is denied, with details of the user's role and experience level and the resource they attempted to access.

**Business Logic**: [app.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/app.py) is the main Flask application file. It defines the resource endpoints and applies the token_required decorator (from [auth.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/auth.py)) to secure them. Each time a request is made to these secured endpoints, the token_required decorator first verifies the token. Then, the authorize_access function (from [access_control.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/access_control.py)) is called to check if the user is authorized to access the endpoint based on their role and experience level.
**Separation of Concerns**: In the design of this API, special attention was given to ensuring that business logic and access control rules are cleanly separated. This is crucial for the maintainability and scalability of the application.

The business logic is independent of who is allowed to access these endpoints, thus it is concerned only with performing actions rather than checking who can trigger these actions. [access_control.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/access_control.py) is strictly focused on implementing fine-grained access control rules. It does not concern itself with the specifics of how requests are processed, but only with who has the permission to make these requests. These rules are based on roles and experience levels stored in JWT token claims. The authorize_access function in [access_control.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/access_control.py) is used in the business logic layer ([app.py](https://github.com/zitadel/example-fine-grained-authorization/blob/main/app.py) ) to guard the endpoints.

The separation of business logic and access control rules allows for a clean, modular design where changes to business processes and access rules can be made independently of each other. This increases the maintainability of the code and makes it easier to manage as the application scales. Additionally, this design makes the system more secure as access rules are abstracted away from the main business logic, reducing the risk of accidentally introducing security vulnerabilities when modifying the business logic.

## Integrate with an External Authorization Service

ZITADEL allows integration with external authorization services such as [warrant.dev](https://warrant.dev/), [cerbos.dev](https://cerbos.dev/), or essentially any service that can consume ZITADEL's users and roles.
By using an external authorization service, you have the flexibility to create a fine-tuned authorization strategy that precisely meets your organization's needs. This could involve creating complex policies that dictate access based on a variety of user attributes and conditions, extending far beyond the traditional roles used in RBAC.

Instead of enforcing a one-size-fits-all solution, ZITADEL believes in giving users the tools and options to construct an access control framework that perfectly suits their organization's unique needs and challenges. This emphasis on flexibility ensures that as those needs evolve, the access control strategy can adapt seamlessly.


This articles showcases fine-grained authorization with ZITADEL and delves into managing access control, validating tokens, and separating business logic from authorization rules.

ZITADEL and Fine-Grained Authorization: A Code-Focused Exploration


When you attempt to access a system, network, or resource, it is critical that **the administration of the platform verifies your identity** to prevent unauthorized access to your personal data. This procedure is called **authentication**. 

The **piece of evidence** users need to provide to complete the authentication process may come in **various forms and quantities**: Be it a password, a fingerprint, a combination of the two, or something completely different. However, though there is a wide selection of common authentication methods, **not all are equally beneficial for end-users' safety**. 

With **[ZITADEL](https://zitadel.com/)** as your Identity and Access Management (IAM) solution, your end-users have the option to **enable any of our available authentication methods**: FIDO Universal 2nd Factor (U2F), FIDO2 Passkeys, Mobile Transaction Authentication Numbers (mTAN), Mobile One-Time-Passwords (OTP) and Password-based authentication. To help you weigh each method's pros and cons, this article **describes each process in greater detail**. 

Here are **ZITADEL's five implementable authentication methods** ranked from worst to best regarding **security and user experience (UX)**. 

![ZITADEL's Authentication Methods Overview](/blog/2023-06-01-authentication-methods-03.PNG "ZITADEL's Authentication Methods")

## Authentication Methods - Worst to Best

### 5. Passwords

Unsurprisingly, the title of the **lowest-ranking entry** on our list has to go to the most infamous form of authentication in the book: **passwords**. 

Since their inception in the 1960s, passwords have been a **standardized practice in validating our digital identities**. Their invention has not only brought the **concept of authentication** to light but also that of **cybersecurity** itself. 

However revolutionary passwords might have been for cybersecurity, the **rapid evolution of technical knowledge** amongst the public also opened the door for more and more cybercriminals who **take advantage of the simplicity of this authentication method**. As a response to these new cyberattacks, the notion of **password hygiene** has emerged: More and more platforms started urging their users to make their passwords **more complex and to change them periodically**. 

As of the 2020s, any password that does not include **at least one uppercase letter, one number, one symbol, and a total of 9 characters** can be [cracked within a maximum of three days](https://www.statista.com/chart/26298/time-it-would-take-a-computer-to-crack-a-password/). While setting up a long and convoluted password might solve the guessability issue, it simultaneously **defeats their original purpose of being easily recallable**. Moreover, even the most complex passwords are vulnerable to other cyberattacks, such as **brute-force attacks and [social engineering](https://zitadel.com/blog/social-engineering)**. 

Fortunately, the traditional username-password login approach is **no longer your sole option to protect your virtual identities**. There is a great variety of newer authentication methods to choose from that **significantly outperform passwords both in terms of User Experience and level of security**. 

### 4. One-Time-Passwords (OTP) mTAN

**One-time passwords (OTPs)** (also known as One-time codes) are a type of authentication in which **a unique password is generated for each login attempt** and, as the name suggests, can only be used once. Since OTPs are **commonly used as a second factor in two-factor authentication (2FA) or [multi-factor authentication (MFA)](https://zitadel.com/features#multifactor) systems**, most of us have likely already encountered this method of authentication in practice. 

**Mobile Transaction Authentication Number (mTAN)** is an off-device method of generating one-time passwords (OTPs) **specifically created for financial transactions**. It is commonly employed by banks as an **additional layer of protection** to verify the identity of the person attempting to initiate a payment. 

At the start of the transaction process, a **TAN (a single-use code of 6-8 characters)** is generated and sent to the user's mobile phone **via SMS or a dedicated banking app**. This TAN must then be **supplied on the transaction page** to validate the payment attempt. Thus, even if a cybercriminal gets their hands on your password, they still **won't be able to conduct payments on your behalf** without this additional verification code. 

While mTAN offers **robust protection against identity theft and fraudulent transactions**, it still ranks low on our list due to its **vulnerability against various forms of [2FA bypass attacks](https://zitadel.com/blog/2fa-bypass-attacks)** (such as [SIM-Jacking](https://zitadel.com/blog/2fa-bypass-attacks#:~:text=6.%20SIM-Jacking,of%20the%20hacker) and social engineering), as well as its inconvenient user experience. To migate some of the security concerns around mTAN, **ZITADEL chose not to support SMS-reliant OTPs** - instead, with the **upcoming login API**, your login flow can be extended easily with external 2FA providers that offer SMS TAN.

### 3. One-Time-Passwords (OTP) Mobile 

**Mobile OTPs** operate very similarly to the previously mentioned mTAN authentication method. Like TAN codes, Mobile OTPs are **single-use, off-device numerals typically used as an additional authentication factor** to ensure a safer login process. The main differences are that this method is not explicitly intended for financial transactions and that the **OTP is sent to the user via an authentication application of the user's choice (f.e. Authy or Google Authenticator)**. 

Take signing into a social media account as an example. With Mobile OTP enabled on your profile, you will be **prompted to navigate to your authentication app after you enter your login credentials**. The app will display a **6-digit code (the OTP)** which must be entered on the social media login page as part of the **secondary authentication process**. Akin to the case of mTAN, the requirement of an additional OTP **safeguards your profile from unwanted access**, even if your password might have been compromised. Moreover, the code refreshes after a short amount of time (30-60s), making the old one automatically useless after its expiration. 

Despite their many similarities, **mobile OTP typically suprasses mTAN in terms of safety**, because the code is generated on the user’s device and **does not rely on a SIM card**. Accordingly, a potential SIM-jacking attack will still not get the attacker closer to accessing the user’s account. Despite this perk, mobile OTP is **still subjectable to the [Duplicate-Generator attack](https://zitadel.com/blog/2fa-bypass-attacks#:~:text=5.%20Duplicate-Generator,time-password%20(OTP).), as well as social engineering attacks (f.e. [phishing](https://zitadel.com/blog/social-engineering#:~:text=1.%20Phishing%20and,card%20suspension%20notice.))**. 

### 2. FIDO Universal 2nd Factor (U2F)

**FIDO (Fast Identity Online)** describes a **set of open protocols based on public key cryptography**. It was developed by the **FIDO Alliance**, consisting of technology giants such as Google, Visa and Microsoft, to create **convenient but highly-secure standards for authentication**. As a groundbreaking domain- and hardware-bound open solution, FIDO has established itself as a **widely used and highly recommended identity and access management (IAM) practice**. Since its founding in 2012, the FIDO Alliance has published three specifications: **Universal 2nd Factor (U2F), Universal Authentication Framework (UAF), and [FIDO2](https://fidoalliance.org/fido2/)**. 

The **U2F protocol** was designed to be used as a **second-factor token-based authentication system** in addition to the first factor (the user's password) to enhance the security of the traditional password-based login method. Accordingly, U2F prompts users to present **two pieces of evidence to validate their identity**:

* **A knowledge factor**: The user's password or PIN
* **A possession factor**: Security devices known as U2F tokens that can be embodied in various form factors, such as a USB device (f.e. Yubikey), a Near Field Communication (NFC) device, or a BlueTooth LE device.

With U2F's extra layer of security added to the authentication process, the service can **simplify its passwords without compromising security**. Furthermore, its reliance on **public key cryptography and physical security keys** makes it far safer and **less vulnerable to 2FA bypass attempts** than the previously stated OTP-based approaches. 

Evidently, even the earlier installations of FIDO (such as U2F) can already be considered **highly innovative and secure** (especially compared to traditional login methods). However, the constant evolution of security standards inevitably led to the need for a newer protocol that **carries on the benefits of its predecessors while also bringing new advancements (such as higher UX)**. This is where FIDO2 comes into play.

### 1. FIDO2 Passkeys

**FIDO2 (aka FIDO 2.0)** is the latest set of specifications published by FIDO, with the primary pursuit of **entirely eradicating password use on the internet**. Ever since its release, FIDO2 has been widely supported by technological giants such as Google, Microsoft and Apple. Unlike previous specifications, this new protocol comprises the **W3C Web Authentication (WebAuthn)** specification and corresponding **Client-to-Authenticator Protocols (CTAP)** from the FIDO Alliance. This innovative collaboration provides users with **[passwordless](https://zitadel.com/blog/passwordless), second-factor and multi-factor user experiences** with **embedded** (such as biometric authentication or PINs) or **external authenticators** (such as physical security keys, mobile devices, wearables, etc.). 

The release of FIDO2 also marked the introduction of **Passkeys - passwordless credentials that allow users to access their FIDO sign-in information across multiple devices**, including new ones, without needing to enroll each device separately for every account. The WebAuthn API of FIDO2 enables the **standardization of passkeys**, which also provides **libraries for their use in both the front- and back-end**. 

As the highest-rated entry on our list, **FIDO2 Passkeys surpass every other authentication technique available on ZITADEL** both in terms of security and UX. To sum up why, here are some of **the key reasons why users should enable FIDO2 Passkeys as their preferred authentication method:**

* Passwordless systems are **less susceptible to phishing and other cyberattacks** due to their complete waiver of passwords.
* Login via Passkeys is **less time-consuming and does not rely on the user's memory**. 
* WebAuthn provides FIDO2 with a **standardized framework that improves compatibility** and ensures **consistent security practices across different platforms**.
* Passkeys ensure a **fast and convenient recovery process** by allowing users to enroll and de-enroll devices via **their service provider's cloud backup**.
* Passkeys enable users to **authenticate seamlessly across different vendor platforms**, ensuring a **convenient UX and cost-effectiveness**.

## In Conclusion

The main goal of the **Identity and Access Management (IAM) solution ZITADEL** is to ensure that the end-users of your application can **verify their virtual identities in the safest and most convenient way possible**. To make this goal a reality, we highly recommend that **they either set up a FIDO U2F token or a FIDO2 Passkey as their preferred authentication method**. 


This article showcases ZITADEL's five implementable authentication methods ranked from worst to best regarding security and user experience (UX).

5 Authentication Methods at ZITADEL - Ranked from Least to Most Secure


We had our inaugural team retreat in May 2023. And looking back, the experience was nothing short of remarkable! For the first time, we gathered the entire team of 13 people in one location. This gathering went beyond work-related matters; it was about the team culture, getting to know each other, and building a great team.

As we transition towards being a remote-first company, we’re placing heightened emphasis on these aspects, striving to create an environment where everyone feels valued, included, and inspired to succeed.

## Our Workplace Evolution

Four years ago, our company began an exciting journey with a unique workplace story. In the early days, we didn't have a set office. Instead, we met in different coffee shops in St. Gallen. It was a fun start, but not a long-term solution. Our friend Ole, who owns Brüw pub in St. Gallen, helped us out. Since his pub was only open in the evening, we made a deal and started working there during the day. This gave us a stable place to work without having to look for a new spot every day.

In January 2020 we decided to rent our first office. But unfortunately, three months later the pandemic hit and we had to work from home. We never really finished setting up our office. When we could go back, only a few of us did. So, by the end of the year, we decided to give up our office and become a fully remote company. This move has also made us more inclusive and flexible, as we hired our first team member from outside the country.

## Embracing Company Culture in a Remote-first World

With the transition to become a fully remote company, we also started to place greater focus on our company culture. In the past, socializing and bonding after work came naturally when we shared office space or lived close to one another. However, with colleagues spread across different countries, we recognized the need to foster connections deliberately.

To combat this geographical separation, we host monthly online team events and commit to in-person gatherings twice a year. We appreciate the value in cultivating personal relationships that extend beyond digital interactions. . Our goal is to create a company where everyone feels not only welcome and motivated but also empowered to voice their ideas.

## Gathering the Team

The goal for our first team retreat was simple: get the team together and have fun. As we started planning, we decided to mix fun activities, team hangouts, and a workshop on company culture. This basic plan helped us start looking for the right place to stay.

### Finding the Right Spot

None of us had planned something like this before, so we chose to stay within Switzerland, where we were familiar with how things work, yet away from our usual workspace. This brought us to Habkern, a beautiful village near Interlaken. The place we rented was nice, though it didn’t check all our boxes completely. While technically accessible via public transport, it wasn’t very convenient. However, since we came by car, this wasn’t a big issue.

We thought cooking most of our meals would be a fun bonding experience (we all know the best parties happen in the kitchen ;) ), but we also wanted one dinner out for a carefree evening. With only eight meals in total, this worked out perfectly. We enjoyed a range of foods, from BBQ to fondue and wraps.

Finding the right location can be tough, and you might want to consider things like:

- Space and capacity
- A large table or area where everyone can gather
- Location
- Privacy and exclusivity
- Kitchen facilities and dining options
- Nearby activities
- Budget
- Reviews and recommendations

Given the unpredictable spring weather in Switzerland, it was challenging to plan outdoor activities. We made sure the lounge area was large enough for the whole team. Luckily, the weather turned out better than expected, and we thoroughly enjoyed our time outside.

<figure>
  <img src="/blog/2023-05-25-team-retreat-01.jpg" width="100%" alt="The team preparing lunch." />
</figure>

### Fun and Games

Part of our retreat involved organizing leisure activities. This gave us a chance to chat, relax, and share some laughs. The weather did force us to mix up our plans a bit.

On the first afternoon, we had a blast at a rope park. For most of the team, it was their first time at such a place. After a safety run-through, we all tried out the first route together to get the hang of it. The routes had different difficulty levels, so we naturally split into groups. We had a great time cheering each other on through the tricky parts where we felt a bit unsure. It was a brilliant combo of fun, learning new skills, and for some of us, even beating our fears 😃.

<figure>
  <img src="/blog/2023-05-25-team-retreat-02.jpg" width="100%" alt="The team on ropes at the rope park." />
</figure>

The next day, we decided on the spur of the moment to go for a two-hour hike around Habkern, taking advantage of the unexpectedly sunny weather. The freedom to do whatever we wanted without sticking to a tight schedule was refreshing. The hike gave us not only good laughs but also a chance to bond and communicate.

For the evening, we initially planned a game night with various quick games, but as the day went on, we realized we might not have time for all of them. So we chose just one game before heading out for dinner: the music guessing game. We split into pairs and took turns playing different songs, enjoying the thrill of recognizing some tunes and the challenge of figuring out the harder ones. It was fun to see how quickly (or not so quickly) we could guess the songs.

<figure>
  <img src="/blog/2023-05-25-team-retreat-03.jpg" width="100%" alt="The team on a hike." />
</figure>

### Team Development Through a Workshop

We believe everyone should have the chance to contribute to making ZITADEL an even better place to work. So, we used the retreat as an opportunity for team development. We considered various options, from hiring an external company for a workshop to using our own expertise. Largely due to time constraints (yes, we were a bit late 😀), we decided to run a workshop ourselves, using a guided platform.

If you ever need to host something on your own, we recommend [Toolbox](https://toolbox.hyperisland.com/). You can filter by category, time frame, and group size to find suitable workshops. We picked the [Team Self-Assessment Workshop](https://toolbox.hyperisland.com/team-self-assessment), which was great for coming up with ideas, addressing challenges, and pinpointing areas where we needed to focus to improve our company.

In the end, it was inspiring to see how much time and effort everyone put into contributing to the discussions. Moving forward, we realized we need to set aside more time for activities like this. When you have a lot of people and opinions, discussions can take longer, and people need breaks to keep their focus sharp.

<figure>
  <img src="/blog/2023-05-25-team-retreat-04.jpg" width="100%" alt="The team at the workshop." />
</figure>

## Lessons Learned

Looking back, our first retreat was a success, full of wonderful memories. Nonetheless, as with any first-time experience, we also gathered some useful insights that we'd like to share.

1. **Time**: Our retreat lasted for two full days, with extra days for arrival and departure. In the future, we think we need more time, as the event seemed to go by too quickly. More time would be especially beneficial for colleagues coming from other countries, as a short trip can be stressful. We also plan to avoid scheduling arrival and departure days on weekends, if possible.
2. **Information Sheet**: We shared important details in the company chat leading up to the retreat, but we found out that not everyone could remember everything. To solve this, we plan to create a detailed information sheet for future retreats. This will include key details like arrival/departure times, a loose schedule (excluding certain activities to keep them a surprise), items to bring, and how to get to the venue.
3. **Transport**: We used private cars for this retreat, but for the next one, we're thinking of choosing a place that's easy to reach by public transport. This would mean we wouldn't need drivers and would make travel easier for everyone.
4. **Meal Planning and Cooking Groups**: Our meal setup worked well for this retreat, as we didn't have many meals. For future retreats, though, we're considering creating cooking groups. Each group would be in charge of one meal, giving us a chance to try foods from different countries within our team.

By putting these insights into action and listening to feedback from the team, we're confident that our future retreats will be even more memorable, enjoyable, and smoothly run.

## Building Upon the Success of Our First Team Retreat

To sum up, our first team retreat marked an important milestone in our journey as a remote-first company. It brought us closer, strengthened our bonds, and gave us valuable insights for future retreats. We are grateful for the opportunity to gather in person, experience thrilling adventures, and engage in meaningful conversations. As we move forward, we are excited to build upon the success of this retreat, incorporating the lessons learned and continuously refining our approach. Our commitment to fostering a supportive and inclusive team culture is unwavering, and we can't wait for the next stage of our team retreat journey. . Stay tuned for more incredible stories and shared experiences from our remote-first team.

Cheers,

**_The ZITADEL Team_**

<figure>
  <img src="/blog/2023-05-25-team-retreat-05.jpg" width="100%" alt="Team picture." />
</figure>


This article recounts the journey of our first team retreat as a remote-first company.

Reuniting Across Boundaries: Our Unforgettable First Team Retreat


Maintaining proper password hygiene does not end with creating a strong password - **How your passwords are subsequently stored** is equally pivotal to the safety of your personal data.

The most common practice enterprises use to authenticate their users is implementing a system that **compares offered credentials to those stored in a centralized database.** Due to the comprehensive collection of user passwords in this database, it has unfortunately emerged as an **attractive objective for malicious actors.**

This article discusses the **importance of password hashing and salting** to secure password storage.

![Hashed Password Illustration](/blog/2023-05-18-password-hashing-01.gif "Password Hashing")

## What is Password Hashing and why is it used?

The term "password hashing" refers to the process by which a **cryptographic algorithm** converts a password irrevocably into a **string of characters and numbers known as a hash**. After this conversion, **the password is stored on the company’s server in its hashed state instead of plain text**. 

But why is it necessary to **store passwords as a string of code?** The answer is simple: Doing so helps to **safeguard it against a potential attack on the database**.

Imagine you are a user attempting to sign in to your company’s server. After entering your password, it is **automatically hashed and compared to the hash stored in the platform’s database**. If an attacker gained unauthorized access to this database, they could still only see a code in your password’s place. Since **password hashing is a one-way function**, it is impossible for them to determine the actual password from the hash alone. 

## The Importance of Salted Passwords

While holding a hashed password in a server's database is unquestionably safer than displaying it in plain text, **password hashing is still not immune to all types of cyberattacks**.

As an example, if the attacker were to **learn the hash function used by the hashing algorithm,** they could try conducting a **brute-force attack by entering random passwords into the function** until a matching hash is found. While this particular attack might often prove inefficient, because **hash functions can be configured to take a long time to execute,** there is, unfortunately, another method at the attacker's disposal:

One of the most common methods attackers use to crack password hashes is called the **“Rainbow Table Attack.”**

### Rainbow Tables 

Rainbow tables are **large databases containing precalculated hash values for common passwords**. If a hacker manages to compromise a hash already listed on the table, they can **trace that hash chain backward** to determine the original password.

Think of hashing a plaintext password as an equivalent of **translating a word into another language.** Just like how “Katze” is consistently translated as “cat,” the hash code for the password “qwerty” will always be represented by **the same combination of characters and digits.** Rainbow tables are similar to dictionaries, storing a list of passwords along with their corresponding “translations.” Therefore, **if a hacker figures out this universal hash** for “qwerty,” they would automatically be able to **recognize this password in every database** - as if it were written in plain text.

### Adding Salt to Hashing

As proven by the security issue posed by brute-force attacks and rainbow tables, **Password Hashing alone is not entirely foolproof.** Fortunately, a specific technique can be used to **boost hashes and subsequently counteract rainbow table attacks.** This method is called **Salt Hashing**, also known as adding Salt to a password.

In this context, **the term “salt” describes a random string of characters added to the password prior to hashing.** The hash is then created based on **the combination of the random salt and the password** instead of the password alone. Since the value of the salt is uniquely generated for every hashing process, **even if two users have the same password, their hash codes will differ.** Thus, making the rainbow table useless.

This technique of salting passwords has become a **fundamental element of modern hashing algorithms, such as bcrypt.** As opposed to weak hashes found in older algorithms, an attempt at breaking the robust architecture of salted hashing functions would require **far more computational power** than ever before. 

![Adding Salt to Hashes](/blog/2023-05-18-password-hashing-02.png "Password Salting")

## Hashing and Salting with Bcrypt

In the age of ever-evolving cyberattacks, **password hashing and salting are indispensable components of every current password management system.** Fortunately, a reliable **authentication solution** can lift these administrative responsibilities off your company's shoulders.

**ZITADEL** is a rapidly growing open-source platform that assists thousands of businesses in keeping sensitive information out of the wrong hands. The solution uses **bcrypt**, a ready-to-use high-level function **that handles the salt, hashing, and string encoding.** Due to bcrypt’s adaptability and integrated work factor, this tool is **highly successful in preventing unwanted access to user accounts.** Migrating users from a system that does not support bcrypt requires users to reset their passwords, as it is **impossible to transform one hash to another hash function** on the fly.  Thus, we will **expand the options of available hash-functions** in the future, such that **multiple hash functions are supported**. 


This article discusses the importance of password hashing and salting to secure password storage.

How Password Hashing and Salt Can Enhance Password Security


The most distinct feature of ZITADEL is how you can structure your identity architecture around Users and Organizations.
Whether you're building a customer-facing app and looking for a CIAM solution to handle authentication for you, or trying to offer hundreds of business customers and partners the ability to use their identities and delegate permission management to your customer, it's worth understanding how you can build your solution scenarios with ZITADEL.

This article aims to give you an overview of the overall concepts used and explain the most important points, so you can get started with enough knowledge at hand.

## Organization vs. Instance

The highest level of separation in ZITADEL is an [instance](/docs/concepts/structure/instance).
ZITADEL allows you to operate multiple virtual instances on the same system with the same database.

Access across instances is not possible.
Instances can be managed with the [System API](/docs/apis/introduction#system) as described in this [Guide](/docs/guides/integrate/access-zitadel-system-api).

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-12.png"
    width="80%"
    alt="Two instances with each organizations in it using the same database"
  />
  <figcaption>Two isolated instances with individual organization structures using the same database</figcaption>
</figure>

It's important to note that some settings can only be set per instance, specifically:

- SMTP Service: All emails within the instance will be sent from this service
- Custom Domain: You can define under which domains (eg, `login.demo-vendor.com`) the ZITADEL service can be accessed

> **Note:**  
> At the time of writing, token lifetimes can only be configured on instance level.
> There is no technical limitation, but it is an outstanding [feature](https://github.com/zitadel/zitadel/issues/5219).

Instances provide one form of multi-tenancy in ZITADEL, where each tenant is completely isolated.
However, most scenarios might involve some form of self-service or fluidity between the different tenants to reduce administrative overhead.
These cases most often leverage our organization model within a single instance.

## Organizations

Think of an organization as a way to group users and set shared policies (our term for "settings") such as login, security, branding.
Organizations also allow you to manage applications centrally and grant other organizations to them.

### User Management

In the following diagram, you can see two organizations.
One for a service provider, for example a software vendor or project like you, and one for a customer organization.
Each organization has its own users.

![](/blog/2023-04-15-multi-tenancy-with-organizations-01.png)

[Users](https://zitadel.com/docs/concepts/structure/users) will always belong to one [organization](https://zitadel.com/docs/concepts/structure/organizations).
You have a high degree of flexibility when it comes to how you structure your identities.
You can put all your users in one organization and use ZITADEL like any other CIAM.
Just as well, you might want to split users in different groups.
For example, you may want to separate your customers from your team members or employee identities.
Alternatively, you may want to keep each of your customers' identities in its own organization.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-02.png"
    width="100%"
    alt="List of organizations of an instance"
  />
  <figcaption>List of organizations of an instance</figcaption>
</figure>

### Managing Roles and Applications

Each organization can have multiple [projects](https://zitadel.com/docs/concepts/structure/projects), and each project can contain multiple applications with a shared set of [roles](https://zitadel.com/docs/concepts/structure/projects#roles).
Think of a project like a "shared security context" for [applications](https://zitadel.com/docs/concepts/structure/applications) that logically belong together.
For example, a web app and mobile app, or a front-end and back-end of the same service.

In the example below, you can see that the service provider has the two projects **Portal** and **Data Cube**.
**Portal** would serve as customer portal for all customers to access their services and contains roles like **reader**, **admin**, **support:read**, **support:write** to grant users a different set of permissions.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-03.png"
    width="100%"
    alt="Multiple projects in one organization"
  />
  <figcaption>Multiple projects in one organization</figcaption>
</figure>

The service **Data Cube** may require different roles, such as **analyst**, **engineer**, **manager**, and could be granted to customer organizations based on a subscription option.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-04.png"
    width="100%"
    alt="Multiple applications in a project that share the same roles"
  />
  <figcaption>Multiple applications in a project that share the same roles</figcaption>
</figure>

### Login and Access Policies

For each organization, you can define individual policies around login, access, branding, and domains.

With the [security settings](https://zitadel.com/docs/concepts/structure/policies) per organization, it is possible, for example, to configure different external identity providers per customer organization.
You could configure one organization to allow login with a customers' AzureAD tenant, while configuring another customer organization to login with a local password and 2FA.

At this point, you might ask yourself: How to redirect users to the correct domain?

One way would be to setup [domain discovery](/docs/guides/solution-scenarios/domain-discovery) on your instance to route users according to their login name or email address.
Another option is to send a reserved scope with your auth request to enforce the organization's policies on the login.

## Delegated Access Management

> **Broken Authorization is a Major Risk to Web Applications**  
> The highest-ranking risk for web-applications is [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/), according to the [OWASP Top 10](https://owasp.org/Top10/).
> Providing a secure way of authorization in a multi-tenancy setup, while allowing for self-service, is difficult to achieve.
> We built ZITADEL, based on our experience, from the ground up with this particular challenge in mind, so you don't have to worry about it.

Now we get to the more interesting part of the setup.

How can you give other organizations access to a project and its applications?
And once the organization has access, how can they give permissions to their users?

That is where the unique delegated access management feature of ZITADEL comes into play.

Instead of copying over all projects or applications to each customer organization, which would result in quite some overhead to manage at scale, you can [grant projects](https://zitadel.com/docs/concepts/structure/granted_projects) to other organizations.

### Project Grants

With a [project grant](https://zitadel.com/docs/concepts/structure/granted_projects), you can select a subset of roles that the receiving organization can assign to their users.

![](/blog/2023-04-15-multi-tenancy-with-organizations-01.png)

As an example you could keep certain administrative roles for support or developers in your own organization.
Or you might want to only grant a role once the customer has subscribed to a feature in your application.

Think of a project grant as creating a link to the project.
You don't need to manage the applications within each organization, but only grant them to other organizations.
The receiving organization will see an incoming projects as a "Granted Project" and cannot change the project and that project's applications directly, but only use the roles to authorize their own users.

In the following screen, you can see that the project **Portal**, which is owned by the organization **Demo-Vendor**, has two active grants to **Demo-Customer** and **Demo-Customer2** respectively.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-05.png"
    width="100%"
    alt="Project grants from Demo-Vendor to customer organizations"
  />
  <figcaption>Project grants from the service provider Demo-Vendor to customer organizations</figcaption>
</figure>

The organization **Demo-Customer2** sees the granted project under the tab "Granted Projects". When clicking on it, you can't edit the project itself, like how Managers of **Demo-Vendor** could, but only assign the granted roles to your users, given you have the permissions.
We will discuss Managers in the next section.

<figure>
  <img src="/blog/2023-04-15-multi-tenancy-with-organizations-06.png" width="100%" alt="List of granted projects" />
  <figcaption>Granted (incoming) projects in the customer organization</figcaption>
</figure>

You can always get an overview of all authorizations under the **Authorizations** tab in the ZITADEL console.
Here you can also see that the user **Eric Employee** has the role **reader** in the granted Project **Portal**.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-07.png"
    width="100%"
    alt="Authorizations can be given to granted projects"
  />
  <figcaption>Authorizations can be given to granted projects</figcaption>
</figure>

When **Demo-Vendor** removes the project grant to an organization, then all authorizations will be removed as well.

### Delegate Self-Service to Customers

[Managers](https://zitadel.com/docs/concepts/structure/managers) allow you to let organizations self-assign roles to users, thus authorizing them to access the granted Project.
Managers are an internal role and permission concept of ZITADEL.
The concept offers many use cases for delegating [self-service](https://zitadel.com/docs/concepts/features/selfservice) to users in other organizations.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-08.png"
    width="100%"
    alt="Machine and human users can take on different manager memberships"
  />
  <figcaption>Machine and human users can take on different manager memberships</figcaption>
</figure>

For example, in a SaaS application, you might assign a manager role to the first user in a new organization.
With that, this user could, for example, configure SSO and assign roles to their team members.

Integrate self-service features for managers into your application by using our APIs, or start your POC by letting users configure their organization via the branded console.
The console will always be scoped to the manager permissions of a user.

## Authorize Users Outside of Your Organization

But wait... there is more 🤯! We've already learned that you can isolate tenants with [instances](/docs/concepts/structure/instance). We also saw how create a multi-tenancy setup with [organizations](https://zitadel.com/docs/concepts/structure/organizations) that allow for grouping users, individual security policies (such as configurations of external identity providers), and delegating access management using [managers](https://zitadel.com/docs/concepts/structure/managers).

So, how about a situation where one of your customers wants to invite users from another of your partners/customers and give them access to their organization's resources?

Here are a few of use cases for this:

- Accounting: You offer an accounting platform for SMEs. Your customers are the SMEs but also fiduciaries and accounting firms as partners that manage the finances of the SMEs. Each SME and partner would have their own organization with their own users and either log in with their business account or with a local account on your platform. The SMEs can grant access to their organization by inviting users of partners and authorize them with specific roles as part of your organization, so that they get access to the data they need.
- Education: You are an EdTech provider for different schools. You have an organization per school with teachers and students as users. Some teachers are, however, also responsible for conducting classes at another school. You can create a user grant for these teachers to the secondary placement. Note: in case the accounts would not be managed by one primary school, you would anyway set up two accounts and manage the logic to select an account in your application.
- Healthcare: A university hospital is sponsoring a platform for cross-hospital knowledge and case exchange (e.g., scientific boards). Instead of creating separate accounts for each participant in your organization, you could create an organization for each participating organization. Then let users sign in with their existing accounts from their hospital and create a user grant, such that they get access to your project where you assign roles for the digital collaboration workspace.

Technically this would look similar as indicated in the next diagram.
As service provider, for example for a time-keeping app, ACME organization owns a project with the roles **Accountant** and **Developer**.
The project is granted to both Alpha and Beta where Beta has assigned Bob already the role **Developer**.

Alice from Alpha is the accountant of Beta and requires regular access to the time-keeping app to do her job.
Beta can create a User Grant for Alice and assign her the role **Accountant** in self-service.
Alice can now access the Project as external user of Beta with her role.

ACME must implement the application permissions for such cases within their application.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-10.png"
    width="100%"
    alt="User Grants allow you to grant access to users managed by another organization and assign them roles"
  />
  <figcaption>
    User grants allow you to grant access to users managed by another organization and assign them roles
  </figcaption>
</figure>

This feature goes beyond a traditional multi-tenancy approach by also allowing delegated access management tenant-to-tenant via user grants.
You can integrate such external user management with ease in your application using our [APIs](/docs/category/apis/resources/auth/user-authorizations-grants).

Here is how you can set up a user grant via the ZITADEL console:

1. Go to **Authorizations** and press **N** (or click the button) to create a new authorization.
2. Under the text field **Loginname** there is a hint "If you want to grant a user of another organization click here".
3. Click on **click here** to switch to external users.
4. Enter the loginname of the external user and select a granted or owned project.
5. Go to the next screen and add the roles to the user.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-11.png"
    width="100%"
    alt="Create a user grant in the console"
  />
  <figcaption>Create a user grant in the console</figcaption>
</figure>

The user will be now visible under Authorizations.
You can't view or edit the user's details, since it is being managed by another organization.
But you can change the associated roles like for internal users.

## Conclusion

We went through several aspects of multi-tenancy of ZITADEL:

- Use instances to completely separate tenants
- Use organizations to group users, security policies, and other settings
- Manage your project centrally in one organization and grant the project to other organizations
- By assigning a Manager, a receiving organization can give permissions to their users via the incoming project
- You can also invite external users from another organization to your organization and give them permission to your owned or granted projects

In conclusion, ZITADEL has a high degree of flexibility to fit your use case. ZITADEL's multi-tenancy features provide a comprehensive solution for managing users, projects, and security policies across multiple tenants, ensuring a secure and efficient environment for your applications and services.
Check out our [Solution Scenarios](/docs/guides/solution-scenarios/introduction) and try out the [Sample B2B application](https://github.com/zitadel/zitadel-nextjs-b2b) for more hands-on learning.


This article explains the most important concepts on how you can structure your multi-tenancy identity architecture with organizations.

Multi-Tenancy and Delegated Access Management with Organizations


Whether it is a social media site, an online game, or even a banking app - **registering to any platform generally necessitates the determination of a new password**. To diminish the risk of higher-scale data breaches, this set of login credentials **should not be reused** across multiple platforms. But is it realistic to anticipate individuals to remember each distinctive password for their conceivably dozens of virtual identities?
 
In recent years, numerous businesses have implemented solutions like **federated identity management (FIM) and single sign-on (SSO) to enhance authentication process security** while minimizing password fatigue. While both of these tools aim to facilitate access to resources, they present **two distinct approaches to identity and access management (IAM)** that differ in scope and complexity.
 
This article discusses the difference between Federated Identity Management (FIM) and Single-Sign-On (SSO) and their respective uses.

![SSO Illustration](/blog/2023-04-27-sso-vs-fim-01.png "Single-Sign-On")

## What is Single-Sign-On (SSO)?

**Single-Sign-On (SSO)** is a mechanism that enables you to delegate end-user account creation and administration to a **centralized Identity Provider (IdP)**, thus allowing users to **access multiple resources within the same organization with a single login process** seamlessly. Though the same server manages these individual accounts, they are still entirely separate from each other: For instance, Google only requires its users to **authenticate once with the central identity provider to access multiple resources**, such as YouTube, Gmail, and Drive.

One of the most significant advantages of SSO is that it **improves business security by lowering the number of passwords that users must manage**. To achieve this, SSO relies on authentication protocols, such as **[Security Assertion Markup Language (SAML)](https://zitadel.com/blog/saml-support) and [OpenID Connect (OIDC)](https://zitadel.com/blog/secure-logins-with-zitadel-part-1)**, which enable users to authenticate once with a central identity provider and then access multiple resources without having to re-enter their credentials. Furthermore, unlike it is used to be the case within an enterprise setup, **applications with an SSO feature only receive authentication tokens instead of the credentials themselves**. Thus, the leakage of passwords/credentials to compromised applications/services can be prevented. 

Since passwords are a common attack vector, lessening dependence on them minimizes the possibility of data breaches and social engineering attacks.

## What is Federated Identity Management (FIM)?

**Federated Identity Management (FIM)** connects identity management systems by establishing a trusted relationship between **different organizations**, allowing them to **utilize the same digital identity to access all their applications** and networks (single access). The reason behind its development was to **enable entities on one domain to access user information held in other domains**.

The enterprises are **linked via third-party identity providers that store their credentials**. Furthermore, FIM enables the safe transfer of authentication and access information between domains by **relying on robust security protocols such as SAML and OpenID Connect (OIDC)**, akin to SSO. Accordingly, users are provided with a secure and streamlined login experience, while allowing the respective organizations to retain control over user authentication and authorization.

A real-life example of FIM is using Facebook credentials to log into several services federated with Facebook, such as Instagram, Netflix, and Disney+.

## SSO vs. FIM

It goes without saying that Single Sign-On and Federated Identity Management seem relatively similar at first glance: **They both simplify authentication for consumers and businesses by merely requiring a single set of credentials to access various resources**. In fact, they can even be used jointly because **FIM significantly relies on SSO technology** to authenticate users across domains.

So, **since FIM can technically give us SSO as well**, it should be a no-brainer for every company to deploy FIM, right? Not necessarily. 

Despite their similarities, the two approaches operate in quite different ways and have **unique applications**. To assist you in determining which technique's implementation would suit your organization better, the following paragraphs showcase **the most notable distinctions between SSO and FIM**. 

### Range of Access and Scalability

The most prominent distinction between the two mechanisms is their **range of access**. While both approaches allow users to access a plethora of resources through a single login procedure, in the case of **SSO**, this admission **only pertains to a specific organization or a set of related organizations**. On the other hand, **identity federation** takes a step further by **allowing access across various organizations and domains within the federated group**.

SSO's smaller range of access may also pose a **scalability challenge** for businesses that use a diverse set of apps and platforms. Thus, **switching to a federated identity provider** would enable users to **access their employers' entire array of services, provided they support identity federation**.

### Complexity and Cost

Given its significantly broader range of access, it is no surprise that **FIM solutions are generally more complex and costly to operate**. They require managing more resources and may require specialized expertise to implement and maintain. Additionally, FIM **necessitates the establishment of trust relationships** among various identity providers.

Ultimately, both of these attributes **highly depend on the size of your organization, the number of applications you wish to integrate,** and the **specific requirements of your security and compliance policies** - neither FIM nor SSO comes with a predefined price tag.                                                                                                                                                                                                                                                                                   

### Security

Due to their diverse built-in security integrations, **both SSO and FIM are highly secure mechanisms for protecting personal data**. However, one contentious aspect of SSO stems from its reliance on a single identity provider: Accordingly, **if the IdP suffers a security compromise, it may impair access to numerous resources** and applications as a result. In the case of federated identity management, **the user credentials are not stored in a centralized location**; thus, the danger of a single breach compromising all accounts is lower.

However, it is worth noting that **most SSO vendors enforce strict security policies to ensure the password is as safe as possible**, such as giving it an expiration date or locking the account after some failed login attempts. 

## In Conclusion

Ultimately, **the decision to implement Federated Identity Management or Single Sign-On should be based on your company's specific characteristics**. For instance, companies that use a limited number of apps and services may find SSO a more suitable fit. In contrast, **FIM is often preferred in larger enterprises with several identity providers** and service providers or when cross-organizational collaboration is required. 

Whether you wish to deploy SSO or FIM, **with ZITADEL as your organization’s authentication solution, both options are well accounted for**. You may implement our **SSO feature** or utilize our **JSON Web Token Identity Provider (JWT IDP)** to use an (existing) JWT as a federated identity. 


Numerous businesses have implemented solutions like federated identity management (FIM) and single sign-on (SSO) to enhance authentication process security while minimizing password fatigue. This article discusses the difference between these two approaches.

Single Sign-On (SSO) vs. Federated Identity Management (FIM) - The Key Differences


[ZITADEL](https://zitadel.com) is an open source identity platform that addresses the challenges of self-service, authentication, and authorization by integrating them into your project. It supports multi-tenancy for business-to-business (B2B), identity brokering, multifactor/passwordless authentication, delegated access management, in-context audit trail, [OpenID Connect](https://openid.net/connect/), SAML 2.0, and [OAuth 2.0](https://oauth.net/2/). 

In contrast, [Firebase](http://firebase.google.com/) is a backend as a service (BaaS) that provides developers with a variety of tools and services to help them build quality applications. It's categorized as a NoSQL database platform because the data is stored in a JSON-like format.

With ZITADEL, you can avoid hours of creating, configuring, and operating complex authentication and authorization systems. Meanwhile, Firebase on the other end provides you with commodity features for all of your backend needs, including cloud messaging, testing, crashlytics, authentication, and real-time databases.

Developing with a powerful and feature-rich platform can be essential in creating a reliable and high-quality mobile and web application. It takes a lot of dedication and time to manage files and resources, server configuration, analytics, and other related operations.

In this article, you'll compare ZITADEL and Firebase authentication and look specifically at where they differ in regard to their authentication and authorization features, integrations, and architecture.

## ZITADEL vs. Firebase

ZITADEL and Firebase can both be used to achieve authentication and authorization in your application. However, there are a few factors, like authentication features and integrations, that can help you decide which platform is best for you. Let's take a look at the authentication features each platform offers:

### Firebase Authentication

The main goal of an authentication provider is to be able to identify each user in your application, which is where Firebase Auth comes into play. With Firebase, you have to obtain an authentication credential from the user in order to sign them into your application. The user's email address and password or an OAuth token from a third-party service can serve as these credentials. If you choose to upgrade to Firebase Authentication with Identity Platform, you can authenticate users on your platform with any identity provider that supports [OIDC](https://firebase.google.com/docs/auth/web/openid-connect) or [SAML](https://firebase.google.com/docs/auth/web/saml).

You can incorporate a quick sign-up and sign-in feature for your users using FirebaseUI Auth. By doing so, users spend less time creating profiles or signing up, which boosts conversion rates. Additionally, it tackles scenarios that can be tricky to manage appropriately in terms of security, such as [account recovery and account linkage](https://firebase.google.com/docs/auth/web/firebaseui). Furthermore, the Firebase SDK Authentication is also an authentication function you can include in your application. It gives you various authentication functions, including the following:

- **Email and password authentication:** Users that sign in with their email addresses and passwords can be created and managed using the Firebase Authentication SDK.
- **Third-party-powered authentication:** Google, Facebook, Twitter, and GitHub user accounts can be used to log in using the Firebase Authentication SDK's APIs.
- **Phone number authentication:** Users can be authenticated after receiving a one-time password (OTP) SMS message on their phones.
- Other authentication channels include custom authentication using a limited list of [federated identity providers](https://firebase.google.com/docs/auth/where-to-start#firebasesdk), any third-party identity providers on a [pricier plan](https://firebase.google.com/docs/auth#identity-platform), and anonymous authentication for temporary accounts.

Firebase authentication can also be achieved using an identity platform. You have the option to add an optional authentication feature (like multifactor authentication, blocking function, multi-tenancy, SAML, and OIDC) to your application using the [Identity Platform](https://firebase.google.com/docs/auth).

### ZITADEL Authentication

ZITADEL provides you with the option to use third-party-powered authentication to provide trust between your application and the users. For instance, if you set Google as an identity provider, ZITADEL can redirect the user to log in with their Google account and give ZITADEL access to take their credentials as a form of identification on the platform.

You can use the following authentication features with ZITADEL:

- You can register an OIDC client of your choice and add a ZITADEL callback redirect (make sure the provider is OIDC 1.0 compliant with a proper [discovery endpoint](/docs/guides/integrate/login-users). This will give your users the option to log into your ZITADEL-powered application using the OIDC authentication feature.
- You can use a SAML sign-in option that gives your users the ability to authenticate once and gain access to multiple secured parts of your application without resubmitting their credentials.
- You can choose to let your users log in with a traditional username and password.
- You can authenticate via external identities, such as Google, Microsoft, or Apple.
- You can force a user to register and use multifactor authentication through a universal second factor, such as OTP, alongside their pin.
- You can decide to use passwordless login authentication. Your user can either use device-dependent (e.g., fingerprint, face recognition, and [Windows Hello](https://support.microsoft.com/en-us/windows/learn-about-windows-hello-and-set-it-up-dae28983-8242-bb2a-d3d1-87c9d265a5f0)) or device-independent (e.g., [YubiKey](https://www.yubico.com) and [SoloKeys](https://solokeys.com)) access.
- You can use multi-tenancy authentication to allow a user to authenticate themselves once with authorizations in multiple organizations. It simplifies the whole authentication process for users regardless of their tenancy, while allowing you to have multiple organizations with different users. ZITADEL ensures each tenant has complete privacy regarding their data, a highly-customizable login flow, and on-demand scaling.

As you can see, both ZITADEL and Firebase provide numerous ways to authenticate your users. However, ZITADEL stands out in that it gives you open access to any third-party [identity broker](/docs/concepts/features/identity-brokering) without any complex pricing plans. You can use OIDC or SAML to connect with any third-party identity provider and provide your users with the authentication they want.

If you're in need of a quick authentication feature for your application, Firebase is a good option. However, if you need more advanced authorization, user self-service, and multi-tenancy features for your application, ZITADEL is the superior choice because it's built to handle your authentication needs, no matter the complexity of your application.

### Firebase Integrations

Programming in C++, Java, JavaScript, JavaScript/Node.js, Objective-C, and Swift is supported by the [Firebase SDK](https://firebase.google.com/docs/firestore/client/libraries). Database bindings and libraries with limited functionality in [Angular](https://github.com/angular/angularfire), [Backbone.js](https://github.com/googlearchive/backbonefire) and [Ember.js](https://github.com/FirebaseExtended/emberfire) are also supported.

For the uninitiated, bindings are basic mappings of APIs to in-code functions that carry out standard operations like CRUD. However, they're not as detailed as SDKs, and sometimes a binding scan can go beyond the basic CRUD operations and offer cosmetic improvements or alternatives to existing methods and features, in which case they are often referred to as auxiliary or supplementary bindings.

Google has added a few supplementary bindings and libraries like [FirebaseUI](https://github.com/firebase/firebaseui-web), [GeoFire](https://github.com/googlearchive/geofire), [Firebase Queue](https://github.com/FirebaseExtended/firebase-queue), and [FirebaseJobDispatcher](https://developer.android.com/topic/libraries/architecture/workmanager/). These auxiliary bindings add more functionality to your application, including [drop-in authentication with FirebaseUI](https://firebaseopensource.com/projects/firebase/firebaseui-web) and [real-time location queries with GeoFire](https://firebaseopensource.com/projects/firebase/geofire-android/).

Additionally, Firebase allows for integration with [Elasticsearch](https://www.elastic.co/what-is/elasticsearch) and the import of big JSON data collections. You can find out more about implementation in the official [Firebase docs](https://firebase.google.com/docs/guides).

### ZITADEL Integrations

ZITADEL is younger than Firebase and provides gRPC, gRPC-web, and Rest APIs, which are supported by most common programming languages, including Angular, React, [Flutter](https://flutter.dev/), [Next.js](https://nextjs.org/), Java, Python, Go, .NET, and [Dart](https://dart.dev/). In addition, you can opt for either the cloud SaaS version or [self-host](/docs/guides/deploy/overview) it using the [open-sourced repo](http://github.com/zitadel/zitadel). To see a few different ways integrations can be used, check out [ZITADEL's official docs](/docs/sdk-examples/introduction).

ZITADEL provides ample APIs and SDKs to help you integrate with most programming languages. You can also easily integrate your apps with open standards such as OpenID Connect, OAuth 2.0, SAML, etc., when using ZITADEL.

Both ZITADEL and Firebase integrate with a wide range of programming languages, which gives you the ability to work with whatever language or framework you're most comfortable with.

### Firebase Use Cases

As previously stated, Firebase is a full-featured BaaS platform, offering all the capabilities required to swiftly create complex, collaborative apps that can support millions of users. The architecture of Firebase is designed to work in any of the following situations:

* **Firebase-powered application:** Firebase sits in between your application and your client. All you need to worry about is the client side of the application, while Firebase handles the complex backend structure. Resource sharing and storage are both handled by Firebase.
* **Firebase-powered application with server-side:** Firebase is positioned between the server and clients in this architecture. In other words, your server interacts with Firebase to send and receive resources from clients. You can decide who has full access to the data and how it should be handled using your security settings and Firebase rules. Then your server code keeps an eye out for any data changes made by clients and reacts as needed. Even though you're still running a server, Firebase is handling all the heavy lifting of scale and real-time updates.
* **Firebase-powered functionality in an existing application:** In this architecture, Firebase can be integrated alongside your existing server. Your clients will establish connections to both your server and Firebase, using Firebase to power your real-time features while keeping the rest of your application running smoothly.

Using any of these capabilities, you can add a real-time notification system for your users, integrate a chat feature into your website, produce a real-time comment feed, and more. An easy way to start using Firebase is to test out some of its minor functionalities.

### ZITADEL Use Cases

ZITADEL offers you much more control over how your IAM system is deployed. You can use ZITADEL in any of the following use-cases:

* **Out-of-the-box integration with your apps:** ZITADEL can offer you a central login experience that can handle all your users in one place. When a user requests to authenticate, you send them over to the central login widget of ZITADEL to retrieve their details once they're successfully authenticated.
* **Multi-tenancy support:** When building business-to-business (B2B) apps, you need to enable your customers to have control over their authentication flow. They should be able to choose and customize things like branding, federation, and policies. This is often not possible with providers like Firebase Auth because it was originally intended for business-to-consumer (B2C) apps. ZITADEL enables you to support your B2B customers and provide their users with the best experience possible.
* **Self-service experience:** As mentioned above, B2B customers need control over their branding and access rules, and it's not scalable for you to approve or moderate changes. ZITADEL offers you a complete self-service platform that your customers can use to easily self-manage their projects in your apps.
* **Using existing identities:** Many B2B customers want to rely on established third-party identity providers or their own company logins instead of going down the generic email-password route. Federated login flows only partly solve this problem because they don't allow you to choose *any* third-party provider, and reusing a company login is an even more complex task. ZITADEL works best in this case since you can allow your customers to use common protocols like OIDC and SAML to register any recognized identity provider with the IAM solution and manage it on a centralized platform.

Internally, ZITADEL is composed of [two principal architectural styles](https://zitadel.com/docs/concepts/architecture/software): command and query responsibility segregation (CQRS), and event sourcing (ES). Combining ES and CQRS improves ZITADEL's consistency and offers numerous advantages.

Due to the nature of Event Sourcing, ZITADEL has the singular ability to create a robust audit record of everything that occurs on its resources—all while maintaining storage costs and audit trail length.

In summary, if your application needs backend functionality, authentication needs, or real-time data alongside your existing server, Firebase gives you the ability to integrate it with your application at any stage (development or production). Meanwhile, ZITADEL's easy integration into your application helps you handle the authentication, authorization, and self-service parts of your application. If you're looking for a platform that will manage your user identity and provide you complete control over it, ZITADEL is the superior choice.

## Conclusion

In this article, you learned about the key differences between Firebase Authentication and [ZITADEL](https://zitadel.com/). You saw how they compared to each other and how you can integrate them into your project, their architectural choices, as well as the different features they offer.

Firebase in general provides you with backend functions that you can use while building your application's frontend or when scaling your applications. In contrast, ZITADEL gives you flexibility with your programming language and unlimited authentication options.

[ZITADEL](https://zitadel.com/) is an open source identity management platform that provides you with a wide range of features like OpenID Connect, SAML 2.0, OAuth 2, FIDO2, OTP, and an unlimited audit trail. With ZITADEL, you can solve all your authentication and authorization needs. Check out the ZITADEL repo and give us a [GitHub star](https://github.com/zitadel/zitadel). We appreciate the feedback.


*This article was contributed by [Aransiola Ayodele](https://portal.draft.dev/writers/rec2hTGbxNzwgQITY).*


The purpose of this article is to guide readers on what are the differences between ZITADEL and Firebase

Comparing ZITADEL to Firebase


## Key Outcomes

- [Kaspar&](https://www.kasparund.ch/), a Swiss fintech company,  uses [ZITADEL Cloud](https://zitadel.com/signin) for centralized user and access management, serving both external customers and internal users.
- By leveraging ZITADEL, Kaspar& has successfully enhanced the user experience and security for B2C customers interacting with their mobile app. They achieved this through streamlined user registration and management processes while maintaining high security standards with features, such as passwordless authentication and multi-factor authentication offered by ZITADEL. This resulted in a significant reduction in time spent on these tasks compared to when they were using their in-house solution.
- ZITADEL will play a crucial role in the growth and expansion of Kaspar&'s core offering to expand its fintech services to a broader clientele in Switzerland. By integrating additional two-factor authentication methods, Kaspar& can offer a higher level of security for their customers.  Furthermore, ZITADEL's built-in organization model and federated authentication capabilities  will enable Kaspar& to efficiently manage their B2B user base.

## Introduction

[Kaspar&](https://www.kasparund.ch/) is a fintech in Switzerland, co-founded by CTO [Sebastian Büchler](https://www.linkedin.com/in/sebastian-b%C3%BCchler/), that offers a user-friendly, mobile app-based wealth management service.  We spoke with Sebastian to gain insight into the problems they encountered and the reasons behind choosing ZITADEL as their identity and access management solution.
Kaspar& provides users a convenient and affordable way to invest and manage their finances using their smartphones. Users can set various investment goals, choose from different investment strategies, and track their portfolio performance. Kaspar&'s customers are retail customers, primarily from traditional banks, wanting to invest money. Kaspar& operates on a cost-effective, technology-driven business model. By leveraging digital platforms and forgoing the need for physical branches and expensive financial advisors, the company can provide professional wealth management services at a fraction of the cost compared to traditional financial institutions. Kaspar& also offers a debit card for making online and offline purchases, which enables automatic investment of the spare change from those transactions.

Kaspar& generates revenue by charging a fee for its wealth management services. This fee is typically lower than those charged by traditional banks and investment advisors. As a spin-off from the University of St.Gallen (HSG) and ETH Zurich, Kaspar& bases its investment decisions on the latest financial market theories and practical concepts, ensuring that users benefit from a professional, research-driven approach to wealth management. Moreover, Kaspar& is regulated by the [Swiss Financial Market Supervisory Authority FINMA](https://www.finma.ch/en/) and partners with [Hypothekarbank Lenzburg](https://www.hbl.ch/de/private/), ensuring that users' investments are held securely in a Swiss bank.
To get started with Kaspar&, users have to: 
- Download the Kaspar& app from the App Store or Play Store.
- Sign up by providing personal information, answering financial questions, and completing the KYC (Know Your Customers) process, which includes an automated video identification process. Kaspar&'s services are restricted to Switzerland; customers must have a Swiss domicile address to register.
- Make an initial deposit from a Swiss bank account.
- Set investment goals, such as retirement or education funding.
- Choose an investment strategy (Comfortable, Normal, or Sporty).
- Start investing with as little as one franc.
- Monitor and manage investments, adjust strategy, and change thematic focus within the app.

## Problem

Kaspar& faced several pain points related to authentication and user management. As Sebastian explained, the company had used an in-house solution that used JSON Web tokens for customer authentication. Although the basic login functionality was relatively simple to implement, other aspects, such as the sign-up process, password reset, two-factor authentication, and security-related concerns proved to be more challenging. 

With the rapid growth and expansion of their customer base, Kaspar& needed a robust and scalable identity and access management (IAM) solution to manage user authentication, both for the customer-facing mobile app and for accessing internal  applications. 

Moreover, Kaspar& wanted a managed solution that was cost-effective, compatible with their Business-to-Customer (B2C) model, and provided data residency in Switzerland to ensure regulatory compliance and maintain customer trust. Sebastian explained that they found the per-user pricing of most of the major market players to be too expensive for their customer base.

## Solution

### Addressing Customer Identity and Access Management Needs

Based on the recommendation of a mentoring agency, the Kaspar& team was introduced to ZITADEL, which they found to be a better fit for their needs compared to other major vendors. Kaspar& found ZITADEL's user registration and management process much easier to handle, and they value the security aspects provided by the platform. 

Kaspar&'s native mobile app for customers applies the OpenID Connect (OIDC) flow with Authorization Code Grant and Proof Key for Code Exchange (PKCE) to securely authenticate users and provide access to its wealth management services. The app initiates the authorization request by opening the system browser with a URL pointing to ZITADEL’s authorization endpoint, including parameters such as client ID, redirect URI, code challenge, etc. Users then authenticate within the system browser using their credentials (the user ID is the phone number), which is accompanied by multi-factor authentication for added security. Upon successful authentication, ZITADEL sends an authorization code to the app via a custom scheme or universal links/app links for iOS and Android, respectively. The app exchanges the authorization code along with the code verifier for an ID token and access token by making a request to ZITADEL's token endpoint.The ID token contains user information, while the access token enables the app to access protected resources, such as APIs. With a valid access token, the authenticated user can set up investment goals, choose investment strategies, and track their portfolio performance within the Kaspar& mobile app.

<figure>
  <img
    src="/blog/2023-04-20-success-story-kaspar&-01.png"
    width="100%"
    alt="Kaspar& Diagram 1"
  />
  <figcaption>
    Figure 1: OIDC Flow with Authorization Code Grant and PKCE for Kaspar& Mobile App
  </figcaption>
</figure>

### Addressing Internal Access Management Needs

ZITADEL is also used internally throughout Kaspar&, mainly for integration into internal applications for single sign-on. They use features such as team pass keys. Passkeys eliminate the need for users to remember and enter passwords. By leveraging passkeys for passwordless authentication, Kaspar& can improve security and provide a more seamless login experience for their internal users as the passkey can be securely delivered and used only once, reducing the risk of unauthorized access. 
Kaspar& currently utilizes ZITADEL's managed cloud solution for their infrastructure, dividing their setup into three environments: production, development, and internal. They separated their cloud instance into projects to map their environments, with customer-facing sites for production and dev environments, and internal tools like Grafana and Admin Dashboard for the internal environment.

### Cost-effective Pricing Model 

Another reason for Kaspar& to choose ZITADEL as their IAM solution was due to its competitive pricing and compatibility with their B2C model. While they initially compared ZITADEL to other major market players, they found the per-user pricing of these alternatives to be too expensive for their customer base. ZITADEL's approach to pricing and technical capabilities aligned well with Kaspar&'s goals of reaching a mass clientele: ZITADEL's pricing is based not on a pay-per-user model but on the number of requests made. This allows ZITADEL to offer a cost-effective and scalable solution for businesses of all sizes.

## Learning Curve and Product Support 

Sebastian explained that they started using ZITADEL at its inception and that the ZITADEL team provided extensive support, helping Kaspar& successfully set up their identity infrastructure. He also mentioned that the availability of libraries and support materials has improved over time, making the integration process even smoother.

Getting accustomed to ZITADEL for Kaspar& was challenging at first because of the numerous features and possibilities it offered. However, once they had gained a better understanding of the platform, they found it to be a powerful tool for creating enterprise-grade solutions with just a few clicks.

With the release of ZITADEL 2.0, the Kaspar& team found the UX to be much more intuitive and significantly improved, making it easier to set up and configure the platform. They found the developer tutorials helpful for setting up authentication clients in NextJS and TypeScript. 

Their overall experience with ZITADEL has been positive, receiving good feedback for the new technology from their users. They appreciate the regular feature updates and ZITADEL's responsiveness to suggestions.

## Future Plans

### Expanding Authentication Options with Hardware/Device Tokens

Kaspar& has several upcoming plans to leverage ZITADEL's capabilities to enhance their offerings and provide a seamless experience for their customers. They plan to introduce hardware/device tokens as an optional opt-in feature and explore other two-factor authentication methods, such as [FIDO](https://fidoalliance.org/)-enabled credit cards and [Swiss Pass](https://www.swisspass.ch/home) cards.

### B2B User Management and Access Delegation for Kaspar& Fintech Services

In addition, as the company also began exploring Business-to-Business (B2B) solutions, they found ZITADEL's multi-tenancy features to be an added advantage. Kaspar& aims to expand their B2B offerings with ZITADEL, using ZITADEL’s built-in organization model to structure their user base and grant access to necessary projects. Their typical B2B customers are banks, and they plan to create a dedicated organization for each bank to manage their users. Here's how it could work:

1. Kaspar& sets up a project in ZITADEL with specific roles tailored to the access levels required for their fintech services.
2. They then delegate access to their fintech services to their B2B customers, such as banks, allowing these organizations to manage their own users and assign roles to them.
3. Each bank (B2B customer) can now self-assign access to their users and manage user authorizations for the Kaspar& fintech services, without Kaspar& having to build a multi-tenant user management system.
4. Users from the banks can self-register for Kaspar&'s services and manage their own profile information and authentication methods, providing a seamless user experience.

This approach reduces the burden on Kaspar& to develop a multi-tenant user management system, and enhances the overall experience for their customers.

<figure>
  <img
    src="/blog/2023-04-20-success-story-kaspar&-02.png"
    width="100%"
    alt="Kaspar& Diagram 2"
  />
  <figcaption>
    Figure 2: B2B User Management for Kaspar& with ZITADEL 
  </figcaption>
</figure>

### Federated Authentication for Seamless Bank Login Integration with Kaspar& Services

One standout feature they hope to deploy is reusing existing clients' logins from the banks to provide a smooth experience for clients through federated authentication. To achieve this, Kaspar& would need to configure a trusted Identity Provider (IdP) for each bank within the ZITADEL platform. These IdPs could be the bank's own identity management systems or popular third-party IdPs such as Google or Microsoft, depending on the bank's preference.

Once the trusted IdP is set up for a bank, users from that bank can use their existing login credentials to access Kaspar&'s services. When they log in, the user's credentials are verified by the bank's IdP, and an authentication token is issued. This token is then used by Kaspar& to grant access to the user, based on their assigned roles and permissions.

This approach not only simplifies the login process for users but also enhances security, as the bank retains control over the user's credentials, and Kaspar& does not store any sensitive information. Full integration with B2B partners will likely be completed by the end of the year, allowing bank customers to experience the new setup from start to end.



## Testimonials

<img
  src="/blog/2023-04-20-success-story-kaspar&-03.png"
  width="200px"
  alt="Portrait of Sebastian Büchler"
/>

“ZITADEL has made a significant difference for our startup, offering a cost-effective solution that aligns with our business model. The ZITADEL development team is highly responsive, regularly adding new features that make our lives easier. As we expand into the B2B market, ZITADEL's multi-tenancy features have proven to be an excellent choice for our needs. Their customer-centric approach and technical expertise set them apart from other big players in the market.“ - [Sebastian Büchler](https://www.linkedin.com/in/sebastian-b%C3%BCchler/), CTO & Co-Founder of [Kaspar&](https://www.kasparund.ch/)

By leveraging ZITADEL, Kaspar& has successfully enhanced the user experience and security for B2C customers interacting with their mobile app.

Built with ZITADEL: A Partnership in Fintech Security with Kaspar&


In response to the **increasing cybercrime rates** and inadequate private data management, the European Union (EU) adopted the **General Data Protection Regulation (GDPR) legislation**. Since the set of laws took effect in 2018, entities that offer services and collect data from users inside the EU **must comply with its guidelines to ensure a reliable means of handling their customers’ information**. With the exposure of sacred data at stake, the GDPR has been established as the strictest security law in the world, with **severe consequences of non-compliance** that can put your company's long-term viability in peril. 

Fortunately, an implemented **Identity and Access Management (IAM) solution**, such as ZITADEL, can **facilitate compliance** by consistently implementing a mechanism to control access to users’ personal data: Thus, it can **reduce the likelihood of cyber-attacks** and data exploitation and simultaneously assist in avoiding expensive GDPR violations.

This article discusses the role of identity vendors in becoming GDPR compliant and the responsibilities of data processors and controllers.

## Who does GDPR apply to?

Before we dive into what it takes to become GDPR compliant, it is crucial to **establish if your organization is even subject to this legislation**. For instance, you must be excluded from these regulations if your company is headquartered outside of the European Union and caters mostly to non-European customers, right? Not necessarily.

The GDPR applies **based on the location of the individuals whose data is being processed** and not the location of the firm itself or its customer-base. Accordingly, any business that offers goods to or **tracks personal data of individuals situated in the EU** would automatically be subject to the regulations: including small-businesses, commercial enterprises, nonprofits, and governmental bodies.

However, according to the European Commission, **"if processing personal data isn’t a core part of your business** and your activity doesn't create risks for individuals, then **some obligations of the GDPR will not apply to you** (for example the appointment of a Data Protection Officer ('DPO'))".

If the aforementioned criteria confirm that your business is covered by the GDPR, follow along to learn how to facilitate compliance with the help of an authentication solution.

## Does implementing identity & access management make me automatically GDPR compliant?

Short answer: **No**. While an identity vendor serves as a significant stepping stone on your journey to compliance, it is ultimately only a part of the solution: As the data controller, **you are still the entity responsible for the safety of your users’ data**. Whereas this responsibility includes consciously choosing an identity solution that meets compliance requirements, you are nevertheless obligated to ensure that **your own platform’s policies and functionalities are up to the standards of the GDPR** as well.

“So, what else do I have to do to make my application compliant?” - Evidently, maintaining oversight of what your and your IAM’s responsibilities entail isn't always easy. To lend you a hand, the subsequent chapters **elaborate on the different tasks of the data controller and data processor**, respectively.

## The Liabilities of the Data Processor

As the name suggests, your identity vendor is mainly responsible for processing sensitive data about your users’ identities. However, this seemingly simple main task entails a wide range of other liabilities, such as:

* Ensuring that the **processed personal data follows the privacy policy** (cf. [Privacy Policy](/docs/legal/policies/privacy-policy)) and the documented directions of the Customer.
* **Informing the Customer if they have violated the Agreement**, the GDPR, or other data protection provisions and potentially suspending the Processing until the instruction is withdrawn or confirmed.
* Ensuring that the **people authorized to process the Personal Data have committed themselves to confidentiality**.
* **Taking appropriate technical and organizational security measures**, maintaining them for the duration of the Processing and updating them on an ongoing basis in accordance with the current state of technology.
* Having the right to **involve additional declared sub-processors** subjected to the same data protection obligations. The Customer has the right to object to such changes and seek a mutual agreement with the processor.
* **Supporting the Customer as far as possible with suitable technical and organizational measures** in fulfilling its obligation to respond to requests to exercise the data subject's rights.
* **Assisting the Customer in complying with its obligations** in connection with the security of the processing, any notifications of personal data breaches, and any data protection impact assessments.
* **Deleting personal data received after the end of the agreement** upon the Customer's request unless there is a legal obligation for the Processor to store or further process such data.
* **Providing the Customer with all information necessary to demonstrate compliance**. It shall enable and contribute to audits, including inspections, carried out by the Customer or an auditor appointed by the Customer.

## The Liabilities of the Data Controller

To make sure that not just your identity provider but also your application itself is GDPR compliant, you, as data controller, also bear some notable responsibilities:

* **Ensuring your vendors, including your identity provider, are fully GDPR compliant** accounting for the transborder data flows.
* Controlling and **notifying end-users on consent and withdrawal of consent**
* Determining **what data you wish to expose to your IAM**
* Ensuring that the **end-users fulfill the requirements** for signing up
* Providing their end users with the **ability to retrieve, review, correct, or remove (delete) their personal information**
* **Answering end users’ privacy-related requests** and communications from the European Union Data Privacy Authorities
* **Notifying end-users about data breaches**

An easy way to **evaluate your current compliance status** and detect any problematic data management procedures is by using the **official [GDPR-Checklist for data controllers.](https://gdpr.eu/checklist/)**

## In Conclusion

Organizations that **collect, process, or store data of EU citizens are obligated to comply with GDPR**. Most of the personal identifiable information is closely **linked to your users’ digital identity**. Safeguarding access to this highly sensitive data and lifecycling the information according to the regulations is a challenging task. Turnkey identity solutions like **ZITADEL** can help you ease the work that has to be done on your side to **protect personal information, manage access, and stay compliant to regulations**.

As a Swiss authentication vendor, **ZITADEL is completely compliant with GDPR standards** and provides the same degree of data security as the EU. The platform’s **Data Processing Agreement** handles obligations to process personal information as well as consumer demands regarding their privacy rights. Furthermore, this IAM aids compliance by **centralizing all information related to digital identities and permissions** and providing you with an audit record of every interaction with the system.

When deciding how to operate your ZITADEL instance, you have the option to **self-host ZITADEL to reduce the number of sub-processors** and the associated supply chain risk. Alternatively, you can choose to rely on the **state-of-the-art operational security in our cloud service** to keep your end-user data safe. 

**[Click here](/gdpr) to learn more about how ZITADEL can help your company with GDPR compliance.**


This article discusses the role of identity (IAM) vendors in becoming GDPR compliant and the responsibilities of data processors and controllers.

Why an Authentication Solution Is Crucial for GDPR Compliance


## Initial Position
From user feedback and our own observation, we got quite a few hints that instance owners get lost after their initial onboarding with what to do next. So we knew that we had to do something about it. Our first thought was an informational email with further instructions and provided links, but it was clear to us that this wasn’t a proper solution and was a bit outdated. So we thought of a more direct “in-app” approach that is more interactive.

## What We Wanted to Improve
After some research, we came to the conclusion that the home page in the console is where most of our customers “get stranded” and that provides the most visibility to our new guiding. We want to give the user some guidance on what could be helpful to set up next and what is missing for a successful authentication experience. We want the instance owner to feel more engaged in the setup process.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-01.png"
    width="100%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 1 - Our old start page with the focus on customizable general shortcuts and some helpful links like docs</figcaption>
</figure>


## Our New Approach
To achieve this new interactive setup for our customers, we thought of a small “to-do list” with some gentle gamification to keep them engaged. And we wanted the home page of the console to focus on these next steps rather than the general shortcuts the old page had.

So we added a progress bar that is prominently visible on the start page so the instance owner can see how far in they are with the setup. This progress bar will also show in a smaller form in the header at all times. When the setup is complete (as far as the guidance goes) this progress bar will be removed.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-02.png"
    width="50%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 2 - Progress bar as shown on the home page of the console</figcaption>
</figure>


These steps in the progress bar are shown on the start page as cards, declaring each step and with a short description of what it is about. Steps that are already done will be faded out and checked so the user can see at first glance which steps are done and which are still to do.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-03.png"
    width="50%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 3 - Progress steps cards as shown on the start page</figcaption>
</figure>


Furthermore, by hovering over the small progress bar, the user can instantly overview this list in a more compact form anywhere in the ZITADEL console with direct links to the according subpage for the task. Here the user can also opt out of this guidance if they don’t want that additional information.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-04.png"
    width="40%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 4 - The overview panel is accessible from the small progress bar in the header bar, including an opt-out option</figcaption>
</figure>


This all results in the new start page that looks like this: 

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-05.png"
    width="100%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 5 - The new and improved home page of ZITADEL console</figcaption>
</figure>


You can see that we still provide the help links but put them a bit further down the list. Note that once the progress is completed, the progress steps will convert to normal shortcuts and provide the user with direct links to the most used pages.

## Conclusion
With these changes, we hope to provide a smoother setup process, especially for new customers. But this should also come in handy for our more veteran ZITADEL users, as it gives them a handy checklist for what they might haven’t set up yet. 

We are constantly trying to enhance the user experience and if you have any suggestions on how to improve our workflow or ZITADEL in general, feel free to let us know.


This post explains what's new in ZITADEL's user onboarding process.

Blog.