Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog


ZITADEL, a leading provider of cloud-native identity and access management (IAM) solutions, has achieved ISO 27001 certification for its information security management system (ISMS). This certification demonstrates ZITADEL's deeply rooted commitment to protect the confidentiality, availability, and integrity of customer, company, and employee data.

"Obtaining the ISO 27001 certification is a testament to ZITADEL's commitment to information security," said Florian Forster, CEO of ZITADEL. "This certification demonstrates that we have the systems and processes in place to protect our customers' data."

<img src="/blog/2024-06-20-zitadel-iso-27001-certified-01.png" width="35%" align="left" alt="" class="wrap"/>

The ISO 27001 standard is a globally recognized framework for information security management. It provides a comprehensive set of requirements for establishing, implementing, operating, monitoring, reviewing, maintaining, and continually improving the security of ZITADEL.

We designed our information security management system (ISMS) to protect against a wide range of threats, including unauthorized access, data breaches, and cyberattacks. The ISMS further includes processes for managing and responding to security incidents.

"Secure development and operations practices are essential for protecting our customers' data," said Fabienne Bühler, CPO of ZITADEL. "ISO 27001 certification provides our customers with assurance that their data is safe and secure."

ZITADEL's ISO 27001 certification is a valuable asset for the company's customers. It provides customers with assurance that their data is protected by world-class processes and tools .

"Our commitment to information security and data privacy is steadfast," said Maximilian Panne, COO of ZITADEL. "ISO 27001 certification is a recognition of our efforts to protect our customers' data at ZITADEL."



