Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

Read the blog

Sign up

Login

Pricing

Jobs

Blog


This is Max from ZITADEL. As in the previous months, in this update I want to highlight our product updates, and tips and tricks in making your identity infrastructure easier.

## Feature highlights

Again in May, we kept the pace high with more than 76 improvements shipped to our self-hosting and cloud users. Let’s go through the key improvements to ZITADEL this month.

[All changes](https://zitadel.com/changelog)

### Improvements using external SAML IdPs

We understand that many organizations, particularly enterprises, leverage SAML for user federation. In response to your needs, we've made significant steps in enhancing ZITADEL's interoperability with various SAML providers this May.

Previously, ZITADEL relied on a persistent nameID format, requiring external identity providers (IdPs) to consistently return this format for linking users. However, some IdPs utilize transient nameIDs, leading to mismatched user identities.

This update allows you to define the preferred nameID format and configure how ZITADEL maps users based on attributes received from the external IdP. For instance, you can leverage email addresses from the IdP to link users with matching emails in ZITADEL.

While ZITADEL offers pre-configured templates for external IdPs that utilize OpenID Connect, we're considering extending this functionality to SAML providers. We value your feedback – let us know your thoughts on this potential addition!

[Should we support SAML provider templates?](https://github.com/zitadel/zitadel/issues/7995)

### Making it easier to manage resources programmatically

While you get all the functionality through a UI, we are api-first and you are able to manage everything through our APIs. Managing ZITADEL resources and configuration programmatically just got simpler with some recent updates.

When you start with a new ZITADEL system, you need a first admin user to login and configure your system. In the past it was only possible to either create a human user or a service user, but not both at the same time. With a recent update creating both a human and service user is now possible, giving you hopefully a much simpler and easier access to configure ZITADEL from the start.

Moreover our [terraform provider](https://zitadel.com/docs/guides/manage/terraform/basics) got significantly updated and improved over the last weeks. Examples are managing organization and user metadata as well as managing SAML and OIDC generic external identity provider templates.

### Scaling to multi-million identities

We're excited to announce performance optimizations in ZITADEL to meet the growing needs of our enterprise customers! This update addresses the demands of multi-million identity deployments and aligns with our ongoing commitment to performance improvement. We've focused on enhancing the token endpoint, specifically for new token creation, alongside optimizations for many frequently used ZITADEL APIs. For detailed upgrade guidance, please refer to the technical advisories.

[Technical Advisories](https://zitadel.com/docs/support/technical_advisory)

## Office hours

Gear up for deeper dives and live engagement! We are excited to announce bi-weekly office hours on our Discord server for our community. These hour-long sessions will offer in-depth explorations of upcoming features, followed by a live Q&A where the ZITADEL team tackles your burning questions.

The first session, held on May 29th, delved into the exciting new version of the Actions feature.

Don't miss out on this chance to connect with the ZITADEL team and stay ahead of the curve! Checkout our [meeting schedule](https://github.com/zitadel/zitadel/blob/main/MEETING_SCHEDULE.md) for upcoming sessions.

[Office hours meeting schedule](https://github.com/zitadel/zitadel/blob/main/MEETING_SCHEDULE.md)

## You will become a Pro

ZITADEL Cloud subscription model is changing to a simpler daily active user (DAU) model on July 1st for easier cost allocation and full feature access across instances. This serves as a friendly reminder that accounts not already on our Pro plan will automatically update.

All new subscription plans will include in the base fee 25’000 Daily Active Users in a month, one custom domain, and 3 external identity providers.

[Pricing Plans](https://zitadel.com/pricing)

## Contributors for the win

19 contributions came from our community in May. 
Thank you for your the continued support and the time you put in to make the project better for everyone.

* [yordis](https://github.com/yordis) helped us bring the typescript repo for our next gen login UI significantly forwards
* Never forget to activate your email service provider with this change from [doncicuto](https://github.com/doncicuto)
* Also by [doncicuto](https://github.com/doncicuto) comes a solution to a  community request, adding customization options to console navigation buttons
* [sujoysb](https://github.com/sujoysb) improved the error messages and user feedback for password complexity validations
* [calRobert](https://github.com/CalRobert), [jayPe69](https://github.com/jayPe69), [aurel004](https://github.com/aurel004), [burahimu](https://github.com/burahimu) all helped with our translations, and typos (is our French that bad? Apologies.)
* [cr1cr1](https://github.com/cr1cr1), [exeteres](https://github.com/exeteres), [kleberbaum](https://github.com/kleberbaum) contributed various improvement to our Charts
* Sign tokens FAPI-compliant with ES256 and PS256 thanks to [nannany](https://github.com/nannany)
* [ymarcus93](https://github.com/ymarcus93) increased compatibility with certain identity providers and fixed some issues around the library

## Additional resources

* [Passkeys: A Shattered Dream](https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/)
* [The SaaS Trends Report | Q1 2024 | Vendr](https://www.vendr.com/insights/saas-trends-report-q1-2024#top-categories-renewed) - Cybersecurity at the top
* [Navigating Session Logouts, Timeouts, and Token Expiry](https://zitadel.com/blog/session-timeouts-logouts)
* [Google Online Security Blog: On Fire Drills and Phishing Tests](https://security.googleblog.com/2024/05/on-fire-drills-and-phishing-tests.html)

New Success Story: [Achieving 70% Faster B2B Integration in Document Automation at BLP Digital](https://zitadel.com/blog/success-story-blp)

Thanks for reading, \
Max


Updates on ZITADEL, and tips and tricks to simplify your identity infrastructure for May 2024. In this episode we highlight improvements to SAML IdPs, managing resources programmatically, and scaling to millions of identities.

Product Newsletter May 2024

BLP Digital experienced significant operational improvements after implementing ZITADEL, highlighted by the following key achievements:

- **70% faster B2B client integration** 
- **Full migration in just 4 weeks** 
- **50% reduction in machine user management overhead**


<img
    src="/blog/2024-05-14-success-story-blp-01.jpg"
    width="100%"
    height="75%"
    alt="Banner Image"
    style={{ margin: '0 auto' }}
  />


## Company Background

[BLP Digital AG](https://www.blp-digital.com/en/), which sprang from a pioneering project at the Swiss Federal Institute of Technology (ETH Zurich) in 2018, focuses on leveraging the latest neural network advancements to automate document-based ERP processes. The founding team, comprising both entrepreneurs and machine learning pioneers, officially formed the company in 2019, earning the prestigious ETH Zurich spin-off label. Today, driven by a team of over 50 skilled software engineers and business experts, BLP Digital serves a diverse global clientele, adapting to 20 languages and multiple regulatory environments. Their SaaS solution targets medium to large-sized industrial companies, trading companies, retailers, and financial institutions, all of whom benefit from high-volume document processing with minimal manual intervention.

## The Challenge

As BLP Digital expanded its services globally, it became clear that their existing Identity and Access Management (IAM) systems were inadequate. The company faced critical technical and financial challenges, particularly in creating a scalable and secure Single Sign-On (SSO) solution that adhered to open standards. The need for a more efficient and secure system became urgent as they planned to migrate thousands of active B2B users from traditional password systems managed through Auth0 to a streamlined SSO setup. 

## The ZITADEL Solution

After evaluating several options, including Keycloak, Firebase, Supertokens, and Ory, BLP Digital selected ZITADEL for its comprehensive capabilities. Through Role-Based Access Control (RBAC), flexible authentication options (including MFA and SSO), and simplified identity federation with a variety of corporate identity providers (including Microsoft Entra ID), ZITADEL significantly improved security and user experience.
ZITADEL stood out because of its:
- **Advanced Multi-Tenancy Capabilities**: Offering the ability to manage distinct, secure environments for each B2B client.
- **Flexible Hosting Options**: Including both cloud services for production environments and self-hosted setups for development, facilitating seamless integration into BLP Digital’s architecture.
- **Machine User Management**: Non-interactive accounts are vital for authorizing automated processes and backend services. This capability ensures secure and seamless service execution, a feature not available with their previous provider, Auth0.
- **Commitment to Open Standards**: Ensuring flexibility and preventing vendor lock-in, crucial for future scalability.
- **Support Model**: The integration process evolved into a dynamic partnership, with BLP Digital working closely with ZITADEL to refine and adapt features to better meet their needs.

## Key Outcomes

- **70% Faster B2B Client Integration**: The time required to set up and manage B2B client environments was reduced from 5 hours to just 1.5 hours.
- **Full Migration in Just 4 Weeks**: Demonstrating ZITADEL’s exceptional adaptability and speed in deployment.
- **50% Reduction in Machine User Management Overhead**: ZITADEL’s service user feature halved the time and effort required to manage backend services and automate processes.

## Testimonials

<img
  src="/blog/2024-05-14-success-story-blp-02.jpg"
  width="250px"
  alt="Portrait of Tim Beck"
/>

“As a leading SaaS company serving tens of thousands of users, we prioritize a robust and reliable authentication solution. After extensive research for the best provider, we were impressed by ZITADEL’s exceptional flexibility and cutting-edge technology. Their seamless integration and unwavering support have significantly enhanced our platform's security, making them an invaluable partner in our growth.”

- [Tim Beck](https://www.linkedin.com/in/timbeque/), Founder and CEO, [BLP Digital AG](https://www.blp-digital.com/en/)


Discover how BLP Digital uses ZITADEL's IAM features to boost their document automation services across B2B platforms.

Achieving 70% Faster B2B Integration in Document Automation at BLP Digital


We're thrilled to announce a significant milestone for ZITADEL: exceeding 100 paying customers as we entered 2024! This achievement marks a pivotal moment in our journey to establish ZITADEL as the leading open-source identity infrastructure platform.

While reaching over 7,000 GitHub stars, having 160+ active contributors across our projects, and a thriving 2,000-member Discord community are fantastic signs of our growing popularity, winning the trust of over 100 paying customers by the start of 2024 demonstrates the demand for a modern identity platform like ZITADEL and sets the stage for continued, rapid growth.

Our customers represent a diverse range of organizations who have chosen ZITADEL for its:

* **Unmatched security and transparency:** The open-source nature of ZITADEL fosters trust and allows for independent security audits, ensuring robust protection for user data.
* **Flexibility and customization:** ZITADEL empowers businesses to tailor its functionalities to their specific needs, offering a high degree of control over their identity infrastructure.
* **Self-hosting:** Many smaller customers trust the scalability and the peace of mind offered by our managed cloud service. Businesses have the option of self-hosting ZITADEL, granting complete control over user data and deployment environment, with support available for added peace of mind.
* **Advanced multi-tenancy:** ZITADEL's robust multi-tenancy features are ideal for B2B scenarios. It allows organizations to manage multiple tenants (customers or partners) with data separation, customizable branding, and secure access control.
* **Enhanced SSO and MFA:** Our customers want to replace their SSO and MFA capabilities with a more robust solution that offers technical and operational scalability. ZITADEL provides teams the functionality to manage their own security policies and SSO configuration coupled with modern phishing-resistant, multifactor authentication methods.

This milestone is a testament to the incredible work done by our amazing community and the unwavering commitment of our team. We are deeply grateful for the trust our customers have placed in ZITADEL, and we remain focused on providing the best possible open-source identity solution.

Join us on this exciting journey! Simplify your identity infrastructure and [get started with ZITADEL Cloud](https://zitadel.com) today.

Together, let's build an open and secure identity infrastructure!


ZITADEL is on Track towards Building the Best Open source Identity Infrastructure

Celebrating 100+ Paying Customers


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.

Blog.