Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog


In this newsletter, I want to share updates about our platform, and provide some tips on how you can simplify your identity infrastructure.

## Feature highlights

In June,  we shipped over 60 bug fixes, improvements, and new features. Most of those changes were released with ZITADEL [v2.55.0](https://github.com/zitadel/zitadel/releases/tag/v2.55.0), so make sure you are running the latest version.

### New password expiry feature

ZITADEL has introduced a new password age policy feature, enabling organizations to require users to change their passwords regularly. This feature can be easily managed through the Console UI at both instance and organization levels. Users will be prompted to change their password in the Login UI if their current password exceeds the defined age limit. This enhancement strengthens ZITADEL's password management capabilities and provides organizations with greater control over their password lifecycle.

![ZITADEL Console UI password expiry settings](2024-07-04-zitadel-product-newsletter-june-2024-01.png)

### Limit requested roles with new scope

A new scope was introduced to address the issue of excessive roles being returned in tokens (and as such increasing their size) for users belonging to multiple organizations. This new scope allows administrators and applications to specify which organizations' roles should be included in the token, thus streamlining access control for specific use cases. By using the new scope, either once or multiple times, only the roles of the specified organizations will be included in the token.  It's important to note that this feature is not compatible with legacy mode for Introspection or Userinfo endpoints.

[Reserved Scopes](https://zitadel.com/docs/apis/openidoauth/scopes#reserved-scopes)

### More performance improvements

ZITADEL's performance continues to improve as the team works to identify and eliminate bottlenecks. Notably, import operations for large quantities of project grants will witness a substantial enhancement. Furthermore, a significant improvement has been made to OpenID Connect / OAuth 2.0 session checks, effectively addressing recent observations identified during load testing.

### Sending test emails

The newly introduced feature has enhanced ZITADEL’s SMTP functionality by introducing a new testing step within the SMTP provider wizard. This allows administrators to verify their SMTP configuration before saving or updating it, preventing potential issues with email delivery. Additionally, the existing table of SMTP providers now includes a test option for existing configurations. This streamlined testing process ensures that email settings are correct from the outset, saving time and effort. This feature was contributed by the community - thank you for your efforts!

![ZITADEL Console UI sending test email during configuration of SMTP](2024-07-04-zitadel-product-newsletter-june-2024-02.png)

[Changelog](https://zitadel.com/changelog)

## ZITADEL achieves ISO 27001 certification, reinforcing commitment to security

<img src="/blog/2024-07-04-zitadel-product-newsletter-june-2024-03.png" width="25%" align="left" alt="" class="wrap"/>

In a significant milestone for ZITADEL's commitment to security and data protection, we have achieved ISO 27001 certification for our information security management system (ISMS). This internationally recognized standard validates our dedication to maintaining the highest levels of security for our customers' data.

To provide further transparency and information about our security practices, we have also updated our [Trust Center](https://trust.zitadel.com). This resource offers comprehensive details on our security posture, policies, and certifications.

[ZITADEL Achieves ISO 27001 Certification](https://zitadel.com/blog/zitadel-iso-27001-certified)

## 21 more reasons to celebrate: Community contributions in June

* Many Console UI improvements were contributed by [doncicuto](https://github.com/doncicuto) improving the user experience for administrators and users. Moreover [doncicuto](https://github.com/doncicuto) made it possible to send test mails for SMTP configurations and further improvements to mail providers.
* [JesperWe](https://github.com/JesperWe) made it possible for Swedish speakers to use their beautiful native language
* [Schettn](https://github.com/schettn) created a guide to integrate with the [Pylon](https://github.com/getcronit/pylon) framework

Many thanks to the contributors this month for their efforts, helping to improve documentation, tests, and fixing bugs in our code: [dkaminer](https://github.com/dkaminer), [panapol-p](https://github.com/panapol-p), [jvanderneutstulen](https://github.com/jvanderneutstulen), [danielmoisa](https://github.com/danielmoisa), [Loddan](https://github.com/Loddan), [Yxnt](https://github.com/Yxnt), [Cubox](https://github.com/Cubox), [danielloader](https://github.com/danielloader), [jfschubert](https://github.com/jfschubert)

Thinking of contributing? Grab a ‘good first issue’ or start a discussion. 

[Contributing guide](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md)

## Additional resources

* [ZITADEL Bi-Weekly Office Hours](https://github.com/zitadel/zitadel/blob/main/MEETING_SCHEDULE.md)
* [Forza Italia: Retreat the third edition in Bologna](https://zitadel.com/blog/team-retreat-bologna)
* First time contribution (Japanese only): [OSS コントリビュートの実績を解除した](https://zenn.dev/otakakot/articles/dc58ff849e43e4)
* Integrate .NET (Polish only):  [Integracja Aplikacji .NET z Zitadel | bd90](https://bd90.pl/integracja-aplikacji-net-z-zitadel/)

ZITADEL introduced new features and enhancements, including a password expiry feature, a new scope to limit requested roles in tokens, SMTP configuration testing, and performance improvements. ZITADEL achieved ISO 27001 certification, demonstrating its commitment to security.

Product Newsletter June 2024


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

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

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

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

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

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

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

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



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

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


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

ZITADEL Achieves ISO 27001 Certification


As a fully remote company, the time we spend together in person is precious.
This is why twice a year, our team gathers for an in person retreat, an opportunity to connect beyond the virtual world.
Last week, we met outside the beautiful city of Bologna for our first retreat of the year.
Since we really enjoyed it, we wanted to share a glimpse of  our week-long adventure.

## Travel Monday and Arrival in Bologna

After a full day of travel by plane or train excitement filled the air as we arrived in Bologna.
The last steps to our accommodation were harder than expected, the location with its view of its flowing hills and grape wines were worth it.
As everybody arrived later in the afternoon we rounded off the evening with pasta, as one would expect in Italy.
We even committed ourselves to cooking two fresh sauces, ragu and a verdure.  The whole team enjoyed the get-together and chatted until late that night over a drink.

<figure>
    <img src="/blog/2024-06-19-team-retreat-bologna-01.jpg" width="100%" alt="Up the hill." />
</figure>

## Workshop Tuesday (with Pizza)

Tuesday marked the beginning of our planned activities. In the morning, we gathered for a collaborative workshop focused on team dynamics and fostering a productive environment. This session, prepared with the guidance of our coach, Diane, was insightful and set a strong foundation for our company culture.

The afternoon was free for everyone to explore the surroundings or engage in spontaneous discussions. Some team members chose to go for a walk, while others stayed back to exchange ideas and plans that have been in their heads for a long time and some others decided to play a game called Kubb.

The highlight of the day was undoubtedly pizza night. Max brought his portable pizza oven, and Florian had spent the afternoon making pizza dough from scratch. As evening fell, we gathered to create our own pizzas. The making was as enjoyable as the delicious outcome. We laughed, shared stories, and ate homemade pizzas—a perfect blend of teamwork and fun.

<figure>
    <img src="/blog/2024-06-19-team-retreat-bologna-02.jpg" width="100%" alt="Pizza Night" />
</figure>

## Wednesday, Continued Workshops and Exploration

Wednesday morning continued with another productive workshop session. Building on the previous day's discussions and results, we delved deeper into our operating principles, aligning our visions and strengthening our collaborative spirit.

The afternoon was again free for personal activities. These unstructured times were as valuable as the workshops, allowing for organic connections and idea exchanges.

<figure>
    <img src="/blog/2024-06-19-team-retreat-bologna-03.jpg" width="100%" alt="Workshop" />
</figure>

### A Culinary Adventure on Thursday

Thursday was dedicated entirely to food. We went on a walking food tour in Bologna, immersing ourselves in the local culinary delights. From fresh pasta to delicious pastries, we tasted a variety of specialties that the city is renowned for, such as cold-cuts, Tiggele, Tortellini al Brodo, Tagliatelle al Ragù. This gastronomic journey was not just about food but also about experiencing the culture and history of Bologna together.

<figure>
    <img src="/blog/2024-06-19-team-retreat-bologna-04.jpg" width="100%" alt="Pasta" />
</figure>

<figure>
    <img src="/blog/2024-06-19-team-retreat-bologna-05.jpg" width="100%" alt="Church" />
</figure>

### The Importance of In-Person Retreats

We figured that these in-person retreats are crucial for our company culture. They provide us with a unique opportunity to build stronger relationships and learn about each other's interests and expertise. Spending time together allows us to connect on a personal and social level, enhancing our collaboration and understanding of each other, far beyond what is possible through modern communication channels like video and audio.

Our week in Bologna was a resounding success. From the insightful workshops to unforgettable culinary experiences, we cherished every moment. These retreats remind us of the importance of human connection in a digital world. It made us aware that remote work is hard work, and we are already looking forward to seeing each other again in person in the next retreat.

<figure>
    <img src="/blog/2024-06-19-team-retreat-bologna-06.jpg" width="100%" alt="Team" />
</figure>


As a fully remote company, the time we spend together in person is precious. Get some insights about our third team retreat taking place in Bologna.

Forza Italia: Retreat the third edition in Bologna


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.

Blog.