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


This is Max from ZITADEL. As always, I would like to highlight some of our product updates, and tips and tricks in making your identity infrastructure easier and more effective.

Summarizing the April product updates for ZITADEL is a difficult task. While we continue to work on the big roadmap items, the team worked diligently to address improvements ranging from new security features to performance enhancements to secure millions of identities. We shipped over 76 features, improvements, and bug fixes to our products. For those keeping score, that is nearly 400 year to date.

### Feature highlights

Let me share some of the more noteworthy features that were shipped during the month of April.

#### Setup your email provider - easier than ever

A generous contribution from our open source community, simplifies the configuration of email delivery within ZITADEL by introducing SMTP provider templates. These templates offer pre-defined settings for popular email service providers (ESPs) like Amazon SES, Mailgun, Mailjet, Postmark, Sendgrid, and a Generic SMTP option.

By the way, we strongly recommend replacing the pre-configured SMTP service in ZITADEL Cloud. The default provider is for demonstration purposes only and will not provide a reliable way to send emails to your users.

![SMTP provider settings in ZITADEL Console](/blog/2024-05-07-zitadel-product-newsletter-april-2024-01.png)

#### Link accounts with external identity providers

There are situations where your users might have created an account in your application and only later on want to connect their social login or external identity provider.

As of now an error might have been shown to the user, since the IdP link was not known before, but the automatic federation / creation failed, because the information (e.g. username) already existed in ZITADEL.

With a newly introduced functionality, users can connect their account with an account provided by an external identity provider. Administrators can configure how accounts should be matched against usernames or email addresses. 

#### Experimental features

Over the past weeks we introduced feature flags into the core of ZITADEL. Feature flags allow administrators to opt-in or opt-out of experimental features that are not intended to be generally available. In April we finished the work by shipping the new feature settings into the Console. 

Our intention with feature settings is to provide means to access and test early features for users to test and provide feedback. Among the currently available functionalities are several performance improvements, OpenID Connect Token Exchange, a preview of User Schemas, and a preview of a more powerful Actions feature. Some settings allow you to roll-back some improvements that would result in issues to few users.

![Feature settings in ZITADEL Console](/blog/2024-05-07-zitadel-product-newsletter-april-2024-02.png)

#### Limit one-time password attempts

Similar to the existing lockout functionality for password attempts, Managers are able to configure automatic lockouts after a specified number of consecutive failed Time-based One-Time Password (TOTP) checks. The new feature strengthens security posture by mitigating brute-force attacks targeting (T)OTP verification.

Lockouts are applied independently for each TOTP method. This ensures users retain the ability to attempt alternative verification methods (e.g., email OTP) even after exceeding the threshold for a specific TOTP method (e.g., mobile app).