You can verify the validity of our ISO certificate by visiting the [website of the British Assessment Bureau](https://cvs.babcert.com/babcert.asp?c=258048&v=3fs61l6zn6).

Visit the [Trust Center](https://trust.zitadel.com) to learn more about our commitment to information security and data protection.


ZITADEL achieved ISO 27001 certification, demonstrating its dedication to data protection and cybersecurity. This certification provides a framework for information security management, safeguarding data against unauthorized access and cyber attacks.

ZITADEL Achieves ISO 27001 Certification


## Introduction

In this post, we'll demonstrate how to leverage Postman, a great tool for API development and testing, to explore and validate the APIs provided by ZITADEL. Postman is renowned among developers and testers for its comprehensive suite of features that facilitate the building, testing, and modification of APIs. Its interface simplifies the process of sending requests and analyzing responses, making it a great tool for debugging and making sure that API functionality aligns with security and operational requirements.

The focus of this post will be on using Postman to interact with ZITADEL's APIs, which are used for tasks such as user authentication and token management. We will begin by examining the user login flow, explaining how to authenticate users on a web application and obtain access tokens. 

The objective is to provide developers with practical insights into integrating ZITADEL within their applications. By the end of this post, readers will gain an understanding of ZITADEL's capabilities by making use of the efficiency Postman brings to testing web application security.


## Set Up Postman

Getting started with Postman is straightforward, and it begins with setting up an account and familiarizing yourself with its interface and capabilities. Here's a brief guide to kickstart your journey:

Visit [Postman](https://web.postman.co/home) to create a new account or log in to an existing one. Once logged in, explore the Postman workspace. The interface is designed to be intuitive, with the primary sections being Collections, Environments, and APIs. Collections are groups of requests that can be organized and run together. To create a collection, click the **+** button under **Collections** and give it a name. This is where you'll store the requests you create to test ZITADEL's APIs.

<img src="/blog/2024-03-07-testing-login-with-postman-01.png" alt="Testing User Login Flows in ZITADEL with Postman" />

<img src="/blog/2024-03-07-testing-login-with-postman-02.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Environments in Postman allow you to use variables, making it easier to switch between different sets of data (such as API keys, tokens, and URLs) without changing your requests manually. We will not be using environments in this setup. 


## Set Up ZITADEL

To get started with setting up your environment in ZITADEL, including creating instances, projects, and human users, we recommend following the [ZITADEL's Quick Start Guide](https://zitadel.com/docs/guides/start/quickstart). 

Follow the guide to do the following tasks: 

- [Sign up for the ZITADEL Cloud customer portal and register your organization](https://zitadel.com/docs/guides/start/quickstart#1-sign-up-for-the-zitadel-cloud-customer-portal-and-register-your-organization)
- [Create your first instance](https://zitadel.com/docs/guides/start/quickstart#1-sign-up-for-the-zitadel-cloud-customer-portal-and-register-your-organization)
- [Create your first project](https://zitadel.com/docs/guides/start/quickstart#3-create-your-first-project)
- [Add a user](https://zitadel.com/docs/guides/start/quickstart#4-add-users-optional)


If you are interested in integrating these setup processes into DevOps pipelines or automating them, ZITADEL's APIs offer the flexibility to programmatically create and manage these entities. 

For detailed API references and guides on doing the above programmatically, you can take a look at  [ZITADEL's API documentation](https://zitadel.com/docs/apis/introduction), such as the [Management Service API for creating a project](https://zitadel.com/docs/apis/resources/mgmt/management-service-add-project). These resources offer in-depth insights into the specific APIs you'll need to use for each step of the setup and management process.


## Secure a Web Application: Test User Login


### Set Up a Web Application in ZITADEL

Create a Web Application in your ZITADEL project by selecting **WEB**. Click **Continue**.

<img src="/blog/2024-03-07-testing-login-with-postman-03.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Select **PKCE** and continue. 

<img src="/blog/2024-03-07-testing-login-with-postman-04.png" alt="Testing User Login Flows in ZITADEL with Postman" />

The callback URL needed for this setup is provided by the Postman UI, which is `https://oauth.pstmn.io/v1/browser-callback`. 

<img src="/blog/2024-03-07-testing-login-with-postman-05.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Add the callback URL in ZITADEL as shown below: 

<img src="/blog/2024-03-07-testing-login-with-postman-06.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Check if your application details are correct and click **Create**. 

<img src="/blog/2024-03-07-testing-login-with-postman-07.png" alt="Testing User Login Flows in ZITADEL with Postman" />

You will thereafter receive the **ClientId** for your application without the Client Secret because you don’t need it for the Authorization Code with PKCE grant type. 

<img src="/blog/2024-03-07-testing-login-with-postman-08.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Also note down the **token_endpoint**, **authorization_endpoint** and the **userinfo_endpoint**  from the **URLs** section in your application as shown below:

<img src="/blog/2024-03-07-testing-login-with-postman-09.png" alt="Testing User Login Flows in ZITADEL with Postman" />


### Test the Flow with Postman

Next, we'll walk through testing this authentication flow using Postman.


#### Retrieve the Access Token

Go to the Postman application and open the **Authorization** tab.

<img src="/blog/2024-03-07-testing-login-with-postman-10.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Select **OAuth 2.0** authorization from the drop-down.

<img src="/blog/2024-03-07-testing-login-with-postman-11.png" alt="Testing User Login Flows in ZITADEL with Postman" />

A new panel will be shown with different values. Fill up the values as shown in the image.


- Token: **Available Tokens**
- Header Profile: **Bearer**
- Token Name: *A name of your choice*
- Grant Type: **Authorization Code (With PKCE)**
- Auth URL: *ZITADEL authorization_endpoint you copied earlier*
- Access Token URL: *ZITADEL token_endpoint you copied earlier*
- Client Id: *Your app's client_id*
- Code Challenge Method: **SHA-256**
- Code Verifier: *Keep it blank or provide any string*
- Scope: **openid urn:zitadel:iam:org:project:id:zitadel:aud**
- Client Authentication: **Send as Basic Auth header**

<img src="/blog/2024-03-07-testing-login-with-postman-12.png" alt="Testing User Login Flows in ZITADEL with Postman" />

<img src="/blog/2024-03-07-testing-login-with-postman-13.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Click **Get New Access Token**. 

<img src="/blog/2024-03-07-testing-login-with-postman-14.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Now, if you haven't logged into ZITADEL yet, you'll be redirected to the ZITADEL login page. This simulates the user login experience. Here, enter your email address. 

<img src="/blog/2024-03-07-testing-login-with-postman-15.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Now enter your password.

<img src="/blog/2024-03-07-testing-login-with-postman-16.png" alt="Testing User Login Flows in ZITADEL with Postman" />

New users need to verify their email and set a new password if they haven't done so already.

If the authentication is a success, you will receive the token. Click **Proceed**.

<img src="/blog/2024-03-07-testing-login-with-postman-17.png" alt="Testing User Login Flows in ZITADEL with Postman" />


#### Use the Token

Click **Use Token** within Postman to apply this token for subsequent API calls. This token enables you to interact with your application's APIs or ZITADEL's, such as fetching user information from the userinfo endpoint.

<img src="/blog/2024-03-07-testing-login-with-postman-18.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Now (after clicking **Use Token**), enter the user_info endpoint as the request URL and set Bearer as the **Header Prefix** for authorization as shown below. Click **Send**. 

<img src="/blog/2024-03-07-testing-login-with-postman-19.png" alt="Testing User Login Flows in ZITADEL with Postman" />

The response will be as follows: 

<img src="/blog/2024-03-07-testing-login-with-postman-20.png" alt="Testing User Login Flows in ZITADEL with Postman" />

We didn’t receive user information because we did not specify sufficient scopes. Modify the scope field to include **profile** and **email**, then obtain a new access token.

<img src="/blog/2024-03-07-testing-login-with-postman-21.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Use the new access token this time. And when you send the request to the userinfo endpoint, you will see the following response. 

<img src="/blog/2024-03-07-testing-login-with-postman-22.png" alt="Testing User Login Flows in ZITADEL with Postman" />


#### View User Roles 

By default, user roles are not included in the userinfo response. To include roles, assign a role to a user. You can [add a user](https://zitadel.com/docs/guides/start/quickstart#4-add-users-optional), [add a role](https://zitadel.com/docs/guides/start/quickstart#5-add-roles-to-your-project-optional), and [add the role](https://zitadel.com/docs/guides/start/quickstart#6-add-authorizations-to-your-project) to the user by following the Quick Start Guide. 

However, to see this role information in the response, you must enable the **User roles inside ID Token** option under **Token Settings** in your web application configuration. Click **Save**.

<img src="/blog/2024-03-07-testing-login-with-postman-23.png" alt="Testing User Login Flows in ZITADEL with Postman" />

Now generate a new access token in Postman and send the request. You will now see the role information included in the response. 

<img src="/blog/2024-03-07-testing-login-with-postman-24.png" alt="Testing User Login Flows in ZITADEL with Postman" />


## Wrap-up

Postman's prowess in simplifying API testing, combined with ZITADEL's robust security features, offers a powerful duo for enhancing your web application's authentication process.

Stay tuned for the next installment in our series, where we'll dive into token introspection with ZITADEL and Postman. We'll show you how to verify token validity and understand its scopes, ensuring strong security for your API access. 

This post explains how to integrate ZITADEL's login flow into your web application, guiding you through the setup process step by step, and also how to leverage Postman to test and ensure the login flow works flawlessly.

Test User Login Flows in ZITADEL with Postman


## Introduction

In our [previous post](/blog/testing-login-with-postman), we focused on how to use Postman to test the user login process, detailing the steps for authenticating users in a web application and obtaining an access token. We also illustrated how to use this access token to access ZITADEL's userinfo endpoint, a secured endpoint that requires an access token for access. In this post, we'll guide you through the process of implementing API introspection within your API, ensuring it requires a token to respond to requests. Furthermore, we'll show you how to use Postman to call this secured API.

We can utilize the token obtained from the user login flow in the previous post. However, to guarantee that this token provides the access we require, a minor adjustment to its scopes is essential. By updating the token's scopes, we can align its permissions with the security demands of our target API, facilitating authenticated and authorized interactions. We'll delve into this aspect shortly. First, let's set up a sample API.

## Create an API

This step is optional if you already have an API to test. To create a simple API with two endpoints (a simple `GET` that doesn’t require a token, and a `GET` that checks the token by calling the ZITADEL introspection endpoint) using Node.js and Express, follow these steps. 

### Prerequisites

- Install Node.js


### Step 1: Initialize Your Node.js Project

Create a new directory for your project, initialize a Node.js application, and install the necessary packages as detailed below:

```bash
mkdir zitadel-api
cd zitadel-api
npm init -y
npm install express axios dotenv
```


### Step 2: Set Up Environment Variables

Create a `.env` file in the root of your project directory. Add your ZITADEL credentials and the introspection endpoint URL. To obtain these values, you must create an API application in ZITADEL, which will be done in the next section. 

```plaintext
ZITADEL_CLIENT_ID=<your_client_id>
ZITADEL_CLIENT_SECRET=<your_client_secret>
ZITADEL_INTROSPECTION_ENDPOINT=<https://your-zitadel-instance.com/oauth/v2/introspect>
```


### Step 3: Create the API

Create a file named `app.js` in your project directory. Open it in your text editor and add the following code:

```javascript
require('dotenv').config();
const express = require('express');
const axios = require('axios');
const app = express();

app.use(express.json());

// Simple GET endpoint
app.get('/simple-get', (req, res) => {
   res.send({ message: "This is a simple GET response." });
});

// Protected GET endpoint
app.get('/protected-get', async (req, res) => {
   const authHeader = req.headers.authorization;
   if (!authHeader) {
       return res.status(401).send({ error: "No authorization header provided" });
   }

   const token = authHeader.split(' ')[1];
   try {
       const response = await axios.post(process.env.ZITADEL_INTROSPECTION_ENDPOINT, `token=${token}`, {
           headers: {
               'Content-Type': 'application/x-www-form-urlencoded',
           },
           auth: {
               username: process.env.ZITADEL_CLIENT_ID,
               password: process.env.ZITADEL_CLIENT_SECRET,
           },
       });

       if (!response.data.active) {
           return res.status(403).send({ error: "Inactive token" });
       }

       res.send({ message: "Access to the protected resource granted." });
   } catch (error) {
       console.error("Introspection error:", error.response ? error.response.data : error.message);
       return res.status(500).send({ error: "Failed to introspect token", details: error.response ? error.response.data : error.message });
   }
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
   console.log(`Server running on port ${PORT}`);
});

```

This API features two endpoints:

1. **`/simple-get`**: A simple `GET` endpoint that responds with a basic message. This endpoint is public and does not require authentication, making it accessible to any client that makes a request to it and returns a greeting message.

2. **`/protected-get`**: This is a secured `GET` endpoint that requires a valid Bearer token for access. This endpoint demonstrates how to implement token-based authentication in an Express application by:
   - Extracting the token from the `Authorization` header of incoming requests.
   - Using the `axios` HTTP client to send the token to ZITADEL's introspection endpoint, validating the token's activity status.
   - Responding with access to a protected resource if the token is active, or appropriate error messages if the token is missing, inactive, or if there's an error during introspection.


### Step 4: Run Your API

Run your API by executing:

```bash
node app.js
```

Your API is now running on `http://localhost:3000` (or another port if you've configured it differently) and can be tested using Postman.


## Set Up an API Application in ZITADEL 

Go to your ZITADEL project and add a new API application by selecting type **API**. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-01.png" alt="Testing token introspection in ZITADEL with Postman" />


Click on **Basic** in the next screen because we will be using a Client ID and Client Secret for the API application to authenticate itself when introspecting a token with ZITADEL. Click **Continue**. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-02.png" alt="Testing token introspection in ZITADEL with Postman" />


In the next screen, review your application details and click **Create**. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-03.png" alt="Testing token introspection in ZITADEL with Postman" />


Now you will be shown a **Client Id** and **Client Secret**, which you must add to the .env file we created for our Node.js application. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-04.png" alt="Testing token introspection in ZITADEL with Postman" />


You must also copy the **introspection_endpoint** to add to the .env file. The introspection endpoint can be found in the **URLs** section. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-05.png" alt="Testing token introspection in ZITADEL with Postman" />


**Note that when testing an API locally (when using localhost), you will need to install the Postman Desktop Agent in your browser. Postman prompts you to install the Desktop Agent on your browser when you try to make a request to localhost.**


## Test the API with Postman


### Test the Non-Secured Endpoint

In Postman, create a new request to test the simple GET endpoint of our API: http://localhost:3000/simple-get. Since this endpoint doesn’t require a token for access, you will get the response as shown below: 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-06.png" alt="Testing token introspection in ZITADEL with Postman" />


### Test the Secured Endpoint

To test the protected endpoint, you need a valid token. Create a new API request in your collection for http://localhost:3000/protected-get. 

Next, go to the **Authorization** tab and select **OAuth 2.0** in the **Type** dropdown as shown below: 


<img src="/blog/2024-03-07-testing-token-introspection-with-postman-07.png" alt="Testing token introspection in ZITADEL with Postman" />


Next, you need to add an access token. You can obtain the access token the same way we did earlier with the PKCE request. However, we have to make a small adjustment in the scope parameter to include the Project ID as shown below. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-08.png" alt="Testing token introspection in ZITADEL with Postman" />


You must set up the required scopes and claims to ensure that the front-end (Postman) and back-end can exchange data securely. It’s important to note that when specifying the scope when calling the token API, the scope must contain the project ID of the ZITADEL project in which the API resides (to enable token validation by the back-end API). Copy the ID of the project, which you can find in the ZITADEL UI, as highlighted below:  

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-09.png" alt="Testing token introspection in ZITADEL with Postman" />


Go back to Postman and modify the scope field to the following: 
 
**openid profile email urn:zitadel:iam:org:project:id:YOUR_API_PROJECT_ID:aud**. 

Replace API_PROJECT_ID with the ID of the ZITADEL project in which your API resides. 

Get a token, and then send the request. If the token is valid, you will receive a response as shown below: 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-10.png" alt="Testing token introspection in ZITADEL with Postman" />



## Run a Sequence of Requests in Postman

We can automate our requests to the APIs, especially when the execution depends on the outcome of previous requests (like utilizing an obtained token in subsequent calls). This can be managed through Postman's Collection Runner and Pre-request Scripts. Here's how to achieve this, including handling token refreshes:

### Step 1: Set Up an Active Environment and Environment Variables

We need to reuse the access token generated from the Auth Code PKCE request for our subsequent API requests. We can also store auth_url, token_url, client_id, project_id, and access_token as environment variables. To do this, go to the Environments tab in Postman, add a new Environment (the one listed here is Dev), select the environment as the active environment (black tick), and finally add the variable names and their values as shown below.

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-11.png" alt="Testing token introspection in ZITADEL with Postman" />


### Step 2: Set Up Your Postman Collection with the Necessary Requests

We will be using the same requests as we did before with slight changes to include environment variables and a pre-request script in order to use the same access token for all the requests to simulate the typical flow of a user-driven web application. 

1. **Userinfo Endpoint Call**: This initial request authenticates the user and obtains an access token to call ZITADEL’s userinfo endpoint. Assume that this is how the user logs in first to the web application. Notice how the environment variables are used. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-12.png" alt="Testing token introspection in ZITADEL with Postman" />

2. **Simple GET Call**: A basic request that doesn't require authentication.

3. **Protected API Call**: Requires the token for authentication. Notice how we have set the **Authorization Type** to **Bearer Token** here and refers to the environment variable that we created earlier. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-13.png" alt="Testing token introspection in ZITADEL with Postman" />



### Step 3: Extract and Store the Token

In the **Tests** tab in your first request (userinfo endpoint call), add the following code to extract the access token from the first request to store it as a variable:


```javascript
if (pm.request.headers.has("Authorization")) {
   let authHeader = pm.request.headers.get("Authorization");
   let accessToken = authHeader.split(" ")[1]; // Assuming the format is "Bearer <token>"
   pm.environment.set("access_token", accessToken);
}
```

Test scripts in Postman are written in JavaScript and run after the response is received. Don’t forget to save the script. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-14.png" alt="Testing token introspection in ZITADEL with Postman" />


### Step 4: Run Your Postman Collection

Utilize Postman's Collection Runner to run the entire collection. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-15.png" alt="Testing token introspection in ZITADEL with Postman" />


We are going to run the requests manually. Click the **Run** button to run the test. 

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-16.png" alt="Testing token introspection in ZITADEL with Postman" />


This way you can test the OIDC login flow of your web application along with calling the protected endpoints with the received access token. This approach ensures that you can sequentially execute requests that depend on authentication, and efficiently test both authenticated and non-authenticated endpoints within your Postman collection.

<img src="/blog/2024-03-07-testing-token-introspection-with-postman-17.png" alt="Testing token introspection in ZITADEL with Postman" />


## Wrap-up

In this guide, we've taken you through enhancing API security by integrating ZITADEL's API introspection, with a deep dive into Postman for extensive testing. We developed a straightforward API using Node.js and Express, featuring both public and protected endpoints, to showcase how token introspection with ZITADEL can be practically applied and tested using Postman's comprehensive features. Keep an eye out for our upcoming post, where we'll demonstrate setting up ZITADEL programmatically through Postman.




This post walks you through the process of calling a protected API that utilizes token introspection in ZITADEL. We'll guide you step by step through the setup and demonstrate how to use Postman for effective testing.

Test Token Introspection in ZITADEL with Postman


## Introduction

In our previous two posts, we explored testing with Postman the [PKCE Authorization Code login flow for web applications](/blog/testing-login-with-postman) and [token introspection](/blog/testing-token-introspection-with-postman). This time, we'll show you how to bypass manual setups in the ZITADEL Console by using Postman to programmatically create projects, apps, and users. To get started, you'll need to set up a service user and secure an access token, which will enable you to interact with the ZITADEL management API effectively.


## Add a New Service User to call the Management API

Go to **Users** in the console. Next, click on the **Service Users** tab.


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-01.png" alt="Testing management APIs in ZITADEL with Postman" />


Click on **+New**

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-02.png" alt="Testing management APIs in ZITADEL with Postman" />

Next, add details and create your service user. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-03.png" alt="Testing management APIs in ZITADEL with Postman" />


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-04.png" alt="Testing management APIs in ZITADEL with Postman" />


## Provide Admin Permissions to the Service User

Now you have to add the Service User as an Organization Manager. Go to the Project and click **+** next to **ZA**.

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-05.png" alt="Testing management APIs in ZITADEL with Postman" />

Now choose **Service User** as the **Org Owner**. Or you can select the relevant roles based on what he can do in the project. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-06.png" alt="Testing management APIs in ZITADEL with Postman" />


## Create an Access Token for the Service User

Now go to the Service User’s profile again. We’ll create a Personal Access Token (PAT) to set up things quickly. You can choose to go ahead with Client Credentials as well, but for this demo, we’ll be choosing the **Personal Access Token**. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-07.png" alt="Testing management APIs in ZITADEL with Postman" />


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-08.png" alt="Testing management APIs in ZITADEL with Postman" />

## Create a Project via the Management API

You can find more details on how to call the Management API to create a ZITADEL project [here](https://zitadel.com/docs/apis/resources/mgmt/management-service-add-project).

Create a new API request and add the headers as shown below. 

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-09.png" alt="Testing management APIs in ZITADEL with Postman" />

**Authorization Type** should be **Bearer** and you can add the PAT in the **Token** field. 

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-10.png" alt="Testing management APIs in ZITADEL with Postman" />

Go to the **Body** tab and add the following: 

```
{
  "name": "MyPostmanProject",
  "projectRoleAssertion": true,
  "projectRoleCheck": true,
  "hasProjectCheck": true,
  "privateLabelingSetting": "PRIVATE_LABELING_SETTING_UNSPECIFIED"
}
```

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-11.png" alt="Testing management APIs in ZITADEL with Postman" />

Also in the **Tests** tab, set an environment variable to capture the Project Id (when it is returned) as shown below: 

```
let response_body = pm.response.json();
pm.environment.set("project_id", response_body.id); 
```

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-12.png" alt="Testing management APIs in ZITADEL with Postman" />

Now send the request and you will get a response as shown below: 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-13.png" alt="Testing management APIs in ZITADEL with Postman" />

And you will also see that an environment variable called `project_id` is set after this call. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-14.png" alt="Testing management APIs in ZITADEL with Postman" />

If you go to the ZITADEL console, you will also see that a new project was created. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-15.png" alt="Testing management APIs in ZITADEL with Postman" />


## Create an Application via the Management API

Now let’s add our OIDC web application. You can find more details about how to invoke this API [here](https://zitadel.com/docs/apis/resources/mgmt/management-service-add-oidc-app).


Create a new request (**Add OIDC Web App**). Use the `project_id` environment variable in the request URL as shown below. 



<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-16.png" alt="Testing management APIs in ZITADEL with Postman" />

Add Headers. 



<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-17.png" alt="Testing management APIs in ZITADEL with Postman" />

Add the body as follows: 
```
{
 "name": "MyOIDCWebApp",
 "redirectUris": [
   "https://oauth.pstmn.io/v1/browser-callback"
 ],
 "responseTypes": [
   "OIDC_RESPONSE_TYPE_CODE"
 ],
 "grantTypes": [
   "OIDC_GRANT_TYPE_AUTHORIZATION_CODE"
 ],
 "appType": "OIDC_APP_TYPE_WEB",
 "authMethodType": "OIDC_AUTH_METHOD_TYPE_NONE",
 "version": "OIDC_VERSION_1_0",
 "devMode": true,
 "accessTokenType": "OIDC_TOKEN_TYPE_BEARER",
 "accessTokenRoleAssertion": true,
 "idTokenRoleAssertion": true,
 "idTokenUserinfoAssertion": true,
 "clockSkew": "1s",
 "additionalOrigins": [
   "scheme://localhost:8080"
 ],
 "skipNativeAppSuccessPage": true
}
```

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-18.png" alt="Testing management APIs in ZITADEL with Postman" />

We will also need to store the Client ID to an environment variable, so set up an environment variable called `web_app_client_id`. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-19.png" alt="Testing management APIs in ZITADEL with Postman" />

Add the script below to the **Tests** tab of the request. 

```
let response_body = pm.response.json();
pm.environment.set("web_app_client_id", response_body.clientId); 
```


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-20.png" alt="Testing management APIs in ZITADEL with Postman" />

And as before, add the service user’s PAT as the Bearer Token: 



<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-21.png" alt="Testing management APIs in ZITADEL with Postman" />


And you should get the following response. 



<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-22.png" alt="Testing management APIs in ZITADEL with Postman" />

Check if the environment variable is also set for the web app’s client id. 



<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-23.png" alt="Testing management APIs in ZITADEL with Postman" />


Similarly, you can now add the API application to this project as well. See [here](https://zitadel.com/docs/apis/resources/mgmt/management-service-add-api-app) for more details about how to call this API. You can duplicate the previous OIDC web app creation request and change the body as follows: 

```
{
"name": "MyAPIApp",
"authMethodType": "API_AUTH_METHOD_TYPE_BASIC"
}
```

You don’t need any scripts for this request. When you send this request, you will receive the clientId and clientSecret. This needs to be added to the Node API project’s .env file. 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-24.png" alt="Testing management APIs in ZITADEL with Postman" />

## Create a User via the Management API

Let’s also [add a user](https://zitadel.com/docs/apis/resources/mgmt/management-service-import-human-user) to the project via the API.

Create the request as shown below (you can duplicate the previous request): 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-25.png" alt="Testing management APIs in ZITADEL with Postman" />

Add the following text to the body:

```
{
"userName": "minnie-mouse",
"profile": {
  "firstName": "Minnie",
  "lastName": "Mouse",
  "nickName": "Mini",
  "displayName": "Minnie Mouse",
  "preferredLanguage": "en",
  "gender": "GENDER_FEMALE"
},
"email": {
  "email": "minnie@mouse.com",
  "isEmailVerified": true
},
"phone": {
  "phone": "+41 71 000 00 00",
  "isPhoneVerified": true
},
"hashedPassword": {
  "value": "$2a$12$k0LsiR40ZNcMxbyD80g5nebjB9R0/VqilwfFLLr6m/XTOc9WRf8Om"
},
"passwordChangeRequired": true,
"requestPasswordlessRegistration": true,
"otpCode": "string"
}
```

<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-26.png" alt="Testing management APIs in ZITADEL with Postman" />

You will receive the following response when you send the request: 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-27.png" alt="Testing management APIs in ZITADEL with Postman" />


You will now see the new user appearing in the ZITADEL Console: 


<img src="/blog/2024-03-07-testing-zitadel-apis-with-postman-28.png" alt="Testing management APIs in ZITADEL with Postman" />


## Try it out Yourself

You can visit our GitHub repository at [https://github.com/zitadel/example-postman-collections](https://github.com/zitadel/example-postman-collections) to download the collection and environment setup that we covered in our Postman blog series. You can add other types of applications, users and roles via the ZITADEL API to this collection and test out various scenarios. Whether you're looking to automate your authentication flows, manage users, or secure your applications, our Postman collection is a great starting point. Happy testing!


This post walks you through the process of testing the ZITADEL Management API to create ZITADEL Projects, Apps, and Users with Postman.

Test the ZITADEL Management API with Postman


## Our Journey: Enhanced Security and Transparency

We are committed to transparency, and that is why we want to give a brief update on the recent [security advisories](https://github.com/zitadel/zitadel/security/advisories) that we issued for ZITADEL.

Let’s start with a couple of figures from this year. We started the year with around 2,000 GitHub stars and grew to more than 5,500 in the last 11 months. Our community on [Discord](https://zitadel.com/chat) had around 100 members, and now we have more than that online around the clock, with over 1,300 members in the channel. Container downloads grew to over 400,000 this month.

We’ve been growing as a community and open-source project, as a cloud service, and as an organization. With growth come more eyeballs; with more eyeballs on our software, we get better ideas for solving bugs, improving code quality, and enhancing security. It seems we might have reached a point where [Linus's Law](https://opensource.com/article/21/2/open-source-security) starts to kick in.

While we follow secure coding practices and also conduct regular [penetration tests by third parties](https://zitadel.com/blog/tags/pentest), we actively encourage people and researchers through our [disclosure policy](https://zitadel.com/docs/legal/policies/vulnerability-disclosure-policy) to test ZITADEL and disclose vulnerabilities responsibly. Following our disclosure process, we publish [security advisories](https://github.com/zitadel/zitadel/security/advisories) on GitHub and inform affected users and customers.

Besides application security, we have also enhanced our information security culture and practices over the last year to strengthen our operational security as well. Examples of this include clarifying the [account lockout policy](https://zitadel.com/docs/legal/policies/account-lockout-policy) and successfully mitigating several notable (D)DoS attacks. We have recently updated our [Trust Center](https://trust.zitadel.com/) to provide you with more information about our security practices.

In recent weeks, we mitigated vulnerabilities reported by different security researchers that could impact the security of systems using ZITADEL. Interestingly, some of the reporting parties conducted security research either on behalf of clients or as part of their due diligence process.

After reviewing and closely collaborating with the researchers, we promptly provided patched versions and issued security advisories, prompting affected users to upgrade to these patched versions. Since ZITADEL acts as a critical piece in protecting the confidentiality and integrity of applications, and moreover, could lead to systems becoming unavailable for users, most of the vulnerabilities receive a high severity rating.

Here is a short overview of the findings:
### Password Reset Does Not Respect the "Ignoring Unknown Usernames" Setting (Moderate)

ZITADEL administrators can enable a setting called "Ignoring Unknown Usernames," which helps mitigate attacks that try to guess or enumerate usernames. While this setting was properly functioning during the authentication process, it did not work correctly in the password reset flow. This meant that even if this feature was active, an attacker could use the password reset function to verify if an account exists within ZITADEL.
[Security Advisory Link](https://github.com/zitadel/zitadel/security/advisories/GHSA-v683-rcxx-vpff)

### XSS with User Avatar Image (High)

ZITADEL users can upload their own avatar images. Various image types are allowed, including SVG. SVG files can include scripts, such as JavaScript, which can be executed during rendering. 

Due to a missing security header, an attacker could inject code into an SVG file to gain access to the victim’s account in certain scenarios.
Please check out the details in the [published advisory](https://github.com/zitadel/zitadel/security/advisories/GHSA-954h-jrpm-72pm). You can also read the [researcher’s blog post](https://zxsecurity.co.nz/research/advisories/zitadel-account-takeover/) for more information.

### Race Condition in Lockout Policy Execution (High)

ZITADEL provides administrators the ability to define a Lockout Policy with a maximum number of failed password check attempts. On every failed password check, the count of failed attempts is compared against the configured maximum. Exceeding this limit will lock the user out and prevent further authentication.

In the affected implementation, it was possible for an attacker to initiate multiple parallel password checks, thereby gaining the ability to try out more combinations than allowed by the Lockout Policy.
We have published the following [advisory](https://github.com/zitadel/zitadel/security/advisories/GHSA-7h8m-vrxx-vr4m), and the researchers have provided a [write-up on their blog](https://zxsecurity.co.nz/research/advisories/race-condition-zitadel/).

### Account Takeover via Malicious Host Header Injection (High)

ZITADEL uses the notification triggering request's Forwarded or X-Forwarded-Host header to build the button link sent in emails for confirming a password reset with the emailed code. If this header is overwritten and a user clicks the link to a malicious site in the email, the secret code can be retrieved and used to reset the user's password, leading to account takeover.

Accounts with MFA, especially Passwordless (aka Passkeys), cannot be taken over by this attack.

You can find more information in our [advisory](https://github.com/zitadel/zitadel/security/advisories/GHSA-2wmj-46rj-qm2w).

## Commitment to Continuous Security Improvement

We truly appreciate the time and effort that went into reporting and clarifying the vulnerabilities in ZITADEL. This work will not only better protect our customers, but our open-source community will also benefit from a more secure version of our product.

Pentests are one part of our security measures, and we will continue to commission security audits to third parties. Furthermore, we strongly encourage users to set up MFA, especially Passkeys, to protect their accounts in the best way possible. Although not all vulnerabilities can be compensated for by secure authentication, it still significantly reduces the attack surface. In terms of scope, we are planning to conclude a majority of the rework on our APIs, such as introducing a session API and [switching from a service-based to a resource-based API](https://chat.openai.com/blog/resource-api), and subject those changes to a thorough review. However, we will not limit the scope only to new features but will continue to review existing features and our infrastructure.




In the past few weeks, we mitigated multiple vulnerabilities reported by different security researchers that could have impacted the security of systems using ZITADEL.

Thank you for Making ZITADEL More Secure

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


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

All posts/ #security