
<img
    src="/blog/2023-10-24-success-story-23-technologies-03.jpg"
    width="100%"
    alt="23 Technologies Image"
    style={{ margin: '0 auto' }}
  />

## Key Outcomes

- **Centralized Authentication Solution**: [23 Technologies](https://23technologies.cloud/en) successfully partnered with ZITADEL to centralize their fragmented authentication mechanisms across multiple services. By using ZITADEL as their primary Identity Provider (IdP), they achieved a cohesive user management system, eliminating complexities from multiple infrastructures.

- **Efficient Organizational Management**: With ZITADEL's robust organizational and instance structures, 23 Technologies can now effectively manage their organizational hierarchy through a single ZITADEL instance. This enhancement offers partners and customers seamless onboarding, streamlined role allocation, and the ability to deploy services efficiently.

- **Streamlined Deployment on Kubernetes**: ZITADEL's use of Helm charts greatly benefited 23 Technologies, simplifying their deployment process. As a result, 23 Technologies could seamlessly run ZITADEL on their Kubernetes clusters, further integrating their Managed Kubernetes offering.


## Introduction 

We spoke to Christian Berendt, CEO of [23 Technologies](https://23technologies.cloud/en), a company that offers a service for Managed Kubernetes and was founded in late 2020. 

They initially adopted [Gardener](https://gardener.cloud/), an open-source Managed [Kubernetes](https://kubernetes.io/)-as-a-Service solution developed by [SAP](https://www.sap.com/) in Germany. However, Christian noted challenges with Gardener, especially in its deployment framework. To address this, 23 Technologies developed their own solution based on the open-source project. The outcome is an enterprise-grade Kubernetes engine called 23KE for industrial use and for the use of Cloud Service Providers (CSPs) and Managed Service Providers (MSPs). It prioritizes scalability, reliability, and the self-repair of Kubernetes clusters without unnecessary bloatware. 

Christian clarified their position in the market: they don’t sell only infrastructure. Instead, they act as a middleware layer for both managed and cloud services targeting independent software vendors, large enterprises, and the Industrial Internet of Things (IIoT) world. Their Kubernetes engine caters to industrial applications and other Cloud Service Providers (CSPs) and Managed Service Providers (MSPs) (such as platform services like [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/), and industrial services like [CODESYS](https://www.codesys.com/) and [OpenPLC](https://autonomylogic.com/)), with a focus on scalability, reliability, and self-healing of Kubernetes clusters. Their primary offering is Kubernetes Clusters as a Service.

Christian discusses the shift in Europe from major cloud providers (often referred to as "scalers") to regional cloud infrastructures. European customers are increasingly interested in using regional cloud services, like [OVHcloud](https://www.ovhcloud.com/en/), [IONOS](https://www.ionos.com/), and [Deutsche Telekom](https://www.telekom.com/en). However, many of these regional cloud services in Europe are smaller and often lack the same reach as the major scalers. For instance, a European cloud provider might not have resources in Asia, which could be a problem if one wants to deploy services worldwide.

23 Technologies addresses these challenges by providing a middleware layer for cloud services. Instead of relying on the infrastructure provided by regional providers, they establish a Managed Kubernetes layer. This allows them to deploy Kubernetes on any cloud infrastructure, be it [AWS](https://aws.amazon.com/), [Azure](https://azure.microsoft.com/), OVHcloud, IONOS, and so on. Their solution offers customers the flexibility of choosing from various cloud infrastructures via the service. 

### The User Journey

- **For Partners**: Upon registration, service providers undergo an onboarding process and are categorized based on partnership tiers. Once integrated, they possess the capabilities to manage their client base, allocate roles, and roll out services on their behalf.
- **For Users**: Users can sign in to a dashboard, enabling them to tap into the services they're permitted to use, navigate links to their respective services, or put forth requests for new ones.

### 23 Technologies' Value Proposition

- 23 Technologies simplifies the cloud infrastructure, requiring customers to have just one contract with 23 Technologies to access any cloud infrastructure.
- Through their service, businesses can deploy services globally without being limited to a specific cloud provider.
- Their service is tailored to regional requirements. For example, if a service needs to be run in Sri Lanka, 23 Technologies can set up a Kubernetes cluster in that region and deploy the requested service.

## Problem and Solution

### The Problem: Fragmented Authentication

23 Technologies operates as a middleware layer between a variety of cloud infrastructures and their clients. As they integrated multiple external services, such as cloud solutions, IIoT platforms, and software services, a significant challenge arose: each of these services had its own separate authentication mechanism. This resulted in:

- **Complicated Onboarding/Offboarding**: Each service's unique authentication required distinct setup and teardown procedures.
- **Disjointed User Experience**: Users had to juggle multiple identity management platforms, causing confusion and inefficiencies.
- **Security Concerns**: Managing multiple authentication systems can lead to vulnerabilities if not maintained with precision.

In essence, there was a clear need for a centralized identity provider that could simplify the identity management process for all integrated services.

### The Solution: A Centralized, User-Friendly and Cloud Native Identity Platform

To address the fragmented authentication issue, 23 Technologies was looking for a solution that:

1. **Centralizes Authentication**: A singular system where all integrated services trust one primary IdP for authenticating users.
2. **Enhances User Experience**: A unified system reduces the confusion of multiple logins and creates a smoother user experience.
3. **Boosts Security**: One integrated solution is easier to monitor, update, and secure.

After evaluating several platforms, including [Keycloak](https://www.keycloak.org/), [Authentik](https://goauthentik.io/), and [ZITADEL](https://zitadel.com/), they ultimately chose ZITADEL.

With ZITADEL, 23 Technologies introduced a centralized ID service for their service. This service aims to provide a European-centric authentication system comparable to the widespread logins offered by platforms like Google, Github, Facebook, or Instagram, tailored specifically for B2B and IIoT needs.
Key features from ZITADEL that 23 Technologies utilizes include the:

- **Distinct Hierarchical Architecture for User Management** -  [Instance and Organization Structures](https://zitadel.com/docs/guides/manage/console/organizations) in ZITADEL allow them to efficiently manage their organizational hierarchy with a singular ZITADEL instance. 

- **User-friendly Self-Service**: ZITADEL offers an intuitive self-service option, allowing users and organizations to manage their profiles, preferences, and security settings without requiring administrative intervention. This directly streamlines user management.
  
- **Efficient OIDC Workflows**: OpenID Connect (OIDC) is a modern authentication protocol that allows centralized authentication. ZITADEL's efficient handling of OIDC aids in providing cohesive identity and access management, linking all services under a unified system.


The decision to integrate ZITADEL was also influenced by the following factors:
  
- **No Feature Bloat**: While many platforms offer an array of features, not all are essential for every organization. ZITADEL's focus on providing just the necessary features (without unnecessary add-ons) ensures that the system remains efficient and user-friendly.

- **Responsiveness of Support**: Effective support is paramount, especially when integrating crucial systems like authentication. The ZITADEL team's responsiveness ensured that any challenges faced during integration were swiftly addressed.


## Technology Architecture and Deployment

<figure>
  <img
    src="/blog/2023-10-24-success-story-23-technologies-01.png"
    width="75%"
    alt="23 Technologies Diagram 1"
    style={{ margin: '0 auto' }}
  />
  <figcaption>
    Figure 1 - ZITADEL Integration: Centralizing Authentication in a Multi-Service Cloud Environment
  </figcaption>
</figure>


**Base Layer**:
The foundational infrastructure is primarily built on cloud technology, with OpenStack being the principal component.

**Kubernetes Management**:
23 Technologies utilizes Gardener for Kubernetes management. Additionally, they have developed their own tool named [23 KE](https://23ke.cloud/) to facilitate the deployment and oversight of Kubernetes across multiple cloud providers.

**User Management and Authentication**:
ZITADEL provides 23 Technologies with a centralized system for user management, ensuring organized and efficient handling of user data. It offers authentication mechanisms, such as multi-factor authentication and single sign-on, ensuring users securely access the system. Beyond authentication, ZITADEL aids in authorization, defining user roles, granting permissions, and maintaining access controls. Various services work harmoniously with ZITADEL's authentication and authorization protocols, maintaining consistent and secure user credentials and permissions across the platform.

**Deployment Preferences**:
Instead of using ZITADEL Cloud, 23 Technologies has chosen to host ZITADEL as an independent service. With an emphasis on security and reliability, they store user identities on a trusted cloud provider based in Germany. Aligning with their inclination towards open-source solutions, they have deployed the open-source variant of ZITADEL, utilizing [Helm charts provided by ZITADEL](https://zitadel.com/docs/self-hosting/deploy/kubernetes) and leveraging a Cockroach database for backend operations.

## Learning Curve and Product Support

While the solution has largely been efficient, Christian's team did face some challenges initially, particularly concerning version upgrades and the integration of the database layer for which they used CockroachDB. However, these issues were subsequently addressed, and the overall experience with ZITADEL has been straightforward. Christian praised the ZITADEL team for their responsiveness, both at the management level and in technical support.

## Future Plans

### In General

The service platform, currently geared towards German-speaking regions, offers deployment for various platform services like [Harbor](https://www.harbornetworks.com/harbor-cloud), [Grafana](https://grafana.com/), and [Prometheus](https://prometheus.io/). They intend for other CSPs and MSPs to be able to integrate their solutions into the 23 Technologies solution.

Future provisions will allow customers to operate their Kubernetes cluster, integrate it with the 23 Technologies service, and deploy services on top of their clusters, adhering to a "bring-your-own-device" philosophy.

While their initial focus is on Germany, they have plans to expand to the DACH region (Germany, Austria, Switzerland), then to the rest of Europe, and eventually to a global audience. They are open to serving any region based on demand.

### Integrating ZITADEL within the Gaia-X Narrative

23 Technologies aims to integrate ZITADEL as a centralized authentication service, especially in the context of the [Gaia-X initiative](https://gaia-x.eu/) in Europe. Their vision is for users to have a unified ID, similar to a Github login, to access multiple online platforms, thereby removing the hassle of creating multiple accounts and repeated registrations.
Gaia-X is a European strategy to boost investment in the regional cloud market. Its primary objective is to set up a standardized data ecosystem that promotes smooth data exchanges between entities, such as car manufacturers and their vehicles. One key aspect of Gaia-X is the federation service, which prioritizes self-sovereign identities. The ultimate aim is to build trust in digital identities, ensuring genuine online verification of a company or its personnel.
While the details are still being refined, 23 Technologies has plans to weave ZITADEL into the Gaia-X story. Being associated with Gaia-X and other European projects like [Catena-X](https://catena-x.net/en/) and [Manufacturing-X](https://www.plattform-i40.de/IP/Navigation/EN/Manufacturing-X/Manufacturing-X.html) offers them a chance to better access European opportunities.

## Testimonials

<img
  src="/blog/2023-10-24-success-story-23-technologies-02.jpeg"
  width="250px"
  alt="Portrait of Christian Berendt"
/>

“What I appreciate most about ZITADEL is the responsiveness and supportiveness of the ZITADEL team. Beyond the product itself, the team and community around it play a crucial role in our satisfaction. We value the open communication lines, especially through platforms like Discord.”

-[Christian Berendt](https://www.linkedin.com/in/christian-berendt-364a01203/), CEO, [23 Technologies GmbH](https://23technologies.cloud/en)


Dive into 23 Technologies' journey of creating a unified user experience in their cloud services with ZITADEL.

Built with ZITADEL: 23 Technologies' Kubernetes-as-a-Service

With PBKDF2 support now available, transitioning your users from Keycloak to ZITADEL has become smoother than ever. Dive into this tutorial to master the migration process.

Migrate Users from Keycloak to ZITADEL


## Introduction

At its heart, the Device Authorization Flow or OAuth 2.0 Device Authorization Grant is an OAuth 2.0 extension (defined in [RFC 8628](https://tools.ietf.org/html/rfc8628)), designed for devices that either lack a keyboard or have limited input capability. This extension enables applications (OAuth clients) on such devices to obtain user authorization by using a browser on a separate device, such as a smartphone.
For this flow to work, the device needs to be: 
- connected to the Internet
- able to make outbound HTTP requests
- able to display a URI and a code sequence to the user

Of course, the user must also possess a secondary device (e.g., a computer or smartphone) from which they can process the request.


## Practical Uses of the Device Flow: From Your TV to Your Fridge

Have you tried setting up your Spotify account on a smart TV or perhaps a gaming console, such as Xbox? Switching between letters, numbers, and symbols on an on-screen keyboard can be frustrating, particularly if your credentials include a mix of uppercase, lowercase, numbers, and symbols, and also because they are required to be of a certain length. So, instead of the painstaking task of typing out a password using clunky controls, you are presented with a code and told to enter it on Spotify’s website via another device. That smooth process is the device flow—born out of the need to simplify logins on gadgets without easy typing capabilities.
While many of us use the device flow with familiar services like Spotify, it's also working behind the scenes in modern devices. For instance, have you come across high-end fridges that display recipes or weather updates? What about the latest vehicles that come with sophisticated touchscreen displays that offer a variety of apps and services? Imagine trying to input login details without a tangible or virtual keyboard in sight with Wearable Tech like Smart Glasses or VR Headsets. Sounds tricky, right? They all can benefit from the device flow. 


<figure style={{ textAlign: 'center' }}>
  <img
    src="/blog/2023-09-22-device-authorization-01.png"
    width="100%"
    alt="Diagram 1"
    style={{ margin: '0 auto' }}
  />
  <figcaption>
    Figure 1 - User Experience of the Device Authorization Flow in [Spotify](https://support.spotify.com/us/article/spotify-on-tv/)
  </figcaption>
</figure>


For IoT app developers, this flow is golden. It is especially handy for those crafting apps for devices where traditional login methods would be, well, a nightmare. The flow ensures that the users are getting connected without a hitch, whether they are watching, gaming, or even cooking!
Here is a simplified breakdown of the flow from the perspective of the user:
- **Initiation**: You request access to an app or service on a device, say, a smart TV.
- **Code Display**: Instead of the familiar username/password prompt, the device displays a user code and provides a verification URL. This verification URL is your portal to authenticate. How you see this – be it text or a QR code – depends on your device.
- **User Verification**: Using a secondary device, like your smartphone, you visit the verification URL, enter the code, and then log in as you normally would.
- **Grant Access**: Once you are verified, you are granted access to the service via the input-constrained device, e.g., the smart TV. 
This might sound like a handful of steps, but in real-time, the flow is swift and intuitive, thanks to the backbone of the process: the Identity Provider.


## Why Incorporate Device Authorization Flow into your IoT Apps? 

Choosing the OAuth 2.0 device flow over conventional on-device logins has its perks:
Users will no longer fumble with tricky on-screen keyboards
Users can follow their usual login methods—they can also utilize saved passwords or password managers.
Users can use advanced authentication methods as usual, like WebAuthN.
Overall, it is safer for the users, especially when they are unsure about the device's security. For example, if the user wants to use a smart TV in a hotel, the device flow ensures they never input actual credentials into the unknown device. They just log into the service, e.g., Netflix, on their smartphone, and the TV gets a special token. They can revoke that device's access from their Netflix account once they check out.


## Enforce Device Authorization Flow Using an Identity Provider

In the simplest terms, an Identity Provider(IdP) is a system that authenticates users, essentially confirming, "Yes, this person is who they say they are." The IdP is the trusted entity that verifies user identities and dishes out tokens that apps or services can use to confirm a user's authenticity. In our Device Authorization scenarios, the IdP is instrumental in verifying the identity of the person scanning that QR code on their TV, car touchscreen, or VR headset.

**The Role of Identity Providers in the Flow:**

1. **Identity Verification**: When you scan that QR code with your phone, the request is forwarded to the Identity Provider. The IdP validates your credentials when you log in through the verification URL via the secondary device (e.g., your smartphone). It ensures that the person trying to gain access is indeed the rightful account holder.
2. **Token Generation**: Once you've authenticated yourself on the secondary device, the IdP generates an access token, which the TV or other input-constrained device obtains. This token gives that device the okay to access the desired service.


### Why use an Identity Provider for Device Authorization?

Standards-compliant IdPs support the OAuth 2.0 Device Authorization Grant, ensuring a universal, streamlined process across devices and platforms. For developers, incorporating the Device Authorization Flow becomes much simpler with an IdP in the mix. Instead of wrangling with the intricacies of user authentication and token management, developers can leverage the robust frameworks provided by IdPs. 

<figure style={{ textAlign: 'center' }}>
  <img
    src="/blog/2023-09-22-device-authorization-02.png"
    width="150%"
    alt="Diagram 2"
    style={{ margin: '0 auto' }}
  />
  <figcaption>
    Figure 2 - The OAuth 2.0 Device Authorization Flow with an IdP
  </figcaption>
</figure>


### Try out the Device Authorization Flow with ZITADEL 

For example, ZITADEL is an Identity and Access Management solution, which offers a SaaS and is also open source if you want to self-host and need more flexibility. It supports both B2C and B2B scenarios. You can authenticate users and authorize your application to access their protected resources on their behalf on ZITADEL with OAuth2/OpenId Connect(OIDC). ZITADEL supports the OAuth 2.0 Device Authorization Grant, and you can try out the Device Authorization Flow in ZITADEL through this [example](https://zitadel.com/docs/guides/integrate/login/oidc/device-authorization). 
You can also read this [post](/blog/secure-logins-with-zitadel-part-1) on the other OAuth2/OIDC grant types that ZITADEL supports, how it supports them, and recommendations depending on the application type. 


## Closing Remarks

As we venture further into a world brimming with diverse smart devices, ensuring seamless and secure access across different devices becomes crucial. The Device Authorization Flow is proving to be an effective bridge, making our digital experiences more fluid, regardless of the gadget in use.
Using an OAuth-2.0-compliant Identity Provider ensures this process is seamless and ironclad. For application developers, the IdP is not just a convenience. Instead of building a complex identity verification system from scratch, developers can lean on trusted Identity Providers to ensure top-notch security, compliance with privacy regulations, and a seamless user experience, all while saving time and resources.





Delve into the transformative power of the OAuth 2.0 Device Authorization Flow, enabling seamless logins across smart devices. Learn how standards-compliant Identity Providers are anchoring this wave of secure, user-friendly authentication.

Evolving IoT Security: From Traditional Logins to Device Authorization Flow


As digital threats and cyberattacks continue to evolve at an alarming rate, the need for robust and reliable security measures has never been more prevalent. Traditional methods of authentication, such as passwords and even multi-factor authentication (MFA), have demonstrated vulnerabilities that attackers exploit to gain unauthorized access to user accounts and personal data. However, a new authentication method has emerged that has successfully eliminated the greatest attack vector by rendering passwords completely obsolete  – FIDO2 passkeys.

This article explores all the reasons FIDO2 passkeys surpass passwords and MFA in terms of security.

## What are FIDO2 Passkeys?

FIDO2 (aka FIDO 2.0) is the latest set of specifications of FIDO (Fast Identity Online), a set of open protocols based on public key cryptography. FIDO2 combines the W3C Web Authentication (WebAuthn) specification and accompanying Client-to-Authenticator Protocols (CTAP) with the pursuit of eliminating password usage over the internet.

This innovative collaboration allowed the introduction of Passkeys - passwordless credentials that let users access their FIDO sign-in information across multiple devices, including new ones, without needing to enroll each device separately for every account. 

Unlike Multi-Factor Authentication (MFA) and Two-Factor Authentication (2FA), passwordless systems do not require users to provide an additional knowledge factor (such as passwords or PIN codes) to confirm their identity: The login process relies solely on possession factors, such as embedded (f.e. biometric authentication or PINs) or external authenticators (f.e. physical security keys, mobile devices, wearables, etc.). 

To summarize, FIDO2 passkeys enable users to log into a platform only using a passwordless credential (such as FaceID or a physical token) of their choice and sync their FIDO private keys across multiple devices. 

<figure style={{ textAlign: 'center' }}>
  <img
    src="/blog/2023-09-07-passkeys-mfa-passwords-01.png"
    width="500"
    alt="Diagram 1"
    style={{ margin: '0 auto' }}
  />
  <figcaption>
    Figure 1 - Using passkeys in ZITADEL
  </figcaption>
</figure>

## Why are Passkeys Safer than Passwords and MFA?

Ever since their release, there have been some misconceptions and mistrust circulating around passkeys: Are they really as safe as they claim to be if PIN codes can be cracked and physical tokens stolen? 

The following sections aim to debunk these misconceptions and explain why FIDO2 passkeys are the more secure and convenient alternative to 2FA, MFA, and password-based authentication.

### Elimination of Passwords

One of the key reasons why FIDO2 passkeys are significantly safer than MFA is due to their complete waiver of passwords. 

Although passwords have been the industry standard for decades, they have proven to be highly susceptible to various attack vectors due to several inherent flaws. Since they are knowledge factors that require easy recallability, many of them subsequently end up being easy to guess and are reused across multiple accounts. These simple passwords can be easily exploited by attackers, using techniques such as brute-forcing, social engineering, and phishing. 

Passkeys, on the other hand, are a possession-based authentication method that employs advanced cryptography. Rather than depending on a human-readable secret, it replaces the password with a non-phishable primary factor for user authentication that is integrated into practically every computing device we use today. Thus, it makes cyberattacks practically unfeasible.

### Phishing Resistance

While MFA adds an extra layer of security by requiring at least two authentication factors to gain access to an account, it is still not completely foolproof. There are various 2FA bypass attacks that can be employed to compromise both authentication factors and without the user’s knowledge: For instance, users can be subjected to social engineering by giving away their credentials or manipulated to do so by falling for MFA-Fatigue attacks. 

One of the most commonly used 2FA bypass attacks is the Man-in-the-Middle (MITM) attack. This infamous phishing technique allows attackers to gain unauthorized access to an account without even knowing the victim’s login credentials by having a third party intercept the communication between two systems. A popular tool to conduct MiTM attacks is a phishing website: A fraudulent duplicate of a legitimate login page that tricks users into placing their credentials and second authentication factors directly into the attackers’ hands.

Fortunately, these attacks can be mitigated entirely with the help of FIDO2’s use of cryptography keys and challenges. FIDO2 uses two types of keys - a public key and a private key. The public key is linked to the domain of the service, while the private key is safely stored on the user's synced devices. Once you initiate a login to a platform that uses FIDO2, the server sends a challenge to your device. The private key is then used by your browser to provide a unique response to the challenge, which the server validates using the associated public key that is linked to it. If your response does not match the challenge, the login is unsuccessful. Thus, FIDO2 prevents users from authenticating on an illegitimate application or website.

### Secure Storage

When we talk about the weaknesses of authentication methods involving passwords, guessability, and excessive reuse are the main flaws that tend to come to mind. However, one significant shortcoming is often forgotten: The storage of passwords in an often vulnerable, centralized database. 

Within the framework of password-based authentication, the system is designed to compare offered credentials to the comprehensive collection of user passwords stored in a database. Needless to say, if this database is breached, attackers can retrieve all of the stored credentials and user data. While password hashing and salt can enhance the security of databases by converting plain text passwords into a random string of characters, that technique is ultimately still vulnerable to many attacks and might lead to follow-up attacks putting sensitive information at risk. 

FIDO2 passkeys use public-key cryptography, which provides a higher level of security compared to centralized password databases. The private key never leaves the user's device, making it nearly impossible for attackers to steal or intercept it. Even if an attacker manages to access the passkey on one device, they cannot use it to access the account on another (unauthorized) one. Thus, there is no need for concern regarding the mishandling of your passkey secret by a website or that your passkey could be used to access another service.

### Multi-device Authentication

In 2022, the FIDO alliance introduced a significant new development of the standard, which aimed to improve the usability and deployability of the FIDO-based authentication mechanism: Multi-device FIDO credentials. With the help of this upgrade, users who had set up multiple FIDO credentials for different relying parties on a device that they don’t use anymore can easily access all those credentials on a new device. The underlying OS platform "syncs" the cryptographic keys associated with a FIDO credential from device to device. Thus, this innovation mitigates the risk of losing access to your credentials due to device loss. 

### Bonus: Better User Experience (UX)

Passkeys eliminate the need to remember and repetitively enter complex passwords to access your accounts. These accounts can also be easily accessed from different devices without compromising security. Moreover, signing in with passkeys only requires a single authentication factor, making the login process faster and smoother than MFA. These advantages are especially helpful in scenarios where speed is crucial, such as making online payments. 

<a href="https://www.youtube.com/watch?v=XaPPGrxfwhQ&list=PLTDa7jTlOyRLdABgD2zL0LGM7rx5GZ1IR" target="_blank">
 <img src="/blog/2023-09-07-passkeys-mfa-passwords-02.png" alt="Watch the video" width="1200" height="600" border="10" />
</a>

## 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 they choose FIDO U2F tokens or FIDO2 Passkeys over MFA as their preferred authentication method.
[Learn more about ZITADEL’s authentication methods](https://zitadel.com/blog/authentication-methods)



This article explores the reasons why FIDO2 passkeys surpass passwords and MFA in terms of security.

Why FIDO2 Passkeys are Safer than MFA and Passwords

Using ZITADEL's OIDC integrations as a guide, this article offers insights into mastering the essential security measures of session timeouts, logouts, and token expriy.

Navigating Session Logouts, Timeouts, and Token Expiry


## Key Outcomes

- [Orbica](https://www.orbica.com/), headquartered in Christchurch, New Zealand, is a company that specializes in the field of geospatial technology. They have recently launched a cloud platform, a geospatial powerhouse that simplifies the complexities of large-scale data analysis for its users and have chosen to use [ZITADEL Cloud](https://zitadel.com/) for managing the identity and access needs of their customers.
- With ZITADEL, Orbica has effectively improved both the user experience and security measures of its customers using the Orbica Geospatial Platform. Orbica estimates to have saved themselves at least 1-2 months of UX and development time, in addition to mitigating the risk of constructing and hosting their own solution incorrectly.
- ZITADEL's compliance with the General Data Protection Regulation (GDPR) primes Orbica for future success by ensuring it meets data protection requirements. Furthermore, Orbica aims to make ZITADEL's authentication system accessible to their customers, enabling them to manage their own user authentication within applications built on the Orbica Geospatial Platform.


## Introduction

Orbica began as a professional services firm, providing geospatial applications, data products, and workloads. Over time, they identified recurring patterns in these projects, which led them to the idea of developing a platform. The intention behind this platform was to enable others to integrate the capabilities of geospatial technology into their own workflows and apps, allowing them to construct more sophisticated applications.

The Orbica Geospatial Platform is a fully managed, cloud-native platform engineered to leverage geospatial data analysis and AI knowledge to unlock insights in data assets, enabling developers to create solutions for a variety of applications. Beyond the conventional geographical information system (GIS) tools, the platform is designed for all types of users - not just GIS experts - eliminating data silos and making geospatial knowledge accessible across an organization. Through the platform, users can easily interact with and manage their geospatial data via an intuitive user interface, setting various exploration goals, choosing from different visualization methods, and monitoring their data insights.

Orbica's clientele primarily consists of businesses in various sectors that require intricate geospatial analysis to drive decision-making and uncover latent trends and patterns within their data. With a range of use cases that include urban planning, disaster response, environmental monitoring, infrastructure management, agriculture, supply chain management, and water management, Orbica's Geospatial Platform caters to a broad spectrum of industries. This makes it a go-to tool for developers aiming to make a significant impact with geospatial AI.

We spoke with [Santosh Seshadri, Head of Platform at Orbica](https://www.linkedin.com/in/santosh-seshadri-9a6b4559) to delve deeper into the technical intricacies they faced and the driving factors behind their decision to embrace ZITADEL as their identity and access infrastrucure solution. 


## Problem and Solution

Orbica's journey in the Identity and Access Management (IAM) space was not a new one. They had tried several other providers, including Microsoft’s Azure Acitve Directory and Azure Active Directory B2C. They had also used Auth0 for some projects due to client requirements. However, when the need to choose an IAM solution for their platform arose, the options were narrowed down to ZITADEL, Auth0, AWS Cognito, and Azure Active Directory. Although AWS and Microsoft were closely tied to their vendors, Orbica was seeking greater flexibility.

Their discovery of ZITADEL was a result of their ongoing exploration of new, flexible, and modular tools in the tech space, consistent with their philosophy of avoiding monolithic systems. They had been testing different options and were impressed by what ZITADEL had to offer. After a thorough investigation and evaluation of ZITADEL's APIs by their development team, they decided to onboard with ZITADEL. This choice was driven by several pain points and unique requirements, which ZITADEL managed to resolve.

Firstly, the organizational and project-based hierarchy presented by ZITADEL resonated perfectly with Orbica's schema level because the Orbica Geospatial Platform was designed around a hierarchical structure of organizations, workspaces, and projects. ZITADEL's ability to provide fine-grained, role-based access control within the same hierarchical structure has been crucial to Orbica. They also appreciated the ability to have multiple instances and the flexibility and comprehensiveness of ZITADEL's metadata. 

From a commercial standpoint, the seat-based pricing model offered by most providers was a significant constraint for Orbica. In contrast, ZITADEL's pricing structure was more conducive to their needs. ZITADEL abandons the conventional per-user licensing model in favor of a consumption-based approach, making it highly suitable for organizations dealing with data and analytics. The model is based on requests rather than user count, reflecting Orbica's commitment to providing usage-based solutions. 


## The Platform’s User Journey

The Geospatical Platform's user journey begins with creating an organization for each new customer. Currently, this is done internally, but there are plans for future self-service. After sign-up, users receive an email from Orbica via ZITADEL to complete their account setup, after which they can access the platform.

Initially, the users are presented with an empty canvas. The first step involves creating a workspace defined according to the organization's needs. These workspaces can be divided as desired and further segmented into projects. Within these projects, users can set up data stores, databases with APIs, and map services. Any data with a geospatial aspect can be viewed on a map, and the platform performs this orchestration. Users can customize server resources to their liking, specifying things like database size or computing resources, and the platform provisions these resources accordingly. Users can opt for any database of their choice; however, Orbica provides spatial databases curated explicitly for advanced spatial analytics and functions as an additional service.

Next, users can add an analytics service, a Jupyter Lab implementation, which comes pre-packaged with geospatial and AI libraries and is automatically connected to the database. If the user has Python scripts or other workloads in their organization, they can bring them in too, and run them in the cloud, scaling resources as necessary. Users can tap into this feature to perform various functions immediately, right out of the box.

<figure>
  <img
    src="/blog/2023-08-22-success-story-orbica-01.png"
    width="100%"
    alt="Orbica Diagram 1"
  />
  <figcaption>
    Figure 1 - Adding an analytics service via a Jupyter Lab implementation with pre-packaged geospatial and AI libraries
  </figcaption>
</figure>

Finally, users can build their custom frontend app and host it on the platform. Currently, users can create multiple projects representing isolated environments, but in the future, they will be able to promote an existing project to a higher environment, e.g., a production environment, with different access policies to run their workloads seamlessly in their respective ecosystems.

<figure>
  <img
    src="/blog/2023-08-22-success-story-orbica-02.png"
    width="100%"
    alt="Orbica Diagram 2"
  />
  <figcaption>
    Figure 2 - An application utilizing Orbica integrating geospatial data with advanced AI capabilities
  </figcaption>
</figure>

<figure>
  <img
    src="/blog/2023-08-22-success-story-orbica-03.png"
    width="100%"
    alt="Orbica Diagram 3"
  />
  <figcaption>
    Figure 3 - Another interface powered by Orbica
  </figcaption>
</figure>


## Architecture and Deployment

Architecturally, the platform is a cloud-native solution modeled on a microservices architecture. Orbica has designed its core to be provider-agnostic; a Kubernetes layer is responsible for seamlessly orchestrating resources in AWS. Network communications between pods and clusters are maintained by a service mesh, forming a critical part of the system by handling the deployment of functions-as-a-service. These functions are directly connected to the service mesh, enabling on-demand resource deployment. A React-based user interface delivers an interactive experience to users. All the platform's operations are enabled through Orbica's SDKs. 

The platform incorporates ZITADEL Cloud, and ZITADEL's primary function within the platform is to provide robust authentication and authorization services. When onboarding a client, an organization is provisioned on the platform, which manages its workloads via workspaces and projects, where the microservices operate. A parallel organization is created on ZITADEL. Subsequent user registrations are also added to this ZITADEL organization, integrating each user into the authentication system right from the start. 

The authentication process uses OpenID Connect to validate the user's identity, using the information provided during the registration, ensuring only verified users gain access to the platform. Once users have been authenticated and are active within the platform, ZITADEL manages the authorization of these users and determines the permissions that each user has within the platform, which resources they can access, and what actions they can perform. 

As the Orbica Geospatial Platform is designed around a hierarchical structure of organizations, workspaces, and projects, [ZITADEL's ability to provide granular access control within the same hierarchical structure](https://zitadel.com/blog/multi-tenancy-with-organizations) is crucial. For instance, an administrator might be allowed to create, delete, or modify projects, while a data engineer might only have permission to view data and perform analysis. Orbica uses ZITADEL’s metadata feature to categorize their projects into workspaces – an intermediary level between organization and project – and to define respective roles within a user's metadata. They further leverage ZITADEL’s custom claims to organize this data, embedding it into JWT. This structured approach ensures they can accurately determine a user's access permissions for various workspaces.

The current hosting is in AWS's Sydney region, but they are actively developing a multi-region cluster for the platform, enabling deployment in other regions around the globe. This global vision is in alignment with Orbica's existing international footprint, with branches in Germany and Australia. 

<figure>
  <img
    src="/blog/2023-08-22-success-story-orbica-04.png"
    width="300%"
    alt="Orbica Diagram 4"
  />
  <figcaption>
    Figure 4 - How ZITADEL integrates with the Orbica Geospatial Platform
  </figcaption>
</figure>


## Learning Curve and Product Support

According to Santosh, the developer experience with ZITADEL has been highly positive. The system is user-friendly, making the integration process relatively smooth. However, there were challenges when certain key features needed for Orbica's operations were initially missing. For instance, the team sought a method to authenticate users through their own login UI and ZITADEL APIs instead of using the ZITADEL UI to log in and acquire a token. Implementing their own login UI would offer a smoother user experience and grant Orbica greater control over authentication. After discussing with the ZITADEL team, Orbica learned that the feature was already under development and has since been released. See the [Login API](https://zitadel.com/docs/guides/integrate/login-ui) for more details. 

Santosh commended ZITADEL’s customer service as they provided swift responses and communicated the progress of feature development effectively. There were slight hiccups in the initial stages regarding custom claims. While the current state of [custom claims](https://zitadel.com/blog/custom-claims) is perfectly suited to Orbica's needs, it was a feature that wasn't available during their early testing phase. 

Presently, ZITADEL is used exclusively for Orbica's Geospatial Platform. The beta process went smoothly, and the registration or login process from the user's perspective was generally positive. 


## Future Plans

The team at Orbica is interested in leveraging ZITADEL's support for the General Data Protection Regulation (GDPR). As Orbica plans to launch a European instance and cluster, [ZITADEL's GDPR compliance](https://zitadel.com/gdpr) becomes an attractive aspect as it helps them meet data protection requirements. 

A more long-term vision for the company's use of ZITADEL involves making the identity provider more accessible to their customers. The idea is to enable customers, who are already creating applications on the Orbica platform, to manage their own user authentication. The goal is to eliminate the need for customers to bring their own authentication systems for their apps. While they could still choose to do so, Orbica wants to give them the option of leveraging the existing authentication system, thus providing a more integrated and seamless experience. This would allow end users to build their applications with the reassurance of having a reliable authentication system in place. To set this plan in motion, the team at Orbica is considering the kind of support they can provide, whether it's at the technology level through the platform or through other means, such as documentation. 


## Testimonials

<img
  src="/blog/2023-08-22-success-story-orbica-05.jpg"
  width="250px"
  alt="Portrait of Santosh Seshadri"
/>

“Auth is complex and critical to get right the first time. I was relieved to discover ZITADEL, allowing us to leverage their expertise so we can focus on the rest of our platform development. ZITADEL’s consumption-based pricing model also aligns perfectly with Orbica’s, allowing us to offer our platform without restrictive per-user charges.” 

— [Santosh Seshadri](https://www.linkedin.com/in/santosh-seshadri-9a6b4559/?originalSubdomain=nz), Head of Platform at [Orbica](https://www.orbica.com/) 

Exploring how Orbica leveraged ZITADEL for exclusive authentication in its geospatial platform.

Built with ZITADEL: Orbica's Cloud Native Geospatial Platform


We decided to adopt a resource-based API for ZITADEL in response to feedback from our customers and community members.
Our overarching goal has always been to provide an exceptional experience for developers using our platform.
However, through ongoing conversations with users, we came to the understanding that while some of our architecture and design decisions were technically sound, they didn't necessarily translate into an intuitive and user-friendly experience from a developer's perspective.

Our API design was identified as one area where we could significantly enhance the developer experience.
By transitioning to a resource-based API, we are making our system more intuitive and easy to understand.
A resource-based API structure focuses on "resources" as the main entities, as opposed to methods or operations, which aligns better with the way developers think about their interactions with our platform.
We believe this change will make ZITADEL more approachable and enjoyable for developers to use.


## Persona-based API design

ZITADEL's API design is grounded in the concept of personas, each with different use cases.
The distinct APIs cater to these various personas and their specific needs, creating a more personalized and intuitive interface.
For instance, the Authentication API is designed primarily for currently authenticated users.
Therefore, if you're developing a user profile or settings page for authenticated users, the Authentication API would be your main resource. 

<figure>
  <img
    src="/blog/2023-08-03-resource-based-api-01.png"
    width="100%"
    alt="Persona-based API"
  />
  <figcaption>
    Figure 1: Persona-based API design
  </figcaption>
</figure>


Similarly, different APIs are designated for different roles.
The Management API is accessible to the administrator of an organization, while the Admin API is available for the IAM administrator.

At first glance, the division of responsibilities and access based on roles appears to make a lot of sense.
However, when we take into account how developers typically interact with our platform, potential complications become evident.
It's not uncommon for developers to dive straight into implementation without thoroughly studying the documentation. 

Let's take an example: a developer wants to create a settings page for a user and needs to retrieve the user information.
They would go to the API documentation and search for "get user".
This seemingly simple query returns multiple results, each tied to a different API and with different permissions:

- Auth API: "Get my own user"
- Management API: "Get user by ID from my organization"
- Admin API: "Get user by ID from any organization"

Without proper understanding of the differences between these APIs, developers may become confused and unsure about which option is the right one for their needs.
This is the kind of complication we aim to reduce with our new API design.

## Resource-based API design

After considering all the above factors, we have concluded that a resource-based API is significantly more straightforward to understand than a persona-based API.

By "resource-based API", we mean an API that allows access to the various resources ZITADEL provides, irrespective of the user's role or persona.
The fundamental principle here is that users access resources through a single API, and the depth or breadth of the results they see depends on the permissions of the user making the request.
This design simplifies the user's navigation through the API and makes for a more intuitive experience.


<figure>
  <img
    src="/blog/2023-08-03-resource-based-api-02.png"
    width="100%"
    alt="Resource-based API"
  />
  <figcaption>
    Figure 2: Resource-based API design
  </figcaption>
</figure>


Let's take an example of how this resource-based API design works.
Let's say we have a 'users' resource in the API.
This resource supports various operations such as create, update, delete, get by ID, and search for users.

- If I'm an end user, and I request a 'get by id' operation, the API will only permit me to retrieve my own user information, respecting the principle of least privilege.

- If I'm an administrator of an organization, I can utilize the 'search users' operation to retrieve details of all users within my organization, representing a higher level of access.

- Finally, if I'm an Identity and Access Management (IAM) administrator, I can use the 'search users' operation to access information on users across any organization in the system, reflecting the highest level of access.

This approach simplifies interactions by centralizing operations on a single resource, while still maintaining appropriate access control based on the user's role.

## Our Progress and Future Plans

We have already made considerable progress with the new API. 
All the necessary requests to construct your own login and registration UI have been implemented. 
As we continue to expand this new API, we will add new requests and gradually transition existing requests from the previous APIs (Auth, Management, Admin) to this new, resource-based API.

With the full implementation of this new API design, we are confident that we will significantly enhance the developer experience. We believe that these changes will simplify not only our customers' experience but also streamline our own operations. 
We look forward to offering a more efficient, user-friendly platform thanks to this resource-based API design.

Stay tuned for more updates! 


## Read the API Documentation

See the documentation of the currently available API resources of the new API if you want to learn more right away.

- [User](https://zitadel.com/docs/apis/resources/user_service)
- [Session](https://zitadel.com/docs/apis/resources/session_service)
- [Settings](https://zitadel.com/docs/apis/resources/settings_service)
- [OIDC](https://zitadel.com/docs/apis/resources/oidc_service)


We decided to adopt a resource-based API for ZITADEL in response to feedback from our customers and community members.

From Persona-based to Resource-based: Rethinking ZITADELs API Design


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

Blog.