[View all changes on our new changelog](https://zitadel.com/changelog)

### ZITADEL Cloud for scale and simplicity: focus on what matters most

We have no plans of moving to a cloud only service. Let me state that right at the start. There are many reasons and use cases to go for an enterprise grade identity management solution that runs on your private infrastructure, ranging from compliance requirements and risk reduction to special cases such as embedded systems.

In a self-hosted setup you will not only be responsible for managing the infrastructure layer, but also the operational security aspects of the deployment. When using cloud you don’t have to worry about DDoS attacks, WAF configuration, or bot detection during login and register. These are all covered by our systems, have a look at our shared [responsibility matrix](https://zitadel.com/docs/legal/service-description/cloud-service-description#responsibilities) to learn more.

The Pro plan now includes 25’000 daily active users per month. The cost for additional daily active users was also reduced to offer you better scale. We will streamline our subscriptions and update all existing plans that use authenticated requests to an up-to-date plan. No action is required on your end, the changes will be applied automatically on July 1st.

### What we’re working on

#### Feedback wanted on Token Exchange

We are very happy to announce that OAuth 2.0 Token Exchange according to RFC 8693 landed in ZITADEL. This grant will lay the foundation for more advanced integration scenarios, including impersonation of users, token validation and exchange with third-party identity providers, and exchange of session tokens and OAuth tokens.

To get started, follow our integration guide on [Impersonation and delegation using Token Exchange](https://zitadel.com/docs/guides/integrate/token-exchange) and make sure to [enable the feature](https://zitadel.com/docs/guides/manage/console/default-settings#features) in the newly introduced feature settings.

We would very much like to get your feedback on the implementation and learn more about your use cases. Join the discussion on our Github repository.

[Github Discussions](https://github.com/zitadel/zitadel/discussions)

#### A new login UI in typescript for you to make your own

Already today you can use our [hosted login UI](https://zitadel.com/docs/guides/integrate/login/login-users) for the highest security standards. For a couple of months you are also able to use the Session API to [build your own login interface](https://zitadel.com/docs/guides/integrate/login-ui) and user flows.

We are currently working on a next generation of our login page, written in Typescript, that will replace our existing hosted login UI. The goal is to implement a login UI, using the session API of ZITADEL, which also implements the OIDC Standard and is ready to use for everyone.

In the first phase we want to have a MVP login ready with the OIDC Standard and a basic feature set. In a second step the features will be extended. 

As always, we value your early feedback, ideas, and contributions to the next generation of our - and hopefully your - login experience.

[To the Typescript Repo](https://github.com/zitadel/typescript)

### Better together

Our community members contributed 23 improvements and features to ZITADEL repositories. I want to thank you for your continued support and the time you put in to make the project better for everyone.

* The feature SMTP templates for the most popular email service providers was contributed by [doncicuto](https://github.com/doncicuto). Not only a great feature, but also a lot of testing involved - a special thanks for that contribution
* [aDogCalledSpot](https://github.com/aDogCalledSpot) added the option to use locally generated RSA keys for service users, avoiding keys being sent over the network instead
* [Doncicuto](https://github.com/doncicuto) contributed also to multiple parts of the console to fix reported issues, improving the overall usability of the UI and APIs
* [Compatibility](https://github.com/zitadel/oidc/issues/565) of oidc client device authorization grant with Google by [celian-garcia](https://github.com/celian-garcia)  and ability to verify ID tokens based on available sign algorithms from the discovery endpoint by [otakakot](https://github.com/otakakot)
* [vigneshsankariyer1234567890](https://github.com/vigneshsankariyer1234567890) improved UX where users switching between register and login got lost
* [celian-garcia](https://github.com/celian-garcia) , [jkroepke](https://github.com/jkroepke), and [otakakot](https://github.com/otakakot) improved error handling in our oidc library
* [yordis](https://github.com/yordis), [zoltantemesvari](https://github.com/zoltantemesvari), [ahmednfwela](https://github.com/ahmednfwela), and  [HaimKortovich](https://github.com/HaimKortovich) helped us to improve and keep our SDKs up-to-date
* Charts repository dependencies by [rud](https://github.com/rud) and improved configuration of ports [ameijboom](https://github.com/ameijboom) 
* Typos and corrections to docs [EthanHeilman](https://github.com/EthanHeilman),  [alexrimlin](https://github.com/alexrimlin), and [thamow](https://github.com/thamow)

Thinking of contributing? Grab a ‘good first issue’ or start a discussion and get started with our [contribution guide](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md).

### Additional resources

* [‘Worth exploring’ - Thoughtworks technology radar](https://www.thoughtworks.com/radar/platforms/zitadel)
* Video: [Complete Guide to Identity Federation and Brokering Using ZITADEL](https://www.youtube.com/watch?v=wg-ee-EnHdE)
* [Built with ZITADEL: 23 Technologies' Kubernetes-as-a-Service](https://zitadel.com/blog/success-story-23-technologies) 
* [Test Token Introspection in ZITADEL with Postman](https://zitadel.com/blog/testing-token-introspection-with-postman)

Thanks for reading,

Max


Updates on ZITADEL, and tips and tricks in making your identity infrastructure easier and more effective for April 2024. In this episode we write about SMTP provider templates, limit attacks on OTP, and account linking. We also share what we are currently working on.

Product Newsletter April 2024


This is Max from ZITADEL. In this newsletter, I would like to highlight some of our product updates, and tips and tricks in making your identity infrastructure easier and more effective.
This is the March 2024 edition of our newsletter.

### Feature highlights

In March, the team shipped over 110 improvements and features to ZITADEL, including many bug fixes and stability improvements. We also delivered critical security patches for issues that were reported by the community and customers. Most of the new feature development in March contributes to our roadmap items and improves the user experience.

#### Easier integration with your frameworks

Simply set up a client application in your framework and programming language. You can choose your framework in the Console, and we take care of the default settings for you so you can get started even faster.

Of course, you can still integrate with any other framework or language.

![ZITADEL Console showing app creation screen with various programming languages and frameworks](/blog/2024-04-05-zitadel-product-newsletter-march-2024-01.png)

#### Better descriptions and tooltips

While you can use the APIs to configure ZITADEL, many users rely on the Console as a user interface to configure their system. Descriptions, tooltips, and labels of both the default settings and the organization settings pages were adapted for clarity and to provide more information to users.

The latest stable version is 2.43.11. You can find the [version of our stable release](https://zitadel.com/docs/support/software-release-cycles-support#stable) information in our documentation. Some features are only available in the latest versions.

### New docs resources

This month, we worked on several documentation resources to help developers use and integrate ZITADEL more effectively. 

* [How to handle session validation when building your own login UI](https://zitadel.com/docs/guides/integrate/login-ui/session-validation)
* [Using OKTA SAML IdP for single-sign-on](https://zitadel.com/docs/guides/integrate/identity-providers/okta-saml)
* [Using Entra ID SAML IdP for single-sign-on](https://zitadel.com/docs/guides/integrate/identity-providers/azure-ad-saml)
* [Code example for ZITADEL actions](https://zitadel.com/docs/apis/actions/code-examples)
* [Guide on how to login users with SSO in ZITADEL](https://zitadel.com/docs/guides/integrate/identity-providers/introduction)
* Reworked [service user authentication](https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users) and guides on [how to access ZITADEL APIs](https://zitadel.com/docs/guides/integrate/zitadel-apis/access-zitadel-apis)
* [Streaming audit logs to external systems such as SIEM/SOC](https://docs-git-external-idp-intro-zitadel.vercel.app/docs/guides/integrate/external-audit-log)

[Check out all our guides](https://zitadel.com/docs/guides/overview)

### Technical & security advisories

Technical advisories (“TA”) are notices about major issues with ZITADEL Self-Hosted or the ZITADEL Cloud platform that could potentially impact security or stability in production environments.   For example, we issue technical advisories if breaking behavior was introduced in a release or if you must expect downtime during an upgrade.

[Review and subscribe to our technical advisories](https://zitadel.com/docs/support/technical_advisory)

Security advisories are notices about security vulnerabilities that affect ZITADEL. While we patch ZITADEL Cloud automatically, these advisories are critical for self-hosted deployments. Make sure to subscribe to “Security alerts” on our GitHub repository, by clicking on “Unwatch”, then “Custom” and selecting “Security alerts”.

[Review past security advisories](https://github.com/zitadel/zitadel/security)

Both technical and security advisories contain the details about the issue, affected versions, and how to resolve the issue.

### What we’re working on

Behind the scenes, the team is continuously  developing and refining the next major feature and improvement.

We needed to make delivery of alpha (experimental) and beta features safer and easier for users. With the recent releases in March, we introduced feature flags via a [feature API](https://zitadel.com/docs/apis/resources/feature_service), allowing users to enable features that are not yet intended for general availability for testing purposes.

In March, we made significant progress on these features. Make sure to subscribe to the underlying GitHub issue to receive regular updates.

* [Impersonation](https://github.com/zitadel/zitadel/issues/7208) enables a functionality to impersonate users to act on behalf of other users. Our efforts in March focused on security settings, Manager roles, and token exchange. We expect to release a preview of the feature in the coming weeks.
* [User Schema](https://github.com/zitadel/zitadel/issues/6433): Implementation for user schemas has started with the first APIs becoming available. This feature is still experimental and behind a feature flag.

[Roadmap](https://zitadel.com/roadmap)

### Community building: Contributions and feedback

Token exchange (RFC8693) is a permissive standard that we will implement to facilitate use cases, such as the impersonation of users. We hope to gather some feedback on our implementation from our community.

Give your [feedback on Token Exchange and impersonation](https://github.com/zitadel/zitadel/discussions/7624).

In March, our community contributed to ZITADEL and our libraries again. Thank you for your continuous support!

* [ay4toh5](https://github.com/ay4toh5i) implemented the OpenID Connect  form_post response mode, increasing interoperability with client applications of our zitadel/oidc library and in the further development of ZITADEL itself.
* [doncicuto](https://github.com/doncicuto) added expiration date information for service users’ keys. Keys expire at midnight (UTC), and that information was previously not displayed to users.
* [vigneshsankariyer1234567890](https://github.com/vigneshsankariyer1234567890) realized we were misaligned with our login button in the email verification and fixed it, while [github-tijlxyz](https://github.com/github-tijlxyz) corrected a mistake in our keycloak migration guide
* [bjw-s](https://github.com/bjw-s) and [pisarz](https://github.com/pisarz) improved our charts allowing additional pod labels and introducing parametrization to probe schemes
* [PaulHiryliuk](https://github.com/PaulHiryliuk) and [petrmifek](https://github.com/petrmifek) helped by reviewing and improving  Czech and Russian translations

We are really grateful to receive all the big and small contributions and the countless feedback and improvement ideas. In case you want to contribute, start with our [contribution guide](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md).

### Additional resources

* [On our blog: Test your web app login flow with Postman](https://zitadel.com/blog/testing-login-with-postman)
* [ROSS Index: ZITADEL as one of the top trending open-source startups in 2023](https://runacap.com/ross-index/annual-2023/)
* [Transforming Identity and Access Management with Event Sourcing](https://thenewstack.io/transforming-identity-and-access-management-with-event-sourcing/)
* [ZITADEL as Identity Provider for NetBird](https://docs.netbird.io/selfhosted/identity-providers)
* [Load testing ZITADEL using K6](https://medium.com/@harsha_reddy/load-testing-zitadel-using-k6-a68328c89b33)


Updates on ZITADEL, and tips and tricks in making your identity infrastructure easier and more effective for March 2024. This edition includes improvements to the console, new docs resources, and things we are working on right now.

Product Newsletter March 2024


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


We're excited to share with you some of our product updates, and tips and tricks in making your identity infrastructure easier and more effective.
This is the February 2024 edition of our newsletter.

## Feature highlights

Our team shipped more than 91 improvements and features in February across all ZITADEL components. Here are some of the highlights in February 2024.

### Organization metadata

With organization metadata, you are able to assign arbitrary information to an organization. This could be, for example, information such as a hierarchical relationship, an internal tenant identifier, or billing information.

With the latest improvements developers can now use the organization metadata in the [complement token flow](https://zitadel.com/docs/apis/actions/complement-token) in Actions. Developers can include a user’s organization metadata into tokens that can be read by receiving applications. An [example on using organization metadata in Actions](https://github.com/zitadel/actions/blob/main/examples/org_metadata_claim.js) is available in our repository.

### Improvements to the official Terraform provider

With the release v1.1.0 of ZITADEL’s official Terraform provider, you can add SAML applications. Moreover, you can generate service user secrets and import service users with an existing secret.

Additionally to the changes mentioned above, we shipped various bug fixes, stability improvements, and enhancements of our documentation.

Make sure to upgrade to the latest version [2.46.0](https://github.com/zitadel/zitadel/releases/tag/v2.46.0) to benefit from the latest features. Consult the [Technical Advisories](https://zitadel.com/docs/support/technical_advisory) for breaking behavior and upgrade recommendations. 

The latest stable version is 2.37.3. You can find the [version of our stable release](https://zitadel.com/docs/support/software-release-cycles-support#stable) information in our documentation.

## More sample apps to secure your favorite language

![Available example apps for zitadel in different programming languages and frameworks such as Angular, Flutter, Go, Java, NestJS, Next.js, Python Django, Python Flask, React, PHP Symfony, Vue.js](/blog/2024-02-29-zitadel-product-newsletter-01.png)

We continued with sample applications to make your authentication and authorization easier in February. These changes also come with a fresh look in our documentation. Have a look at the new example applications:

* [Python Django](https://zitadel.com/docs/sdk-examples/python-django)
* [React](https://zitadel.com/docs/sdk-examples/react)

Are you missing an example or SDK in your favorite language? [Vote and join the discussion](https://github.com/zitadel/zitadel/discussions/7376)

## Tip of the month: Managers are privileged users

Managers are users who have privileged permissions to make changes within ZITADEL itself. This could be changing configurations, creating new users, or assigning roles within an organization.

For example, you can assign a Manager role to the first user of a new organization. With that, you can enable the user to configure SSO and login policies or assign roles to their team in self-service.

Developers can assign a Manager role to service users to make changes via API instead of using the Console.

[Learn how to use Managers](https://zitadel.com/docs/guides/manage/console/managers)

## Building together: Contributions & feedback

### Shape the new user API

We’re actively looking for feedback on our User API. The API is based on the new User Schema, which will allow developers to define the fields of the user, permissions of Managers and users to edit fields, and more.

[Give feedback on the user API](https://github.com/zitadel/zitadel/discussions/7423)

### Community contributions

In February our community contributed over 18 features and fixes to ZITADEL. Our thanks go out to everyone who contributed.

* [jkroepke](https://github.com/jkroepke) made valuable contributions to the oidc library
* [doncicuto](https://github.com/doncicuto) provided several UI fixes to the console
* [dvob](https://github.com/dvob), [mdarii](https://github.com/mdarii), and [filips](https://github.com/filips) contributed important improvements and bug fixes on the operations and deployment functionality.
* [yordis](https://github.com/yordis), [tired-engineer](https://github.com/tired-engineer), [omarmoo5](https://github.com/omarmoo5), and [accir](https://github.com/Accir) helped us fix various typos and improve our documentation

Thanks again for all the big and small contributions, and the countless feedback and improvement ideas. In case you want to contribute, start with our [Contribution Guide](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md).

## What we’re working on

The team works continuously to deliver new features, improvements, and bug fixes. You can review the high-level items on our public [roadmap](https://zitadel.com/roadmap). This month, we started working on these important features. Make sure to subscribe and receive a notification once they are done.

* [Actions V2](https://github.com/zitadel/zitadel/issues/7235), called Executions, allow developers to customize the behavior of ZITADEL. Actions exist today already but are limited to certain flows and triggers. The upgraded version of Actions will allow developers to manipulate requests, manipulate the response, react to events, or hook into predefined trigger points.
* [ZITADEL CLI](https://github.com/zitadel/zitadel/issues/6669), aka. zcli, allows developers to send commands to ZITADEL from the CLI.
* [Impersonation](https://github.com/zitadel/zitadel/issues/7208) enables a functionality to impersonate users to act on behalf of other users. Impersonation will be limited to configurable user groups and will be logged in the audit trail.

## Additional resources

* [Integration guide: MockSAML](https://zitadel.com/docs/guides/integrate/identity-providers/mocksaml)
* [Hosted login vs. custom login user interface](https://zitadel.com/docs/guides/integrate/login/login-users)
* [Log actions to stdout](https://zitadel.com/docs/apis/actions/modules#log)
* [Prevent users from accessing ZITADEL console](https://zitadel.com/docs/guides/solution-scenarios/restrict-console)
* [Why we moved ZITADEL Cloud from CockroachDB to PostgreSQL](https://zitadel.com/blog/move-to-postgresql)


Updates on ZITADEL, and tips and tricks in making your identity infrastructure easier and more effective for February 2024. This edition includes details about the new organization metadata feature, latest examples, and things we are working on right now.

ZITADEL Product Newsletter for February 2024


## Introduction

ZITADEL Cloud recently made a notable shift in its database choice by moving from CockroachDB to PostgreSQL. This operational change was influenced by several factors, which we will explain in this blog. We took proactive steps to inform our valued customers about this infrastructure shift, and we've successfully completed the transition to PostgreSQL within our cloud service. Currently, we are actively working on revising our documentation and examples to reflect this change, i.e., prioritize PostgreSQL over CockroachDB. 
ZITADEL Cloud exclusively operates on Google Cloud Platform (GCP), which plays a significant role in our decision-making process. Our choice to adopt PostgreSQL was made smoother due to our seamless integration with GCP's managed database service, Cloud SQL. This fully managed, highly available PostgreSQL environment enabled us to tap into the scalability, reliability, and security features that GCP offers, all while benefiting from PostgreSQL's strong performance and efficiency.

Additionally, our aim to minimize the involvement of subprocessors and reduce reliance on third-party entities, including our previous discontinuation of Cloudflare services, played a significant role in this decision. This approach aligns with our goal of reducing dependencies on external partners, which not only simplifies control but also decreases the risk of data leakages.

Let’s dive into some of the key factors that drove this shift. 

## Data Residency and Control Concerns

One of the primary drivers behind our switch was concerns about how we managed data and where it was stored. With CockroachDB Dedicated, while we could set data storage regions, controlling the movement of log files and preventing data from ending up in unintended places was a real challenge. That challenge led us to difficulties in assuring our customers that their data would exclusively reside in their designated regions, ultimately influencing our decision to transition to PostgreSQL.

Shifting to PostgreSQL within GCP’s Cloud SQL environment gave us stronger tools for enforcing data residency within specific geographical boundaries. This was and still is vital for complying with regional data protection laws and building trust with our customers.

## Technical Factors 

### Improved Latency and Efficiency

Our decision to switch was also motivated by the need to improve latency and streamline infrastructure efficiency. CockroachDB's global distribution model, while really advantageous for high availability, introduced higher latency and required more compute resources, leading to higher costs. In contrast, PostgreSQL, with its simpler architecture, enabled us to handle larger workloads with improved latency and reduced compute requirements. As a result, ZITADEL Cloud experienced significant enhancements in database query performance and overall system responsiveness. These improvements were particularly noticeable in our reduced API latency.

### Scalability and Infrastructure Optimization

Our decision to shift to PostgreSQL was also rooted in a thorough analysis of our infrastructure needs. For example, running a CockroachDB cluster required 3 nodes per region, each equipped with 8 CPUs and 32 GB of RAM, operating at around 40-50% capacity. In contrast, PostgreSQL allowed us to achieve similar results with significantly fewer resources with 4 CPUs and 16GB of RAM, making our infrastructure utilization more efficient.

Scalability was another factor in our choice. GCP's ability to offer robust configurations combined with PostgreSQL's efficient scaling capabilities allowed us to confidently handle growing workloads. Whether we need to scale vertically or horizontally, PostgreSQL's architecture, coupled with GCP's infrastructure, provides the flexibility we need.

Recent advancements in cloud infrastructure have made PostgreSQL an even more attractive option. We can now vertically scale to machines with substantial resources, like 128 CPUs and nearly a terabyte of memory, addressing our previous scalability concerns in the past. Additionally, PostgreSQL's operational flexibility, including the ability to adjust database costs for different operations and utilize read replicas, gives us more options for scalability and performance optimization.

### Operational Flexibility and Ease of Use

Moving to PostgreSQL also made our operational processes more straightforward. Running a dedicated PostgreSQL cluster in each region provides us with greater flexibility in how we handle tasks like isolated schema changes and rollouts, making data management smoother and less expensive.
For example, optimizing for PostgreSQL was easier due to its non-distributed nature, allowing for straightforward use of transaction IDs. This simplicity was in contrast to the complexities associated with CockroachDB's logical timestamps. PostgreSQL presented a more deterministic and less resource-intensive approach.

## Cost Effectiveness

Financial factors also weighed in our decision-making process. Operating a CockroachDB cluster incurred considerably higher costs compared to a similar configuration with PostgreSQL on Cloud SQL. For instance, we noted that a CockroachDB cluster with 3 nodes (8 CPUs, 32 GB RAM each) was almost three times as expensive as a PostgreSQL setup (4 CPUs, 16 GB RAM) while offering comparable performance per region. This cost difference, coupled with a more straightforward scaling model, made PostgreSQL a more economically viable option.

## Conclusion

The decision to embrace PostgreSQL wasn't straightforward and was influenced by a blend of considerations, including data residency assurance, reduced latency requirements, cost-efficiency, operational flexibility, optimization simplicity, and scalability potential.

It's worth noting that CockroachDB remains extremely valuable, particularly in scenarios where high availability is a non-negotiable requirement, even if it means sacrificing a bit of speed. Essentially, it boils down to a classic trade-off between latency and availability, which you see in all distributed systems. If achieving the lowest possible latency while accommodating minor availability trade-offs is your goal, PostgreSQL emerges as the preferred choice. On the other hand, if ensuring rock-solid availability takes precedence and you can tolerate slightly higher latency, then opting for a CockroachDB cluster is the recommended route. Naturally, cost considerations also factor into this evaluation.






This article delves into ZITADEL Cloud's shift from CockroachDB to PostgreSQL and the reasons behind this database transition.

Why We Moved From CockroachDB to PostgreSQL


We're excited to share with you some of our product updates, and tips and tricks in making your identity infrastructure easier and more effective. 

### New sample apps in VueJS, PHP, and Java

We have set ourselves the goal to make your life as easy as possible —at least for your authentication and authorization needs. Check out these newly added examples and guides for PHP, Vue, and Java to get started in minutes:

* [PHP Symphony](https://github.com/zitadel/example-symfony-oidc)
* [VueJS](https://github.com/zitadel/zitadel-vue)
* [Java](https://github.com/zitadel/zitadel-java)

Are you missing an example or SDK in your favorite language? Let us know by opening an improvement idea. 

[Create an improvement idea](https://github.com/zitadel/zitadel/issues/new/choose)

### Tip of the day: Invite users outside of your organization

![user_grants](/blog/2024-01-31-zitadel-product-newsletter-01.png)

Maybe you didn’t know, but you can invite users from other organizations and assign them authorizations just as for internal users. This is what we call “user grants”, they work the same as for organization grants, but for users.

Do you have partners or agencies managing your customers' organizations on behalf of them? Maybe have a look at user grants and see if that could help you to make this process easier.

[Read more about multi-tenancy](https://zitadel.com/blog/multi-tenancy-with-organizations)

### Build or buy? Anyways, lunch was on us

This month we started a webinar series “Lunch & Learn. First to start was Fabienne, our Head of Product & Co-Founder taking on the topic “Build or Buy?”.

What are build and buy decision factors? And when does the complexity of modern identity management really come into play when rolling your own auth?

Did you miss it? We published the first webinar of the series on our [YouTube channel](https://www.youtube.com/watch?v=xn_yNzWKfIA&t=315s), including the Q&A with our participants.

Make sure to register for our future webinars on topics such as Beyond Community Bug Fixing, Penetration Testing, or making your applications more secure. Recordings of future webinars will be published only later this year, so make sure to register for the webinar.

[Register for our next webinar](https://share-eu1.hsforms.com/1SPAf60K9QO-QqF7Vqp6s8Q2dljbt)

### What else has changed in ZITADEL?

* We shipped many bug fixes and performance improvements in January
* Improvements in how errors are handled and logged for OpenID Connect functionalities
* Added more functionality (GetUserByID) to the resource-based API, as part of deprecating our service-oriented APIs
* You can now define some resources by name rather than id only when using our [Terraform Provider](https://github.com/zitadel/terraform-provider-zitadel). This should make it easier for many users to apply the same configuration to different environments.

Remember that the latest stable version is 2.37.3. You can find the [version of our stable release](https://zitadel.com/docs/support/software-release-cycles-support#stable) information in our documentation. Make sure to check the [Technical Advisories](https://zitadel.com/docs/support/technical_advisory) for breaking behavior and upgrade recommendations.

### Contributions

We received 18 contributions to our products through our community in January. Thank you very much for your continuous support!

* [doncicuto](https://github.com/doncicuto) provided several fixes to login and console, making it easier for users to navigate, configure, and login to ZITADEL, and contributed a feature to search for users by their email address
* [jkroepke](https://github.com/jkroepke) contributed features and fixes to our OIDC package, improving error messages
* Our Helm Chart received valuable improvements from  [thomaspetit](https://github.com/thomaspetit), [arnouthoebreckx](https://github.com/arnouthoebreckx), and [raunodepasquale](https://github.com/raunodepasquale)
* [tafaust](https://github.com/tafaust) contributed a NodeJS-NestJS example
* [ahmednfwela](https://github.com/ahmednfwela) kindly improved the Flutter example
* [lukasver](https://github.com/lukasver) and [tstenner](https://github.com/tstenner) helped us find errors and typos in our docs

Thanks again for all the big and small contributions, and the countless feedback and improvement ideas. In case you want to contribute, start with our [contribution guide](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md).

### Additional resources

* [New Guide: Onboard your customers and users](https://zitadel.com/docs/guides/solution-scenarios/onboarding)
* [Hands-on Introduction to ZITADEL | Rawkode Livestream](https://www.youtube.com/watch?v=ctkmwzHgIPs&list=WL&index=3)
* [Exciting ZITADEL Features to Watch for in 2024](https://zitadel.com/blog/upcoming-features-2024) 
* [Built with ZITADEL: CrossClassify's Fraud Prevention Solution](https://zitadel.com/blog/success-story-crossclassify)
* [Built with ZITADEL: Open Systems' IAM Strategy for Global Networks](https://zitadel.com/blog/success-story-open-systems)


Updates on ZITADEL, and tips and tricks in making your identity infrastructure easier and more effective for January 2024

ZITADEL Product Newsletter


<img
    src="/blog/2024-01-25-success-story-crossclassify-01.png"
    width="100%"
    alt="Banner Image"
    style={{ margin: '0 auto' }}
  />

## Key Outcomes

- [CrossClassify](https://www.crossclassify.com/), a provider of AI-powered online account fraud prevention, required a robust Identity and Access Management solution to integrate with its services. They needed a system capable of handling Single Sign-On(SSO), identity federation, and multi-tenancy, catering to their B2B clients' diverse authentication requirements.

- [ZITADEL](http://www.zitadel.com) emerged as the ideal solution for CrossClassify's IAM requirements, offering features like secure authentication, Role-Based Access Control (RBAC), SSO, identity federation, and multi-tenancy. CrossClassify evaluated other vendors, including RedHat SSO (Keycloak), but chose ZITADEL for its cloud-agnostic deployment, SaaS offering along with self-hosting capabilities, and comprehensive technical support. The flexibility to run ZITADEL on any platform and its active community were also key deciding factors.

- By adopting ZITADEL, CrossClassify was able to efficiently develop their comprehensive authentication system and RBAC authorization in under 3 months. This implementation included the advantages of self-hosting and the flexibility for cross-platform scalability. Opting for ZITADEL instead of constructing a solution from the ground up, CrossClassify not only halved the development time frame—typically a 5-to-6-month endeavor—but also significantly minimized potential security risks.

For an insightful exploration into CrossClassify and their implementation of ZITADEL, we had the opportunity to speak with [Amir Moghimi](https://www.linkedin.com/in/amir-moghimi-10b4b624/), the co-founder and CEO of CrossClassify. Amir provided valuable insights into how CrossClassify integrates ZITADEL to strengthen the security and efficiency of their solution.


## CrossClassify: Pioneering AI-Enabled Fraud Detection

Founded in 2020 in Melbourne, and currently based in Brisbane, Australia, CrossClassify offers a B2B AI-enabled fraud prevention solution. The company currently focuses on providing cutting-edge, online account fraud prevention services that are affordable and easy to integrate into any mobile and web app. The core offering, a Software as a Service(SaaS) product, is designed to alleviate concerns around fake accounts and account takeovers. These issues, if not addressed, can lead to significant consequences for businesses, such as fines or the loss of operating licenses. 

Their primary customer base includes businesses that provide an application with sign-up and sign-in features. These businesses, particularly as they scale, become increasingly vulnerable to fake account creation and account takeover attacks. Currently, CrossClassify is particularly focused on serving the fintech and healthcare sectors. These domains face stringent regulatory requirements and handle sensitive data, where breaches can lead to substantial fines and severe reputational damage.

Startups and scale-ups are their early adopters. These companies, often working with tighter budgets, find CrossClassify's cost-effectiveness appealing – CrossClassify’s solution is at a price point that is at least ten times less expensive than their nearest competitor. Additionally, these businesses are typically more agile and quicker to adopt new technologies.

One of the key advantages of their solution is its ease of integration that is comparable to analytics SaaS platforms. Amir claims that most of their clients are able to integrate the system within a single day, allowing for swift testing and the ability to go live in just two weeks. This easy integration process, combined with their competitive pricing, makes CrossClassify an attractive option for businesses looking to enhance their security against fraud while adhering to regulatory standards.

### The User Journey with CrossClassify

The journey of a B2B user with CrossClassify begins with the initial step of signing up for the service. 

- Once signed up, a key is generated per environment (e.g., dev/staging/prod), which serves as the unique identifier and access token for their application. It allows secure data collection between the B2B user's app and CrossClassify's services.
- The next phase involves integrating CrossClassify into the B2B user's application. This is facilitated by CrossClassify's client-side SDK, which is available for various programming languages and platforms, catering to both web and mobile applications. This allows the application to start collecting behavioral data from their application users to detect potentially fraudulent activities.
- Following the client-side integration, the user integrates CrossClassify with their application’s backend. This step is optional but is strongly recommended for implementing security measures, such as blocking access to an account when CrossClassify's AI-driven algorithms detect an unusually high risk of fraud in real-time. 
- After integration, users in the B2B organization can log in and access CrossClassify's portal, where they can monitor and review flagged and blocked accounts. This feature provides valuable insights into end-user behavior and potential security threats, enabling businesses to make informed decisions about account activities.

<figure>
  <img
    src="/blog/2024-01-25-success-story-crossclassify-02.png" 
    width="100%"
    alt="CrossClassify in Action"
    style={{ margin: '0 auto' }}
  />
  <figcaption>

    Figure 1 - CrossClassify in Action

  </figcaption>
</figure>


## Problem and Solution

The primary need for CrossClassify was a centralized Identity and Access Management (IAM) system capable of handling both authentication and user management effectively. This system would play a crucial role when B2B users sign up for CrossClassify, managing their credentials and access rights while ensuring compatibility with their cloud-native infrastructure. 

For B2B customers integrating CrossClassify into their applications, the IAM system should facilitate authentication services. Moreover, in instances where these organizations use their own Identity Providers (IdPs), the IAM system must offer identity federation support. This feature allows them to authenticate with their pre-existing credentials across various IdPs, enhancing the user experience.

An essential requirement for the IAM solution was Single Sign-On (SSO). SSO is pivotal in ensuring a frictionless sign-in process for the B2B users across different services and applications, particularly vital in multi-application ecosystems in large organizations that demand consistent user authentication. CrossClassify wanted to offer SSO for clients who needed it via their enterprise plan. Large companies often wanted to use SSO for all of their internal systems, including CrossClassify’s fraud prevention portal.

### Criteria for IAM Selection

1. **Secure and Scalable Authentication**: A fundamental requirement was robust authentication to secure user sign-up and sign-in processes. This was vital for preventing fraudulent activities and ensuring system integrity.

2. **SSO and Identity Federation**: The IAM solution had to facilitate seamless integration with various IdPs used by CrossClassify's clients. They were also looking for SSO capabilities to cater to the needs of large organizations that prefer to integrate SSO across their internal systems. This integration should extend to their fraud prevention portal, allowing seamless access.

3. **Multi-Tenancy Support**: The solution had to be capable of supporting multiple B2B clients, reflecting a multi-tenanted architecture that could handle diverse requirements.

4. **Flexible Hosting Options**: A dual hosting approach was sought – a cloud-based solution with the option for self-hosting. This flexibility was necessary to meet specific client demands, especially for direct control over data and authentication processes.

5. **Cloud-Agnostic Deployment**: CrossClassify required an IAM solution that could be deployed across various cloud platforms like GCP and AWS. This cloud-agnostic feature would ensure compatibility and flexibility across different infrastructures.

6. **Reliable Support and SLA**: The vendor needed to provide dependable commercial support, backed by service level agreements (SLAs), particularly crucial for scenarios involving self-hosting configurations.

7. **Cost-Effective Solution** Catering to startups and scaleups, the IAM solution had to be budget-friendly, offering valuable features at a price accessible to early-stage businesses.

8. **Ease of Integration**: The solution had to be easy to implement, with a focus on reducing the time and resources required for integration, therefore enabling smooth adaptation and operational testing.

### Choosing ZITADEL

CrossClassify discovered ZITADEL through a Google search and chose it over other options like RedHat SSO (Keycloak) because it closely matched their outlined criteria. Amir mentioned that their team managed to develop the entire authentication framework and Role-Based Access Control (RBAC) on ZITADEL in a span of less than three months. He emphasized the advantage of ZITADEL in providing future flexibility for self-hosting and cross-platform compatibility—benefits not typically offered by standard cloud IAM solutions. Amir also pointed out that creating an IAM solution from scratch would not only have required a significantly longer development time but also would have introduced greater security risks.

Central to their decision was ZITADEL’s multitenancy support, enabling the management of multiple B2B clients within a single instance, each with the capability to self-manage users and roles. This setup was vital for addressing diverse login requirements and security policies across different client organizations.

ZITADEL’s SSO and identity federation capabilities were crucial, allowing seamless access needed for user applications and for the integration with various IdPs used by CrossClassify's clients, thereby facilitating a unified authentication experience. ZITADEL’s support for RBAC aligned with their need for precise user permission management. 

Its open-source nature and scalability catered to CrossClassify’s expanding client base, and the dual hosting options—cloud-based SaaS and self-hosting—offered the deployment versatility they required. The choice was further reinforced by the active development community around ZITADEL and the availability of comprehensive technical support.


## Solution Architecture and Deployment

In this setup, ZITADEL acts as the central IAM system that manages both direct authentication (for users without an external IdP) and federated authentication (for users with an external IdP). At present, CrossClassify uses ZITADEL’s cloud hosting solution.

CrossClassify leverages both Google Cloud Platform (GCP) and Amazon Web Services (AWS). Their infrastructure heavily utilizes serverless technologies, including Google Cloud Functions and AWS Lambda, which allows for scaling and resource management suited to the dynamic needs of their applications. In terms of data storage, they use a NoSQL approach, using MongoDB for its advanced querying and indexing capabilities and AWS's DynamoDB for its scalability and pay-as-you-go pricing. 

For their software development, Python is the programming language of choice for backend development, while the front end is built using React and TypeScript. The integration with ZITADEL is implemented through ZITADEL’s APIs. 

### ZITADEL and CrossClassify in Action

<figure>
  <img
    src="/blog/2024-01-25-success-story-crossclassify-03.png" 
    width="100%"
    alt="The Complete User Flow with CrossClassify and ZITADEL"
    style={{ margin: '0 auto' }}
  />
  <figcaption>

  Figure 2: The Complete User Flow with CrossClassify and ZITADEL

  </figcaption>
</figure>


1. **Organization and Project Creation**: In the dynamic collaboration between ZITADEL and CrossClassify, the process begins with the creation of an organization and a specific project within ZITADEL when a B2B customer registers with CrossClassify. This setup allows each customer to have an individually tailored security environment, where they can add users, configure [Role Based Access Control (RBAC)](https://zitadel.com/docs/guides/manage/console/roles), [multi-factor authentication (MFA)](https://zitadel.com/docs/guides/integrate/login-ui/mfa), [identity federation via external IdPs](https://zitadel.com/docs/guides/integrate/services), and [passkeys](https://zitadel.com/docs/guides/integrate/login-ui/passkey) at an organizational level, thanks to ZITADEL's support for [multi-tenancy](https://zitadel.com/docs/guides/solution-scenarios/b2b).

2. **API and Service User Setup in the Project**: In the project setup phase, B2B client applications are required to transmit behavioral data to CrossClassify each time a user logs in or performs other relevant actions. This is achieved through API calls to CrossClassify. Within ZITADEL, these client apps are identified as service users. For secure communication, a private-public key pair is generated for each service user using the [JSON Web Token (JWT) profile](https://zitadel.com/docs/guides/integrate/private-key-jwt#get-an-access-token). This key pair enables the service user to request tokens from ZITADEL's OIDC token endpoint, which are then used to access CrossClassify's protected APIs. To facilitate this process, an API application is also set up within the same ZITADEL project. This application is specifically configured to communicate with the CrossClassify API, using the token obtained with the service user's private key for authentication. The CrossClassify API, upon receiving a request, validates the access token by consulting ZITADEL's introspection endpoint, which then determines whether to grant or deny access based on the token's validity. For additional insights on API access and token introspection in ZITADEL, explore further in this detailed post: [API Access and Token Introspection - ZITADEL Blog](https://zitadel.com/blog/api-access-and-introspection).

3. **SDK Configuration**: The client-side SDK is set up with specific ZITADEL OIDC client configurations. This includes essential details like the service user's private key, the token endpoint, and the API Client ID and Secret. Alternatively, an API key may be used if the JWT profile is implemented for API security. These elements, obtained during the service user and API creation phase, enable the SDK to effectively manage the login process and token handling. Additionally, the SDK facilitates interaction with CrossClassify’s fraud detection system by securely communicating with the API.

4. **End-User Interaction**: In this phase, B2B applications utilize the assigned private key to transmit end-user behavioral data to CrossClassify. ZITADEL plays a critical role in verifying the validity of this key and identifying its assigned user. This validation process is essential for ensuring that the data is securely and accurately relayed to the CrossClassify API for processing. Based on the fraud score returned, the B2B application can grant or deny access to the end user. 

5. **Portal Access**: Within ZITADEL, users assigned to an organization gain access to the CrossClassify portal. Here, they can log in to view end-user data and execute a range of tasks tailored to their specific roles and permissions. This login functionality and access control are efficiently managed by ZITADEL.

<figure>
  <img
    src="/blog/2024-01-25-success-story-crossclassify-04.png" 
    width="100%"
    alt="User Activity of End-User in the CrossClassify Portal"
    style={{ margin: '0 auto' }}
  />
  <figcaption>

  Figure 3: User Activity of End-User in the CrossClassify Portal 


  </figcaption>
</figure>

<figure>
  <img
    src="/blog/2024-01-25-success-story-crossclassify-05.png" 
    width="100%"
    alt="Reviewing User Registrations in the CrossClassify Portal "
    style={{ margin: '0 auto' }}
  />
  <figcaption>

  Figure 4: Reviewing User Registrations in the CrossClassify Portal 

  </figcaption>
</figure>

<figure>
  <img
    src="/blog/2024-01-25-success-story-crossclassify-06.png" 
    width="100%"
    alt="Summary Statistics in the CrossClassify Portal"
    style={{ margin: '0 auto' }}
  />
  <figcaption>

  Figure 5: Summary Statistics in the CrossClassify Portal 

  </figcaption>
</figure>


## User Experience and Challenges in Implementing ZITADEL

CrossClassify's experience with implementing ZITADEL has been largely positive. They found ZITADEL's documentation to be very helpful and sufficiently detailed, which facilitated a smoother integration process. On occasions where additional assistance was required, the technical support provided by ZITADEL proved to be highly responsive and effective, addressing their queries directly and efficiently.

One particular aspect CrossClassify wished for improvement was the customization of sign-up and login pages in ZITADEL's SaaS option. They found that more flexibility in this area would enhance their user experience and better align with their branding needs. Recognizing this need, ZITADEL plans to introduce functionality for full customization of the sign-up and register pages within this year, aiming to provide users with more control and alignment with their unique branding and user experience requirements.

Despite this challenge, what CrossClassify appreciates the most about ZITADEL is its cloud-native and modern design. 


## Future Plans

Currently, CrossClassify primarily utilizes the cloud-based SaaS hosting of ZITADEL. However, they have a strategic plan to expand their hosting options by deploying a self-hosted version of ZITADEL, specifically tailored for certain clients in the future. This move is aimed at providing more customized and controlled hosting solutions to meet the diverse needs of their clientele.

Regarding their service reach, CrossClassify is predominantly active in Australia and Europe at present. Nonetheless, they are not restricting their services geographically and are open to expanding their service offerings to other regions, aligning with their growth strategy and client demand.


## Testimonials

<img
  src="/blog/2024-01-25-success-story-crossclassify-07.jpg"
  width="250px"
  alt="Portrait of Amir Moghimi"
/>

“We needed an SSO solution that can be deployed independenty of the cloud provider and self-hosted if required by our clients. ZITADEL is a great choice because it is designed to be deployed as containers, which makes it straightforward to run on any platform and provides commercial SLA with technical support for self-hosting.”

-[Amir Moghimi](https://www.linkedin.com/in/amir-moghimi-10b4b624/), Co-Founder and CEO, [CrossClassify](https://www.crossclassify.com/)



Discover how CrossClassify leverages ZITADEL to offer B2B customers advanced fraud prevention and streamlined identity management, enhancing security in their digital ecosystems.

Built with ZITADEL: CrossClassify's Fraud Prevention Solution


<img
    src="/blog/2024-01-18-upcoming-features-2024-01.jpg" 
    width="100%"
    alt="Banner Image"
    style={{ margin: '0 auto' }}
  />

## Upcoming Features

After [a year of solid growth and improvements in 2023](https://zitadel.com/blog/recap-2023), we are already gearing up for what 2024 has in store for ZITADEL. Our focus is always on how we can make things better for you, and it’s not just about keeping up; it's about paving the way forward.

In this post, we want to give you a sneak peek into some of the key features on our [roadmap](https://github.com/orgs/zitadel/projects/6/views/1) for 2024. These features and enhancements will help make ZITADEL more intuitive, responsive, and, most importantly, aligned with your needs. We are excited to share these developments and continue our journey together in enhancing your experience with our platform. Here are the top features and offerings for 2024:

### 1. Authentication Examples and SDKs for the Most Used Languages

ZITADEL will be rolling out more easy-to-understand examples and SDKs this year. Whether you are working on a frontend or backend project, you will find clear, hands-on examples that show you how to integrate ZITADEL's authentication into your app. For frontend apps, you will see more examples with session management, user roles, and even how to handle user profiles. For the backend, you will see examples on how to handle various types of access control. All of them will use recommended OIDC libraries or SDKs. 

After setting the stage with these examples, ZITADEL's next move is to bring in more SDKs for languages like Java, Python, and PHP. We are planning to take them up a notch, showing you how to interact with ZITADEL APIs for more complex tasks, like managing user profiles or setting up security features. There will also be a wide range of languages and integration patterns. Whether you are coding in Python, PHP, or Java, or working on a mobile app, there is something in the pipeline for you. Plus, we are looking into making ZITADEL play nice with popular third-party tools. See this [epic](https://github.com/zitadel/zitadel/issues/5124) for more details. 

### 2. ZITADEL Cloud’s Data Region Expansion: Introducing US and EU Hosting in 2024

This year, ZITADEL is taking a significant step forward in its service offerings with the introduction of data regions in the US and EU (European Union). This move is all about giving customers more control and assurance over where their data is hosted.

Data location is a big deal. It's about knowing the specific region, which could be a country or a group of countries, where your data lives. ZITADEL understands that for many businesses and users, where their data is stored is as important as how it is stored. 

ZITADEL's cloud service is already offering a range of regions through Google Cloud Platform. These include:

- **Global:** This is the broadest option, where your data can be hosted in any of the cloud regions offered by ZITADEL’s provider.

- **Switzerland:** For those who prefer their data to stay in Switzerland, this option ensures hosting exclusively within the Swiss region.

- **GDPR Safe Countries:** This is for those who want to align with GDPR guidelines. Data is hosted within EU member states and other countries recognized as adequate under GDPR.

And the big news for this year:

- **US and EU Regions:** Recognizing the demand and importance of these regions, ZITADEL is set to offer cloud instances in both the US and the EU. This expansion means increased flexibility and more choices for businesses and individuals with specific needs or preferences for data hosting in these areas. We expect this expansion to go live by early Q1. As always, keep an eye on our website for the most current information regarding available regions.


### 3. Say Hello to Customizable User Schemas

ZITADEL is about to roll out a game-changer for businesses managing user data—[customizable user schemas](https://github.com/zitadel/zitadel/issues/6433)! This update responds to the growing demand for flexibility in user information management, allowing businesses to tailor user data fields to their specific needs and compliance requirements.

The new user schema feature in ZITADEL enables complete customization of user data fields. Businesses now have the freedom to determine which fields are necessary and which are not, eliminating the need to fill irrelevant fields. This flexibility also extends to defining which fields users can manage on their own and which ones require admin oversight.

Most importantly, despite the customizations, the user sign-in process will remain straightforward. ZITADEL ensures that the system works seamlessly without additional configurations. The update also promises efficient performance, with validations happening swiftly to ensure a smooth user experience. We are keeping it simple and user-friendly. 

We will enhance the user object structure to include a variety of fields like unique IDs, schema types, contact information, and custom profile fields, aligning with various user types. The introduction of a diverse range of authenticators will further enrich user interaction, catering to different security and access needs.

Incorporating JSON Schema Validation, the new feature allows robust validation of fields, ensuring data integrity and compliance. This flexibility also extends to management methods, with comprehensive options for creating, updating, and deleting users and schemas. Keep an eye out for this; it's going to make life a whole lot easier!


### 4. Custom Actions for Every Event and API Request

ZITADEL will be [extending actions to let you create custom actions](https://github.com/zitadel/zitadel/issues/7235) for every event, API call, and the functions you are already used to in ZITADEL. This means you can now tailor custom workflows to fit your exact needs. With this feature, you will be able to add your code, your own rules, right into ZITADEL's events and API calls. Whether it's an event in the system or an API request you are making, you will be able to hook in custom actions. 

- **Event-Based Actions:** You can attach actions to specific events within ZITADEL. After the event is stored, you decide when your custom action should kick in.

- **API Request Actions:** Similarly, for any API request, you can define actions to occur at different stages—during the request or in the response phase.

- **Multi-Event Actions:** And here's the kicker-you can create actions that run across multiple events. Think of it as a way to implement a consistent response or workflow across various parts of the system.

For developers, this feature is a game-changer. It means you can integrate ZITADEL more deeply into your systems and workflows. You are no longer just reacting to a few points during code execution—you gain the full flexibility of the programming language of your choice to customize the behavior of ZITADEL and react to events in real time. This level of customization is unprecedented and will unlock new ways of leveraging ZITADEL for your projects.



### 5. Streamlining User Management with Outbound Provisioning via SCIM

In 2024, ZITADEL will roll out a pretty cool feature that's going to make life a lot easier for businesses using Single Sign-On (SSO)—[outbound provisioning with SCIM (System for Cross-domain Identity Management)](https://github.com/zitadel/zitadel/issues/6601), and it's all about simplifying how user accounts sync up with external systems and applications.

Many SSO systems need a user account to already exist in their platform. Plus, these accounts must stay updated, especially when someone's status changes in the identity provider. This can get tricky when you're juggling multiple systems.

Understanding the need for pre-existing user accounts in many SSO systems, and the importance of keeping user statuses in sync with Identity Providers (IdPs), ZITADEL's solution focuses on extended actions. These allow for real-time updates and custom integrations with third-party systems, overcoming the challenges posed by standard SCIM implementations. This approach is not only more flexible but also caters to diverse use cases, offering businesses the ability to tailor their user management workflows.

Extended actions offer several advantages:
- They adapt to various third-party systems, allowing for a more personalized approach to user management.
- Changes in user accounts are instantly reflected across systems, ensuring up-to-date information.
- Supporting SCIM and generic API endpoints, this feature broadens the scope of integration possibilities.

The new feature enhances functionality through:
- Changes in user status automatically initiate actions, enabling immediate response to user management events.
- Fine-tuned control over actions based on user metadata or attributes.
- Options for executing REST calls or utilizing a SCIM module, enhancing data synchronization flexibility.
- Including all aspects of user management like creating, reading, updating, deleting, enabling/disabling users, and schema discovery.
- Detailed Documentation and Testing: Ensuring ease of integration and understanding.


### 6. Enhancing Team and Organization Onboarding with Improved Invitation Flows

ZITADEL is addressing a vital need in the B2B sector: [better and more intuitive ways to invite team and organization members](https://github.com/zitadel/zitadel/issues/7083). Recognizing the importance of streamlined team management and onboarding processes, ZITADEL is set to introduce enhanced invitation flows that cater to the specific requirements of business-to-business scenarios.

The proposed solution focuses on empowering managers to invite new users to their organization effortlessly. Here’s what it entails:

- **Email Invitations:** Users can be invited through an email containing a registration link specific to the organization from which the invite was sent.

- **SSO Integration:** If Single Sign-On is enabled, invitees have the option to sign up using an external identity provider, enhancing the ease of the onboarding process.

- **Customizable Email Texts:** The content of the invitation emails can be tailored to match the organization's tone and branding, offering a personalized touch.


This update is more than just about inviting members; it’s about enabling comprehensive team management within an application. This includes creating a new organization, appointing an admin user, configuring security settings like SSO and 2FA, and assigning roles to users. ZITADEL aims to make this process as intuitive as possible, addressing the common challenge of balancing authentication, authorization, and self-service configuration in cloud solutions.

ZITADEL recognizes that creating a custom onboarding experience is a frequent requirement. The new update will make it easier to understand and implement various methods for user registration, whether it’s through username/password, external IdPs, or social logins.
This feature will further enhance the critical aspects of the B2B onboarding process. 


### 7. User Group Authorizations

In 2024, ZITADEL will also introduce [user group authorizations](https://github.com/zitadel/zitadel/issues/5822), a game-changing feature for administrators. This update streamlines the way permissions and roles are managed by leveraging group-based authorizations. Its key advantages are:

- **Group-Based Access Control:** Admins can now manage permissions at the group level, rather than for individual users, saving time and reducing complexity.

- **Easy User and Group Management:** Features include creating, updating, searching, and deleting groups. Users can be added effortlessly or removed from these groups.

- **Merged Authorizations:** A standout feature where individual user roles are seamlessly combined with their group roles, enhancing flexibility and ensuring comprehensive access rights.

- **Integrated Authorization Visibility:** Group authorizations are integrated into tokens and user information, maintaining consistency across the platform.

In essence, ZITADEL's user group authorizations simplify and enhance access management, making it more efficient for administrators, especially in larger organizations. 


## Let's Go

As we wrap up our preview of what 2024 holds for ZITADEL, we are genuinely excited and hope you are too. A lot of hard work is going into developing these features, and we're eager for you to start using them. Make sure to stay tuned for our release announcements.

Your continuous support and feedback are what drive us. So, thank you for being an integral part of our journey. Here's to a groundbreaking year ahead!







This article provides an insightful overview of the exciting new features and updates that ZITADEL is set to roll out in 2024.

Exciting ZITADEL Features to Watch for in 2024

As we approach the end of 2023, it's an excellent time to reflect on how ZITADEL progressed throughout the year. We've remained committed to our promise of continuous innovation and delivering exceptional user experiences, as we set out to do at the beginning of the year.

ZITADEL significantly enhanced the developer experience by focusing on two key areas: API design and documentation. Firstly, we made a significant shift in our API design, moving towards a [resource-based approach](https://zitadel.com/blog/resource-api). This shift wasn't just a change; it was a strategic move to make our APIs more intuitive and developer-friendly. 

Then there's our documentation overhaul, making it more informative and user-friendly. This revamp was coupled with a streamlined onboarding process, designed to be quicker and more intuitive, particularly benefiting new users who are integrating ZITADEL into their systems for the first time. 

Here's a look back at the significant milestones we achieved:

## A Detailed Recap of ZITADEL's Product Features and Enhancements in 2023

###  Authentication and Identity Management

- **[Configurable Social/Enterprise Identity Provider Templates](https://zitadel.com/docs/guides/integrate/identity-providers):** We launched new social and enterprise SSO options, expanding our identity provider support to include Google, Github, Gitlab, Microsoft Azure AD, and Apple.
- **[Self-Hosting with Terraform](https://zitadel.com/docs/guides/manage/terraform/basics):** Simplified management of ZITADEL resources for a seamless setup.
- **[OIDC Version 2.0 Release](https://zitadel.com/blog/oidc-v2-release):** This was a significant update to our OpenID Connect library, including device authorization and token exchange.
- **[LDAP Login](https://zitadel.com/docs/guides/integrate/identity-providers/ldap):** Integration with Active Directory/LDAP for enabling the use of legacy systems as identity providers. 
- **[Device Authorization Grant](https://zitadel.com/blog/device-authorization):** Acknowledging the challenge of text input on certain devices, we implemented OAuth 2.0 Device Authorization Grant for a smoother user experience on input-constrained devices.
- **Email and SMS OTP Support:** Introduced one-time password for two-factor authentication.
- **ZITADEL API V2:** We've boosted our API with enhanced user registration and email verification features. Now in the beta stage, it allows you to create custom login interfaces and enables effective session management. Additionally, it supports integration with external providers, multifactor authentication options like TOTP and U2F/WebAuthN, streamlined password reset processes, and customizable methods for crafting your own login UI. This upgrade is all about giving you more control and flexibility.

### Security and Compliance

- **Event Audit Log with Advanced Filters and Threat Detection:** Our new audit log feature provides a comprehensive view of all actions and modifications, enhancing security and compliance capabilities.
- **[Client Credentials](https://zitadel.com/docs/guides/integrate/client-credentials) as JWT & PAT Alternative:** We introduced a third authentication method for service accounts, offering more flexibility.
- **Improved Password Change Notifications and Logging:** Enhanced security measures for user account management.
- **Support for Multiple Hashing Algorithms, Including PBKDF2:** Strengthened password hashing and migration capabilities. See the [ZITADEL passwap package]( https://github.com/zitadel/passwap), which provides a unified implementation between different password hashing algorithms. 
- **Technical Advisories and Updates:** We introduced [technical advisories](https://zitadel.com/docs/support/technical_advisory) to inform users about critical issues and updates for seamless operations.
- **Amplified Penetration Testing:** Complementing our secure coding practices, we intensified [third-party penetration tests](https://zitadel.com/blog/tags/pentest) and continued to encourage researchers to responsibly test and disclose vulnerabilities through our [disclosure policy](https://zitadel.com/docs/legal/policies/vulnerability-disclosure-policy). Adhering to this process, we consistently published [security advisories on GitHub](https://github.com/zitadel/zitadel/security/advisories) and proactively informed affected users and customers about any vulnerabilities.

### Developer Experience and Customization

- **Custom Claims and Role Integration:** Actions now allow for enhanced token customization, such as flat role claims and custom claims. This adds flexibility to include additional attributes in SAML responses as well.
- **Customizable Login UI:** ZITADEL now allows businesses to craft their own user interface for login, offering greater flexibility and personalization, along with guides to customize the login experiences using ZITADEL APIs.
- **Language Support:** Added Polish, Japanese, Spanish, Bulgarian, Macedonian, Brazilian Portuguese, Russian, and Dutch thanks to many contributions from our community.
- **Improved Onboarding Process:** An interactive in-app approach for a smoother user experience.

### Platform Enhancements and Integrations

- **Event Store Optimizations:** With ZITADEL's unique approach to event sourcing and CQRS, users can follow along the change track of the system. During the year, we took a big step forward in improving performance and parallel requests, and we prepared the storage layer for future improvements. Stay tuned for the upcoming blog series, which covers all the details of our journey. 
- **General Availability of PostgreSQL Support in ZITADEL:** PostgreSQL support is now fully integrated and generally available in ZITADEL, complete with Enterprise support. For more details, visit our guide on [managing databases with ZITADEL](https://zitadel.com/docs/self-hosting/manage/database).
- **Migration Guides:** We've developed thorough guides to smoothly transition your systems from platforms like [Auth0](https://zitadel.com/docs/guides/migrate/sources/auth0) and [Keycloak](https://zitadel.com/docs/guides/migrate/sources/keycloak) to ZITADEL, ensuring a hassle-free migration experience.


## Team and Community Updates

<figure>
  <img
    src="/blog/2023-12-29-recap-2023-01.png" 
    width="100%"
    alt="Team Retreat"
    style={{ margin: '0 auto' }}
  />
  <figcaption>
  The ZITADEL Team in Bucharest in October 
  </figcaption>
</figure>

### Welcoming New Team Members

[Tim Mohlmann](https://www.linkedin.com/in/tim-mohlmann/) joined as a Software Engineer, enhancing our development team with his technical expertise. Next, [Jason Burkhead](https://www.linkedin.com/in/jasonburkhead-06/) came on board as an Account Executive, bringing a new dynamism to our sales strategies.

### Team Retreats

Our first retreat in May in the scenic town of Habkern in Interlaken was a blend of team bonding and strategic planning amidst the beauty of Switzerland. In October, the team gathered in Bucharest,  absorbing the vibrant culture of Romania and fostering strong team unity.

### Community Engagement and Achievements

- **Contributions from the Community:** We had over a hundred contributions this year and would like to acknowledge and thank all our external contributors for their significant role in enhancing ZITADEL's features and functionalities.

- **Discord Community Grows to 1500 Members**: This milestone is a clear reflection of the engaging nature of our platform and the supportive spirit of our user base. We have an expanding community of enthusiasts and professionals who actively contribute to and benefit from our [Discord channel](https://zitadel.com/chat).

- **5750 GitHub Stars**: ZITADEL hit 5750 GitHub stars, a clear indicator of our growing influence and acceptance in the open-source community. This achievement is a collective success, made possible by the incredible support of our community members. Our [GitHub repository](https://github.com/zitadel/zitadel) continues to be a hub of innovation and collaboration. 


## New Updated Subscription Model: Aligning with Customer Needs

In 2023, ZITADEL took a customer-centric approach to update our subscription model for ZITADEL Cloud. 

In response to feedback from our users, we transitioned to using **Daily Active Users (DAUs)** as the primary metric for our subscriptions. We designed this shift from the previous request-based model to provide a clearer, more predictable structure that closely aligns with user engagement. The updated subscription plans are now more intuitive and tailored to actual usage, ensuring that our services resonate with your daily operations. The plans were made available for all customers, with existing subscribers given the option to switch at their convenience.

For a comprehensive overview of the subscription model, please see [ZITADEL's New Pricing](https://zitadel.com/pricing). Here, you'll find all the necessary details to understand how these changes might affect your current usage and future plans.

This update was a significant step in ZITADEL's journey this year, reflecting our commitment to evolving with market needs and enhancing customer experience.


## Recognition and Achievements in 2023

- **Featured in Star History Monthly Pick**: In January 2023, ZITADEL was featured in the Star History Monthly Pick. This feature by Star History HQ delved into the story behind our project, showcasing our journey and the impactful strides we've made in the identity and access management domain. The article is available for a detailed read at [Star History](https://star-history.com/blog/star-history-monthly-pick-202301).

- **Top 100+ Developer Tools for 2022 by StackShare**: ZITADEL's commitment to simplifying identity and access management for developers was further acknowledged when we were listed among the Top 100+ Developer Tools for 2022 by StackShare. For more information, visit [StackShare](https://stackshare.io/posts/top-developer-tools-2022).

- **Fastest-Growing Open-Source Startups in Q1 2023 ROSS Index**: The first quarter of 2023 brought us another significant milestone. ZITADEL was ranked among the fastest-growing open-source startups in the Q1 2023 ROSS Index. We extend our gratitude to Runa Capital for this recognition. To learn more about our ranking, visit the [ROSS Index](https://runacap.com/ross-index/q1-2023).

- **Switzerland's Most Influential Information Services Startups for 2023**: ZITADEL was honored with this award by Startup Bubble, recognizing our significant role in the information services sector. They positioned ZITADEL prominently in the fields of cybersecurity and web security in Switzerland. For more information about this recognition, visit [Startup Bubble](https://startupbubble.news/what-are-switzerlands-most-influential-information-services-startups-in-2023).

## Thank You

![Thank you](/blog/2023-12-29-recap-2023-02.png)

These updates highlight ZITADEL's commitment to providing a robust, secure, and user-friendly platform. We've made changes across the board to ensure our platform not only meets but exceeds the expectations of our users and the developer community.

As we wave goodbye to 2023, we're buzzing with excitement for the new horizons 2024 will bring. A huge shoutout to our awesome community and customers—your support, feedback, and ideas have been the secret sauce in ZITADEL's growth this year.

So, here's raising a toast to more innovation and even better user experiences! Wishing you all a fantastic and happy 2024! 



This post looks back at the pivotal moments and key updates that have shaped ZITADEL's journey in 2023

ZITADEL's 2023 in Review: Key Highlights and Updates


<img
    src="/blog/2023-12-21-success-story-open-systems-01.png"
    width="100%"
    alt="Banner Image"
    style={{ margin: '0 auto' }}
  />

## Key Outcomes

- [Open Systems](https://www.open-systems.com/) has adopted self-hosted [ZITADEL](https://zitadel.com/) to modernize their identity and access management. This adoption provides a robust authentication framework for their customer portal, serving a large customer base with diverse global networks and is pivotal in managing secure access to their backend systems for both admin users and potentially end users in the future.

- The decision to switch to ZITADEL was driven by its seamless integration with various third-party identity providers, cloud-native design, self-hosting capability, and adaptability in accommodating new features and custom requirements. This strategic choice allows Open Systems to stay ahead with a modern authentication stack, offering significant improvements over the previous legacy RADIUS-based system and well-known solutions like Auth0 and Microsoft AD (now Entra ID).

- This shift to a more advanced, off-the-shelf solution aligns them with current identity management trends. It drastically cuts down development time, with **the setup now accomplished in just 15 minutes per customer, as opposed to the previous duration of 24 hours**. Furthermore, it enhances system compatibility across diverse Identity Providers (IdPs) and streamlines risk management effectively.

## Introduction

[Open Systems](https://www.open-systems.com/) is a leader in networking and cybersecurity, primarily focusing on the Secure Access Service Edge (SASE) domain. With a customer base of around 200, primarily large-scale organizations with global networks, Open Systems focuses on providing robust security and network solutions. The key aspect of their service includes a customer portal for service management, emphasizing the importance of authentication and identity management. This portal serves several thousand users, necessitating a strong authentication solution. Open Systems has effectively addressed their authentication requirements by choosing ZITADEL, a decision influenced by its capabilities and advantages over notable solutions like Auth0 and Microsoft AD (currently referred to as Entra ID). 

We had an insightful discussion with [Simon Stäheli](https://www.linkedin.com/in/simon-stäheli-179a6a78/), product owner and manager for the authentication platform team at Open Systems, about how they leverage ZITADEL for their authentication needs.  

## Open Systems Managed Secure Access Service Edge (SASE)

The Open Systems Managed SASE solution addresses the critical challenges that businesses face today, especially in enabling secure and efficient access for a globally distributed workforce and leveraging cloud capabilities for business empowerment, all while minimizing costs and risks.

Features of Open Systems Managed SASE:

- **Comprehensive Framework**: The Managed SASE solution unifies essential components like Software-Defined Wide-Area Network (SD-WAN), Firewall, Secure Web Gateway(SWG), Cloud Access Security Broker (CASB), and Zero Trust Network Access(ZTNA) into a single framework. This integration facilitates secure connectivity across cloud and hybrid environments, simplifying network and security management.
- **Unified Data Platform**: A centralized data platform underpins Open Systems Managed SASE. This unified approach allows for consistent policy enforcement across global networks. Enhanced with predictive analytics, this platform proactively identifies potential issues.
- **Customer Portal**: The solution is delivered as a 24×7 managed service, offering an easy-to-use customer portal for visibility and control. This service model includes onboarding, unlimited support, and lifecycle management.

The Open Systems Managed SASE stands out for its ability to facilitate seamless work from anywhere, integrating a cloud-delivered network and security architecture that efficiently allocates resources, and eliminates the need for traditional network components and VPNs. It incorporates Zero Trust principles for secure access to cloud resources.

## Customer Focus and Differentiation at Open Systems

Open Systems mainly caters to large-scale organizations with an extensive global presence, often including companies with over 20 branches and exceeding 1,000 employees. This client base typically comprises sectors like insurance, banking, and major international organizations. The company's specialty lies in building and managing global networks, efficiently interconnecting numerous sites—some clients have over 300 locations.

A key distinction of Open Systems is their customer portal, which goes beyond typical service offerings. The portal provides direct access to engineers for issue resolution or consultancy, enabling immediate and expert-level interaction. This approach contrasts with the common industry practice of multi-level support structures, where initial responses often come from first-level support. The customer experience at Open Systems is also defined by a longstanding commitment to self-provisioning. While this approach is becoming more common in the industry, Open Systems has been integrating it into their services for quite some time.

Their service offerings combine traditional and modern solutions. This hybrid approach allows clients to choose between physical appliances ('old-world' solutions) and cloud-native services ('new-world' solutions) depending on their specific location needs. Such flexibility in service offerings is relatively rare among their competitors, who typically specialize in either traditional or cloud-based solutions.

Integrating Open Systems' services into a client's network includes integrating critical network infrastructure components like WANs, firewalls, web proxies, and email security, creating network schemas, defining policies, and configuring and implementing these policies.

## The Customer Portal 

The [Customer Portal](https://www.open-systems.com/sase/customer-portal/) of the Managed SASE offering is a tool designed for managing the SASE services.

<figure>
  <img
    src="/blog/2023-12-21-success-story-open-systems-02.png" 
    width="100%"
    alt="Customer Portal"
    style={{ margin: '0 auto' }}
  />
  <figcaption>

    Figure 1 - The Open Systems Customer Portal

  </figcaption>
</figure>


### Key Features and Functions

- **Real-Time Insights and Analytics**: The portal provides a comprehensive overview of network and security postures, offering real-time reports, tools, and trend analysis. 
- **Collaboration and Transparency**: It acts as a collaborative platform, sharing technical data between clients and Open Systems engineers. Users can view service statuses, analyze network performance, and observe current threats, mirroring the visibility available to engineers. The integrated ticketing system offers detailed configuration views and operational metrics.
- **Audit and Compliance**: An embedded audit trail in the portal ensures that every change is documented, enhancing transparency and compliance.
- **Network Health Monitoring**: The portal facilitates detailed mapping of network connections and health, enabling users to prioritize and address critical issues promptly.

## The Problem

Open Systems faced substantial challenges in identity and access management, primarily stemming from the need to modernize their authentication systems, thereby reducing technical debt, and effectively serving a diverse customer base. With over 30 years in the industry and a business model more than two decades old, the company had historically relied on legacy systems, including a self-developed authentication solution based on [RADIUS](https://en.wikipedia.org/wiki/RADIUS). 

The primary issue was the lack of an identity management solution that could seamlessly interface with the identity providers (IdPs) used by their 200 customers. Given that the majority of these customers used Entra ID for account management, with others utilizing platforms like Auth0 or Okta, it was important for Open Systems to adopt a system compatible with these varied third-party IdPs. This need for compatibility and seamless integration was pivotal in their search for a new solution.

Open Systems required a solution that offered the flexibility of self-hosting while ensuring robust support and ongoing development. This requirement ruled out solely cloud-based solutions and self-hosted, open-source options that lacked substantial backing and support.

## The Solution

ZITADEL emerged as the chosen solution for Open Systems after they evaluated various options, including well-known services like Auth0 and Keycloak. The decision leaned towards ZITADEL due to its alignment with Open Systems' specific technical and operational requirements, and the limitations encountered with other cloud services. Interestingly, their discovery of ZITADEL through social media interactions presented a solution that closely matched their specific needs.

The primary factors that made ZITADEL an appealing choice for Open Systems are:

- **Cloud-Native Design**: ZITADEL's architecture is inherently cloud-native, built to operate efficiently in Kubernetes environments. This modern approach to product design was crucial, especially compared to competitors whose products were not developed with a cloud-native focus.

- **Integration with Third-Party IdPs**: A crucial requirement for Open Systems was the ability to integrate seamlessly with various third-party identity providers (IdPs) used by their clients. ZITADEL's provision of IdP templates for easy identity brokering or federation with these third-party IdPs was a key feature that met Open Systems’ needs.

- **Self-Hosting with Support**: Open Systems valued the ability to self-host the identity management solution while still receiving robust support. ZITADEL offered this balance, providing a self-hosted solution with a solid support model—a combination that was lacking in purely cloud-based solutions or open-source products without substantial backing.

- **Rapid Development Cycle**: ZITADEL's development life cycle stood out, with frequent releases (every two weeks) allowing for quick bug fixes and feature updates. This agility was a significant improvement over previous experiences where updates and new feature implementations were much slower.

## Solution Architecture and Deployment 

The primary application of ZITADEL within Open Systems is centered around their customer portal, where it serves to authenticate users accessing the SASE services. The portal application is designed with a frontend built in Typescript and a backend developed using Java. Currently, the utilization of ZITADEL is predominantly by the administrators or IT teams of Open Systems' clients. For these users, the interaction with ZITADEL occurs during essential processes such as logging in or resetting passwords within the customer portal. Internally, ZITADEL functions as the Identity Provider (IdP) for Open Systems, employing the best practices of the OpenID Connect (OIDC) standard for authentication. The system currently utilizes opaque tokens for security purposes, but they are considering a transition to JSON Web Tokens (JWT) soon. 

In terms of configuration within ZITADEL, Open Systems makes use of a single instance that includes all their customers. These customers, amounting to about 200, are each represented as separate organizations within ZITADEL, with the number of IT administrators per organization ranging from 3 to 1000. The system uses ZITADEL's [custom claims and action features](https://zitadel.com/blog/custom-claims) to import data from third-party IdPs, including essential information like contact details, job titles, and roles. This data is then efficiently distributed to other products, ensuring streamlined and consistent information management across the board.

To access the customer portal via third-party logins, Open Systems has configured and managed the[ IdP federation between their clients' identity providers and ZITADEL](https://zitadel.com/docs/guides/integrate/identity-providers). A majority of their clients, around 80%, use Microsoft's Entra ID for internal account management. 

<figure>
  <img
    src="/blog/2023-12-21-success-story-open-systems-03.png" 
    width="100%"
    alt="Architecture Diagram"
    style={{ margin: '0 auto' }}
  />
  <figcaption>

    Figure 2 -User Identity and Access Management with ZITADEL

  </figcaption>
</figure>


Open Systems' decision to self-host, rather than use a cloud service provider, is driven by a combination of compliance requirements and the need for operational control. For example, working with clients in the finance sector imposes specific contractual obligations that necessitate a higher degree of control over how and where data is processed and stored. 

When a company like Open Systems considers using a cloud or Software as a Service (SaaS) provider, this external provider becomes a subprocessor. They would be processing data on behalf of Open Systems (who is the primary data processor). Adding a new subprocessor in such a regulated environment is not a simple task—it often involves a thorough vetting process to ensure compliance with various data protection laws and industry-specific regulations. This process can be time-consuming, often taking several months, due to the need for careful review, risk assessments, and possibly contract negotiations to ensure all compliance requirements are met.

Therefore, by opting to self-host, Open Systems avoids the complexities and delays associated with adding a new subprocessor. Self-hosting ZITADEL gave them the flexibility to fulfill that requirement, and they decided to integrate it into their existing Kubernetes cluster. 

The core of their deployment is a mid-sized Kubernetes cluster, which includes various backend systems of the SASE, the customer portal, and observability tools. They make use of the [ZITADEL Terraform provider](https://zitadel.com/docs/guides/manage/terraform/basics) to manage ZITADEL resources, which allows them to efficiently automate and manage ZITADEL configurations, ensuring streamlined deployment and consistency across their cloud environments. 


## Product Experience, Challenges, and Support

### Efficiency in Authentication 

Simon highlighted that the switch to ZITADEL has greatly simplified their process of configuring and deploying authentication mechanisms for each customer. This improvement is significant compared to their previous system, which relied on managing local accounts and using older protocols like RADIUS and LDAP. With ZITADEL, the process of setting up and integrating authentication services for a new customer – including configuring identity providers, user access, and security policies – is now notably quicker, typically completed in about 15 minutes. Previously, this setup process could take up to 24 hours, which required deploying a host into the customer's network followed by the configuration of RADIUS and LDAP. This showcases the efficiency benefits of a modern IdP system.

### Challenges 

Open Systems encountered several challenges, primarily when migrating to ZITADEL. Simon highlighted that the most significant hurdle was updating the existing username patterns and naming conventions to conform to ZITADEL’s system. Given the diversity and complexity of their user base, this task was far from trivial. Open Systems had to account for numerous unique cases and intricacies inherent in their legacy system, making the transition to ZITADEL somewhat challenging.

### Flexible Feature Roadmap

Despite this challenge, ZITADEL's flexibility, particularly in introducing features to its frequent release cycle, was key in managing Open Systems' transition effectively. He noted that while about 90% of their required features were already in ZITADEL, for the remaining 10% that needed customization, Open Systems worked closely with the ZITADEL team. This collaboration facilitated the timely introduction of new features into ZITADEL’s existing release cycle, effectively meeting Open Systems' specific needs.

### Consultancy and Support

According to Simon, a key aspect of the implementation process was the consultancy and support provided by ZITADEL, including the valuable assistance of a dedicated Technical Account Manager (TAM). This professional guidance went beyond just the technical features of the product; it also covered broader aspects of the transition process. The involvement of the TAM was particularly beneficial in aligning Open Systems' future goals with ZITADEL's capabilities, offering insights into potential opportunities and solutions. 

## Future Plans

Open Systems is still in the process of migrating to ZITADEL, with their immediate focus on tracking the transition of users from their old authentication platform to ZITADEL. Looking ahead, they are contemplating broader applications of ZITADEL within their operations. 

One of the key plans under consideration is the extension of ZITADEL’s capabilities to authenticate end users, especially for client VPN and Zero Trust network services. Currently, ZITADEL's use is predominantly by the IT administrators of their clients, but extending its application to end users would mark a considerable enhancement in their service offerings.

## Testimonials

<img
  src="/blog/2023-12-21-success-story-open-systems-04.jpg"
  width="250px"
  alt="Portrait of Simon Stäheli"
/>

"Choosing ZITADEL was a key decision for us at Open Systems, particularly for its straightforward integration with various third-party identity providers used by our client base. ZITADEL's cloud-native approach and rapid development cycle aligned perfectly with our needs. This, coupled with the ability to self-host and receive excellent support, made ZITADEL stand out as the best choice for our modern authentication requirements." 

-[Simon Stäheli](https://www.linkedin.com/in/simon-stäheli-179a6a78/), Product Owner/Manager, [Open Systems](https://www.open-systems.com/)

Discover how Open Systems' shift to ZITADEL has enhanced security and efficiency for their global network management.

Blog.