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


## Key Outcomes

- [Kaspar&](https://www.kasparund.ch/), a Swiss fintech company,  uses [ZITADEL Cloud](https://zitadel.com/signin) for centralized user and access management, serving both external customers and internal users.
- By leveraging ZITADEL, Kaspar& has successfully enhanced the user experience and security for B2C customers interacting with their mobile app. They achieved this through streamlined user registration and management processes while maintaining high security standards with features, such as passwordless authentication and multi-factor authentication offered by ZITADEL. This resulted in a significant reduction in time spent on these tasks compared to when they were using their in-house solution.
- ZITADEL will play a crucial role in the growth and expansion of Kaspar&'s core offering to expand its fintech services to a broader clientele in Switzerland. By integrating additional two-factor authentication methods, Kaspar& can offer a higher level of security for their customers.  Furthermore, ZITADEL's built-in organization model and federated authentication capabilities  will enable Kaspar& to efficiently manage their B2B user base.

## Introduction

[Kaspar&](https://www.kasparund.ch/) is a fintech in Switzerland, co-founded by CTO [Sebastian Büchler](https://www.linkedin.com/in/sebastian-b%C3%BCchler/), that offers a user-friendly, mobile app-based wealth management service.  We spoke with Sebastian to gain insight into the problems they encountered and the reasons behind choosing ZITADEL as their identity and access management solution.
Kaspar& provides users a convenient and affordable way to invest and manage their finances using their smartphones. Users can set various investment goals, choose from different investment strategies, and track their portfolio performance. Kaspar&'s customers are retail customers, primarily from traditional banks, wanting to invest money. Kaspar& operates on a cost-effective, technology-driven business model. By leveraging digital platforms and forgoing the need for physical branches and expensive financial advisors, the company can provide professional wealth management services at a fraction of the cost compared to traditional financial institutions. Kaspar& also offers a debit card for making online and offline purchases, which enables automatic investment of the spare change from those transactions.

Kaspar& generates revenue by charging a fee for its wealth management services. This fee is typically lower than those charged by traditional banks and investment advisors. As a spin-off from the University of St.Gallen (HSG) and ETH Zurich, Kaspar& bases its investment decisions on the latest financial market theories and practical concepts, ensuring that users benefit from a professional, research-driven approach to wealth management. Moreover, Kaspar& is regulated by the [Swiss Financial Market Supervisory Authority FINMA](https://www.finma.ch/en/) and partners with [Hypothekarbank Lenzburg](https://www.hbl.ch/de/private/), ensuring that users' investments are held securely in a Swiss bank.
To get started with Kaspar&, users have to: 
- Download the Kaspar& app from the App Store or Play Store.
- Sign up by providing personal information, answering financial questions, and completing the KYC (Know Your Customers) process, which includes an automated video identification process. Kaspar&'s services are restricted to Switzerland; customers must have a Swiss domicile address to register.
- Make an initial deposit from a Swiss bank account.
- Set investment goals, such as retirement or education funding.
- Choose an investment strategy (Comfortable, Normal, or Sporty).
- Start investing with as little as one franc.
- Monitor and manage investments, adjust strategy, and change thematic focus within the app.

## Problem

Kaspar& faced several pain points related to authentication and user management. As Sebastian explained, the company had used an in-house solution that used JSON Web tokens for customer authentication. Although the basic login functionality was relatively simple to implement, other aspects, such as the sign-up process, password reset, two-factor authentication, and security-related concerns proved to be more challenging. 

With the rapid growth and expansion of their customer base, Kaspar& needed a robust and scalable identity and access management (IAM) solution to manage user authentication, both for the customer-facing mobile app and for accessing internal  applications. 

Moreover, Kaspar& wanted a managed solution that was cost-effective, compatible with their Business-to-Customer (B2C) model, and provided data residency in Switzerland to ensure regulatory compliance and maintain customer trust. Sebastian explained that they found the per-user pricing of most of the major market players to be too expensive for their customer base.

## Solution

### Addressing Customer Identity and Access Management Needs

Based on the recommendation of a mentoring agency, the Kaspar& team was introduced to ZITADEL, which they found to be a better fit for their needs compared to other major vendors. Kaspar& found ZITADEL's user registration and management process much easier to handle, and they value the security aspects provided by the platform. 

Kaspar&'s native mobile app for customers applies the OpenID Connect (OIDC) flow with Authorization Code Grant and Proof Key for Code Exchange (PKCE) to securely authenticate users and provide access to its wealth management services. The app initiates the authorization request by opening the system browser with a URL pointing to ZITADEL’s authorization endpoint, including parameters such as client ID, redirect URI, code challenge, etc. Users then authenticate within the system browser using their credentials (the user ID is the phone number), which is accompanied by multi-factor authentication for added security. Upon successful authentication, ZITADEL sends an authorization code to the app via a custom scheme or universal links/app links for iOS and Android, respectively. The app exchanges the authorization code along with the code verifier for an ID token and access token by making a request to ZITADEL's token endpoint.The ID token contains user information, while the access token enables the app to access protected resources, such as APIs. With a valid access token, the authenticated user can set up investment goals, choose investment strategies, and track their portfolio performance within the Kaspar& mobile app.

<figure>
  <img
    src="/blog/2023-04-20-success-story-kaspar&-01.png"
    width="100%"
    alt="Kaspar& Diagram 1"
  />
  <figcaption>
    Figure 1: OIDC Flow with Authorization Code Grant and PKCE for Kaspar& Mobile App
  </figcaption>
</figure>

### Addressing Internal Access Management Needs

ZITADEL is also used internally throughout Kaspar&, mainly for integration into internal applications for single sign-on. They use features such as team pass keys. Passkeys eliminate the need for users to remember and enter passwords. By leveraging passkeys for passwordless authentication, Kaspar& can improve security and provide a more seamless login experience for their internal users as the passkey can be securely delivered and used only once, reducing the risk of unauthorized access. 
Kaspar& currently utilizes ZITADEL's managed cloud solution for their infrastructure, dividing their setup into three environments: production, development, and internal. They separated their cloud instance into projects to map their environments, with customer-facing sites for production and dev environments, and internal tools like Grafana and Admin Dashboard for the internal environment.

### Cost-effective Pricing Model 

Another reason for Kaspar& to choose ZITADEL as their IAM solution was due to its competitive pricing and compatibility with their B2C model. While they initially compared ZITADEL to other major market players, they found the per-user pricing of these alternatives to be too expensive for their customer base. ZITADEL's approach to pricing and technical capabilities aligned well with Kaspar&'s goals of reaching a mass clientele: ZITADEL's pricing is based not on a pay-per-user model but on the number of requests made. This allows ZITADEL to offer a cost-effective and scalable solution for businesses of all sizes.

## Learning Curve and Product Support 

Sebastian explained that they started using ZITADEL at its inception and that the ZITADEL team provided extensive support, helping Kaspar& successfully set up their identity infrastructure. He also mentioned that the availability of libraries and support materials has improved over time, making the integration process even smoother.

Getting accustomed to ZITADEL for Kaspar& was challenging at first because of the numerous features and possibilities it offered. However, once they had gained a better understanding of the platform, they found it to be a powerful tool for creating enterprise-grade solutions with just a few clicks.

With the release of ZITADEL 2.0, the Kaspar& team found the UX to be much more intuitive and significantly improved, making it easier to set up and configure the platform. They found the developer tutorials helpful for setting up authentication clients in NextJS and TypeScript. 

Their overall experience with ZITADEL has been positive, receiving good feedback for the new technology from their users. They appreciate the regular feature updates and ZITADEL's responsiveness to suggestions.

## Future Plans

### Expanding Authentication Options with Hardware/Device Tokens

Kaspar& has several upcoming plans to leverage ZITADEL's capabilities to enhance their offerings and provide a seamless experience for their customers. They plan to introduce hardware/device tokens as an optional opt-in feature and explore other two-factor authentication methods, such as [FIDO](https://fidoalliance.org/)-enabled credit cards and [Swiss Pass](https://www.swisspass.ch/home) cards.

### B2B User Management and Access Delegation for Kaspar& Fintech Services

In addition, as the company also began exploring Business-to-Business (B2B) solutions, they found ZITADEL's multi-tenancy features to be an added advantage. Kaspar& aims to expand their B2B offerings with ZITADEL, using ZITADEL’s built-in organization model to structure their user base and grant access to necessary projects. Their typical B2B customers are banks, and they plan to create a dedicated organization for each bank to manage their users. Here's how it could work:

1. Kaspar& sets up a project in ZITADEL with specific roles tailored to the access levels required for their fintech services.
2. They then delegate access to their fintech services to their B2B customers, such as banks, allowing these organizations to manage their own users and assign roles to them.
3. Each bank (B2B customer) can now self-assign access to their users and manage user authorizations for the Kaspar& fintech services, without Kaspar& having to build a multi-tenant user management system.
4. Users from the banks can self-register for Kaspar&'s services and manage their own profile information and authentication methods, providing a seamless user experience.

This approach reduces the burden on Kaspar& to develop a multi-tenant user management system, and enhances the overall experience for their customers.

<figure>
  <img
    src="/blog/2023-04-20-success-story-kaspar&-02.png"
    width="100%"
    alt="Kaspar& Diagram 2"
  />
  <figcaption>
    Figure 2: B2B User Management for Kaspar& with ZITADEL 
  </figcaption>
</figure>

### Federated Authentication for Seamless Bank Login Integration with Kaspar& Services

One standout feature they hope to deploy is reusing existing clients' logins from the banks to provide a smooth experience for clients through federated authentication. To achieve this, Kaspar& would need to configure a trusted Identity Provider (IdP) for each bank within the ZITADEL platform. These IdPs could be the bank's own identity management systems or popular third-party IdPs such as Google or Microsoft, depending on the bank's preference.

Once the trusted IdP is set up for a bank, users from that bank can use their existing login credentials to access Kaspar&'s services. When they log in, the user's credentials are verified by the bank's IdP, and an authentication token is issued. This token is then used by Kaspar& to grant access to the user, based on their assigned roles and permissions.

This approach not only simplifies the login process for users but also enhances security, as the bank retains control over the user's credentials, and Kaspar& does not store any sensitive information. Full integration with B2B partners will likely be completed by the end of the year, allowing bank customers to experience the new setup from start to end.



## Testimonials

<img
  src="/blog/2023-04-20-success-story-kaspar&-03.png"
  width="200px"
  alt="Portrait of Sebastian Büchler"
/>

“ZITADEL has made a significant difference for our startup, offering a cost-effective solution that aligns with our business model. The ZITADEL development team is highly responsive, regularly adding new features that make our lives easier. As we expand into the B2B market, ZITADEL's multi-tenancy features have proven to be an excellent choice for our needs. Their customer-centric approach and technical expertise set them apart from other big players in the market.“ - [Sebastian Büchler](https://www.linkedin.com/in/sebastian-b%C3%BCchler/), CTO & Co-Founder of [Kaspar&](https://www.kasparund.ch/)

By leveraging ZITADEL, Kaspar& has successfully enhanced the user experience and security for B2C customers interacting with their mobile app.

Built with ZITADEL: A Partnership in Fintech Security with Kaspar&


In response to the **increasing cybercrime rates** and inadequate private data management, the European Union (EU) adopted the **General Data Protection Regulation (GDPR) legislation**. Since the set of laws took effect in 2018, entities that offer services and collect data from users inside the EU **must comply with its guidelines to ensure a reliable means of handling their customers’ information**. With the exposure of sacred data at stake, the GDPR has been established as the strictest security law in the world, with **severe consequences of non-compliance** that can put your company's long-term viability in peril. 

Fortunately, an implemented **Identity and Access Management (IAM) solution**, such as ZITADEL, can **facilitate compliance** by consistently implementing a mechanism to control access to users’ personal data: Thus, it can **reduce the likelihood of cyber-attacks** and data exploitation and simultaneously assist in avoiding expensive GDPR violations.

This article discusses the role of identity vendors in becoming GDPR compliant and the responsibilities of data processors and controllers.

## Who does GDPR apply to?

Before we dive into what it takes to become GDPR compliant, it is crucial to **establish if your organization is even subject to this legislation**. For instance, you must be excluded from these regulations if your company is headquartered outside of the European Union and caters mostly to non-European customers, right? Not necessarily.

The GDPR applies **based on the location of the individuals whose data is being processed** and not the location of the firm itself or its customer-base. Accordingly, any business that offers goods to or **tracks personal data of individuals situated in the EU** would automatically be subject to the regulations: including small-businesses, commercial enterprises, nonprofits, and governmental bodies.

However, according to the European Commission, **"if processing personal data isn’t a core part of your business** and your activity doesn't create risks for individuals, then **some obligations of the GDPR will not apply to you** (for example the appointment of a Data Protection Officer ('DPO'))".

If the aforementioned criteria confirm that your business is covered by the GDPR, follow along to learn how to facilitate compliance with the help of an authentication solution.

## Does implementing identity & access management make me automatically GDPR compliant?

Short answer: **No**. While an identity vendor serves as a significant stepping stone on your journey to compliance, it is ultimately only a part of the solution: As the data controller, **you are still the entity responsible for the safety of your users’ data**. Whereas this responsibility includes consciously choosing an identity solution that meets compliance requirements, you are nevertheless obligated to ensure that **your own platform’s policies and functionalities are up to the standards of the GDPR** as well.

“So, what else do I have to do to make my application compliant?” - Evidently, maintaining oversight of what your and your IAM’s responsibilities entail isn't always easy. To lend you a hand, the subsequent chapters **elaborate on the different tasks of the data controller and data processor**, respectively.

## The Liabilities of the Data Processor

As the name suggests, your identity vendor is mainly responsible for processing sensitive data about your users’ identities. However, this seemingly simple main task entails a wide range of other liabilities, such as:

* Ensuring that the **processed personal data follows the privacy policy** (cf. [Privacy Policy](/docs/legal/policies/privacy-policy)) and the documented directions of the Customer.
* **Informing the Customer if they have violated the Agreement**, the GDPR, or other data protection provisions and potentially suspending the Processing until the instruction is withdrawn or confirmed.
* Ensuring that the **people authorized to process the Personal Data have committed themselves to confidentiality**.
* **Taking appropriate technical and organizational security measures**, maintaining them for the duration of the Processing and updating them on an ongoing basis in accordance with the current state of technology.
* Having the right to **involve additional declared sub-processors** subjected to the same data protection obligations. The Customer has the right to object to such changes and seek a mutual agreement with the processor.
* **Supporting the Customer as far as possible with suitable technical and organizational measures** in fulfilling its obligation to respond to requests to exercise the data subject's rights.
* **Assisting the Customer in complying with its obligations** in connection with the security of the processing, any notifications of personal data breaches, and any data protection impact assessments.
* **Deleting personal data received after the end of the agreement** upon the Customer's request unless there is a legal obligation for the Processor to store or further process such data.
* **Providing the Customer with all information necessary to demonstrate compliance**. It shall enable and contribute to audits, including inspections, carried out by the Customer or an auditor appointed by the Customer.

## The Liabilities of the Data Controller

To make sure that not just your identity provider but also your application itself is GDPR compliant, you, as data controller, also bear some notable responsibilities:

* **Ensuring your vendors, including your identity provider, are fully GDPR compliant** accounting for the transborder data flows.
* Controlling and **notifying end-users on consent and withdrawal of consent**
* Determining **what data you wish to expose to your IAM**
* Ensuring that the **end-users fulfill the requirements** for signing up
* Providing their end users with the **ability to retrieve, review, correct, or remove (delete) their personal information**
* **Answering end users’ privacy-related requests** and communications from the European Union Data Privacy Authorities
* **Notifying end-users about data breaches**

An easy way to **evaluate your current compliance status** and detect any problematic data management procedures is by using the **official [GDPR-Checklist for data controllers.](https://gdpr.eu/checklist/)**

## In Conclusion

Organizations that **collect, process, or store data of EU citizens are obligated to comply with GDPR**. Most of the personal identifiable information is closely **linked to your users’ digital identity**. Safeguarding access to this highly sensitive data and lifecycling the information according to the regulations is a challenging task. Turnkey identity solutions like **ZITADEL** can help you ease the work that has to be done on your side to **protect personal information, manage access, and stay compliant to regulations**.

As a Swiss authentication vendor, **ZITADEL is completely compliant with GDPR standards** and provides the same degree of data security as the EU. The platform’s **Data Processing Agreement** handles obligations to process personal information as well as consumer demands regarding their privacy rights. Furthermore, this IAM aids compliance by **centralizing all information related to digital identities and permissions** and providing you with an audit record of every interaction with the system.

When deciding how to operate your ZITADEL instance, you have the option to **self-host ZITADEL to reduce the number of sub-processors** and the associated supply chain risk. Alternatively, you can choose to rely on the **state-of-the-art operational security in our cloud service** to keep your end-user data safe. 

**[Click here](/gdpr) to learn more about how ZITADEL can help your company with GDPR compliance.**


This article discusses the role of identity (IAM) vendors in becoming GDPR compliant and the responsibilities of data processors and controllers.

Why an Authentication Solution Is Crucial for GDPR Compliance


## Initial Position
From user feedback and our own observation, we got quite a few hints that instance owners get lost after their initial onboarding with what to do next. So we knew that we had to do something about it. Our first thought was an informational email with further instructions and provided links, but it was clear to us that this wasn’t a proper solution and was a bit outdated. So we thought of a more direct “in-app” approach that is more interactive.

## What We Wanted to Improve
After some research, we came to the conclusion that the home page in the console is where most of our customers “get stranded” and that provides the most visibility to our new guiding. We want to give the user some guidance on what could be helpful to set up next and what is missing for a successful authentication experience. We want the instance owner to feel more engaged in the setup process.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-01.png"
    width="100%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 1 - Our old start page with the focus on customizable general shortcuts and some helpful links like docs</figcaption>
</figure>


## Our New Approach
To achieve this new interactive setup for our customers, we thought of a small “to-do list” with some gentle gamification to keep them engaged. And we wanted the home page of the console to focus on these next steps rather than the general shortcuts the old page had.

So we added a progress bar that is prominently visible on the start page so the instance owner can see how far in they are with the setup. This progress bar will also show in a smaller form in the header at all times. When the setup is complete (as far as the guidance goes) this progress bar will be removed.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-02.png"
    width="50%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 2 - Progress bar as shown on the home page of the console</figcaption>
</figure>


These steps in the progress bar are shown on the start page as cards, declaring each step and with a short description of what it is about. Steps that are already done will be faded out and checked so the user can see at first glance which steps are done and which are still to do.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-03.png"
    width="50%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 3 - Progress steps cards as shown on the start page</figcaption>
</figure>


Furthermore, by hovering over the small progress bar, the user can instantly overview this list in a more compact form anywhere in the ZITADEL console with direct links to the according subpage for the task. Here the user can also opt out of this guidance if they don’t want that additional information.

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-04.png"
    width="40%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 4 - The overview panel is accessible from the small progress bar in the header bar, including an opt-out option</figcaption>
</figure>


This all results in the new start page that looks like this: 

<figure>
  <img
    src="/blog/2023-04-11-onboarding-process-05.png"
    width="100%"
    alt="Onboarding Process"
  />
  <figcaption>Figure 5 - The new and improved home page of ZITADEL console</figcaption>
</figure>


You can see that we still provide the help links but put them a bit further down the list. Note that once the progress is completed, the progress steps will convert to normal shortcuts and provide the user with direct links to the most used pages.

## Conclusion
With these changes, we hope to provide a smoother setup process, especially for new customers. But this should also come in handy for our more veteran ZITADEL users, as it gives them a handy checklist for what they might haven’t set up yet. 

We are constantly trying to enhance the user experience and if you have any suggestions on how to improve our workflow or ZITADEL in general, feel free to let us know.


This post explains what's new in ZITADEL's user onboarding process.

ZITADEL's New and Improved User Onboarding Process


## Introduction

With the release of [ZITADEL v2.22.0](https://github.com/zitadel/zitadel/releases/tag/v2.22.0), we announced the availability of Flat Role Claims. This feature enables you to easily integrate user roles into your tokens through customizable actions, providing greater flexibility and control over the claims in your access tokens, ID tokens, and user info.

Flat role claims are a way of representing user roles in a simplified and easily readable format. Instead of using nested structures or complex JSON objects, flat role claims utilize a list of strings where each string represents a user's role, often combined with additional identifiers, such as organization or project IDs. For example, a flat role claim could look like this: 

`["{orgId}:{role}", "{orgId}:{role}", ...]`

Before supporting flat role claims, ZITADEL represented role claims using a JSON object structure. While this format provided all the necessary information, it could be difficult to parse and integrate with certain third-party tools and applications that expected roles in a simpler format.

ZITADEL switched to supporting flat role claims to provide more flexibility and ease of integration with various tools and systems. For example, better compatibility with tools such as [OAuth2 Proxy](https://github.com/oauth2-proxy/oauth2-proxy) or using ZITADEL as an OIDC provider with [Hashicorp Vault](https://www.vaultproject.io/). Flat role claims are easier to read, parse, and work with, reducing the complexity of managing user roles without having to recreate the role information as user metadata. 

## A Practical Use Case

Let’s consider that an organization has a project management application that integrates with ZITADEL for user authentication. The project management application requires user roles and permissions to be included in the ID token as custom claims in a specific format.

The organization uses ZITADEL's built-in roles and permissions for its users. However, the project management application expects user roles in a flat format (e.g., `orgId:role`), while ZITADEL provides roles as a JSON object.

To address this requirement,  ZITADEL allows the organization to reformat the user roles into the required flat format and include them as custom claims in the ID token. This way, the project management application can receive the ID token containing the custom claim and use it to grant the user access based on their roles and permissions.

By supporting flat role claims, ZITADEL enables the organization to customize the ID token to meet the specific requirements of their third-party application.

## How to Configure Flat Role Claims in ZITADEL

### Terminology: Actions, Triggers, and Flows
[ZITADEL Actions](https://zitadel.com/docs/apis/actions/introduction) is a key feature to extend the functionality of ZITADEL and continuously improve upon ZITADEL features and expand use cases. Actions allow you to create extended functionality by writing scripts using JavaScript. For example, the script of an action called doSomething should have a function called doSomething and would look like this:

```
function doSomething(ctx, api){
   // read from ctx and manipulate with api
}
```

[Trigger Types](https://zitadel.com/docs/apis/actions/introduction#trigger-types) define the point during the execution of a request. Each trigger defines which readable information (`ctx`) and mutual properties (`api`) are passed into the called function as well as which libraries are available for the function. 

[Flows](https://zitadel.com/docs/apis/actions/introduction#flows) are the links between an action and a trigger type. Currently, ZITADEL provides the following flows:

- Internal Authentication
- External Authentication
- Complement Token

The **Complement Token Flow** is the process flow of token creation and token introspection. The flow contains the following triggers: 

**Pre Userinfo creation**: This is the trigger that is called before `userinfo` is set in the token or response, and takes in the parameters (`ctx` and `api`) and their respective fields, such as `claims`, `getUser()`, `user`, `getMetadata()`, `grants`, and `setClaim()`.

**Pre access token creation**: This is the trigger that is called before claims are set in the access token and the token type is set to JWT. It takes in the parameters (`ctx` and `api`) and their fields, including `claims`, `getUser()`, `user, getMetadata()`, `grants`, `setClaim()`, and `appendLogIntoClaims()`.

You can define custom claims within the Complement Token Flow. You can create an action and use roles from ZITADEL to add a claim to your tokens/userinfo in the format of your choice. 

### A Sample Action
This code snippet is a JavaScript function named`flatRoles` that sets additional role claims in a token, combining the project ID and role name as a key-value pair. The function is part of the Complement token flow and is triggered during Pre Userinfo creation and Pre access token creation.

``` JavaScript

/**
 * Sets the roles as an additional claim in the token with roles as the value and project as the key.
 *
 * The role claims of the token look like the following:
 *
 * // Added by the code below
 * "my:zitadel:grants": ["{projectId}:{roleName}", "{projectId}:{roleName}", ...],
 * // added automatically
 * "urn:zitadel:iam:org:project:roles": {
 *   "asdf": {
 *     "201982826478953724": "zitadel.localhost"
 *   }
 * }
 *
 * Flow: Complement token, Triggers: Pre Userinfo creation, Pre access token creation
 *
 * @param ctx
 * @param api
 */
function flatRoles(ctx, api) {
    if (ctx.v1.user.grants === undefined || ctx.v1.user.grants.count == 0) {
        return;
    }
    let grants = [];
    ctx.v1.user.grants.grants.forEach(claim => {
        claim.roles.forEach(role => {
            grants.push(claim.projectId + ':' + role)
        })
    })
    api.v1.claims.setClaim('my:zitadel:grants', grants)
}

```


1. The function accepts two parameters: `ctx` and `api`.
  - `ctx`: Contains context information about the user, including user grants.
  - `api`: Provides methods to interact with ZITADEL's API.
2. The function checks if `ctx.v1.user.grants` is undefined or has no elements; if true, it returns immediately, as there's nothing to process.
3. If there are user grants, the function initializes an empty array called `grants`, which will be used to store the flattened roles.
4. Next, it iterates through the user's grants and roles, concatenating the `projectId` and `role` with a colon (":") separator, and then pushes the result into the `grants` array.
5. Finally, the function sets a new claim called `my:zitadel:grants` with the content of the grants array using the `api.v1.claims.setClaim()` method.
6. When the function is executed, it adds the flat role claims to the token in the format `{projectId}:{roleName}`.

### Enable the Action in ZITADEL
To use this flat role claim feature in ZITADEL, follow these steps:

1. Log in to the ZITADEL management console and navigate to the project where you want to use the flat role claim feature. Click on **Actions**. 

<figure>
  <img
    src=" /blog/2023-03-30-custom-claims-01.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

2. Click on the **New** button to create a new action.

<figure>
  <img
    src=" /blog/2023-03-30-custom-claims-02.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

3. In the **Create an Action** section, give the action the same name as the function name, e.g., flatRoles. In the script field, paste the provided flatRoles code. Click on **Add**.

<figure>
  <img
    src=" /blog/2023-03-30-custom-claims-03.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

4. The **flatRoles** action will now be listed. 

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-04.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

5. Next, we must select a **Flow Type**. Select **Complement Token** from the dropdown. 

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-05.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

6. Next, you must choose a trigger. Click **Add trigger**.  

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-06.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>


7. Select **Pre Userinfo creation** as the **Trigger Type** and select **flatRoles** as the associated action. 

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-07.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

8. You will see the **Pre Userinfo creation** trigger listed. 

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-08.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>


9. Follow the same steps to add the  **Pre access token creation** trigger and add **flatRoles** as the associated action. Afterwards, you will see both triggers listed as shown below: 

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-09.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

10. Don't forget to select the **Assert Roles on Authentication** checkbox on the Project dashboard and click **Save**. 

<figure>
  <img
    src="/blog/2023-03-30-custom-claims-10.png"
    width="100%"
    alt="Custom Claims."
  />
</figure>

Now, when a user logs in and receives an ID token, the action will be executed, transforming the user roles into the required flat format and adding them as a custom claim with the key `my:zitadel:grants`. This custom claim can then be used by third-party applications to manage user access based on their roles and permissions in the desired format.

## Closing Remarks

In summary, supporting custom role claims in ZITADEL enhances the user experience by providing more customization options, better compatibility with third-party tools, and improved adaptability to different use cases

Thanks for reading!

ZITADEL is FREE! So, go on and [try it out](https://zitadel.com/signin). 


This article demonstrates how to add custom claims to your tokens through customizable actions.

Configuring Custom Claims in ZITADEL

This follow-up article demonstrates how to use ZITADEL to secure APIs and how back-end applications can access these protected APIs.

API Access and Token Introspection with OpenId Connect in ZITADEL


## New Features

The [ZITADEL OIDC library](https://github.com/zitadel/oidc) is where we implement the OpenID Connect standard in a Go library. It is used by ZITADEL and our clients. Whenever we need to support additional parts of the specification or OAuth2-related RFCs in ZITADEL, the first step is to implement it in our OIDC library. In short, the following features lay important groundwork for later support in ZITADEL.

### Dynamic Issuer

The framework can now set the issuer of tokens based on the hostname in the request. This is an improvement for multi-domain deployments. The feature was already in use for almost a year in ZITADEL and now is finally merged to be available to a wider audience.

### Token Exchange (RFC 8693)

We have received a significant contribution from the community that completes the implementation of the Token Exchange flow. Big shoutout to [lefelys](https://github.com/lefelys) for his pull request!

### Device Authorization (RFC 8628)

The OIDC framework now offers device authorization flow as defined by RFC 8628. This feature allows authorization of devices that cannot open a browser for users to authenticate themselves. Instead, a code is generated and displayed along with a URL where the user should point their browser to authenticate and authorize the device.

## Test Coverage

We had a big bump in coverage after a community contribution from [muir](https://github.com/muir) (Thanks!!) last November from 12% to almost 40%. Ever since then,  we have been steadily growing coverage. And today we have crossed the 50% line!

## Refactoring

We have started refactoring some core parts of the library. For v2, we have started to simplify the usage of the collection of token claims, user info, and introspection response. These used to be interfaces, with their implementations as private structs and tons of getter/setter methods. In the case of custom claims a `map[string]interface{}` had to be used, with awkward type assertions.

Now we export those structs, and by the use of generics/type parameters, it is now possible to replace the OIDC types with custom types as decoding/unmarshal targets, essentially allowing type-safe access to additional fields. Don’t worry, the standard types still carry a map if you need the flexibility.

## The Future

We aim to continue to refactor parts of the library. We are looking to get rid of redundant code. Also, we are working hard to replace stale dependencies such as gorilla/mux. And we have some priorities planned, such as improving error handling and logging. In essence, the [issue list](https://github.com/zitadel/oidc/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement) gives a good overview of what we are planning to do.

Given the fact that we have some major refactoring in the pipeline, it might not be long until we tag a v3. However, we didn’t want to postpone the release of v2, as we had a split development target for almost a year now. Instead, we’ve decided to be more proactive when it comes to increasing to a new major version while refactoring.

## Conclusion

The release notes for this and the upcoming releases can always be found on the [Github releases page](https://github.com/zitadel/oidc/releases). We are forever grateful for PRs sent in by our [Contributors](https://github.com/zitadel/oidc/graphs/contributors).


We have released version 2.0 of our OpenID Connect library, which includes many changes.

OIDC Version 2.0 Release


When we think of cyber criminals, the first image that commonly comes to mind is a mysterious computer expert seamlessly accessing all of a platform's data with a few keystrokes. Astonishingly though, **brute force only accounts for 2% of cyberattacks** - the remaining 98% involve a **non-technical hacking method relying on human interaction, known as social engineering**. 

![Example of Pretexting](/blog/2023-03-16-social-engineering-01.gif "Social Engineering")

## What is social engineering?

Social engineering is a general term for **non-technical attacks employing deception** to exploit people's good intentions and trust to **acquire sensitive data**. From commonly seen scam e-mails to the exploitation of CEOs, **social engineering techniques heavily vary in their scales and stakes**. These diverse techniques, combined with the lack of required technical knowledge, make this attack *accessible to anybody with malicious intentions*, placing everyone who uses technology and interacts with people at risk.

This article discusses the **six most commonly encountered social engineering tactics** and how to protect your account from cybercriminals.

## 6 Common types of social engineering attacks

### 1. Phishing and Whaling

As the most common form of social engineering, **phishing** has become an inescapable term in cybersecurity. It describes a virtual attack during which **attackers send messages posing as reliable entities** to trick users into **giving away personal information or installing malware via a malicious link**. These messages usually depict situations that, due to their urgency, are known to grab the victim’s attention, such as a package delivery notification, a purchase confirmation, or a credit card suspension notice. 

While fraudulent e-mails are the most widespread phishing tactic, the attack takes many forms. **[Smishing (SMS Phishing)](https://zitadel.com/blog/smishing), Vishing (voice phishing), and Spear Phishing** are all smaller-scale methods commonly used to target everyday individuals. Whereas the former two alternatives generally rely on ambiguous situations that anyone could experience, **spear phishing messages aim to explicitly captivate a specific target** by involving personal details about the victim (f.e. an e-mail from the gym they attend). 

Akin to spear phishing, **whaling is a targeted phishing scam**; however, as the name implies, it aims to catch “bigger fish.” The goal of the attack is to **exploit the influence high-ranking individuals (such as CEOs) of companies have** by spoofing their e-mail addresses and **sending fraudulent messages to their lower-ranking co-workers**. Due to the instructions of the phishing message seemingly coming from a trusted higher-up, the **targets are more likely to fall victim to the scam**. 

### 2. Baiting

When you are trying to catch a fish, you may discover that it is much more likely to bite the hook if equipped with an **alluring bait**. The same simple principle can be applied to a social engineering attack. 

Baiting attacks put something intriguing in front of their target to **trick them into giving away their personal or financial information** or downloading malicious software. The bait in question could come in many forms, such as a **gifted USB inflicted with a virus or an online ad** luring people to malicious websites. Either way, it is intended to be hard for the victim to resist.

Akin to other social engineering techniques, baiting **thrives on exploiting the flaws of human nature**. If someone is nice enough to make us feel special, we are taught not to look a gift horse in the mouth - especially if the item or the deal seem authentic. 

### 3. Pretexting

Pretexting is an exceptionally calculated social engineering attack that strives to **get people to give away sensitive information under false pretenses**. It generally involves the scammer creating a **fake scenario under a false identity** to trick corporations into providing access to their databases. 

While the concept of pretexting might sound similar to phishing, they vary in their motives: the former solely aims to set up a successful future attack, **while the latter is generally the attack itself**. 

An infamous example of a pretexted scenario leading to a powerful attack occurred in 2019 when a **[hacker impersonated a CEO’s voice with AI software](https://www.wsj.com/articles/fraudsters-use-ai-to-mimic-ceos-voice-in-unusual-cybercrime-case-11567157402)**. In this case, the attacker established an employee’s trust by claiming the identity of his boss and subsequently urged him to transfer €220,000 to a made-up supplier. And just like that, **an imaginary scenario and a phone call were enough to scam a company out of thousands of euros**. 

### 4. Honey Trap

While bosses can undoubtedly sway people to follow orders blindly, their influence is still inadequate compared to the **power of love**. Though the internet has blessed us with the chance to find our soulmate while lounging at home, it comes with the curse of **commonly deceptive self-representation**. 

Honey Trap (aka. Honey Trapping) is a type of social engineering attack in which **the attacker seduces the victim into an online relationship**, usually using a fraudulent profile of an attractive person. The perpetrator then **exploits the trust and devotion of the victim towards their “partner”** to yield personal information or large sums of money. 

While the technique of honey trap is commonly used with the previously mentioned malicious goal in mind, it can also **serve an investigational purpose**: For example, to prove that a partner is unfaithful. 

### 5. Tailgating and Piggybacking

Unlike most social engineering attacks, **Tailgating is carried out in the physical world**. It involves an attacker closely yet unnoticeably **following an authorized person to gain access to an unauthorized location**. The technique can be as simple as the offender using an object or body part to prevent the door from closing after the authorized person has entered the area.

While Tailgating requires the attacker to be stealthy, **Piggybacking relies on the authorized person to voluntarily grant access to the restricted area**. Of course, the offender will **use deception to earn this grant**, such as by pretending to be a new employee who forgot their keys. 

### 6. Quid pro Quo

We have all heard of the golden rule: “Never give away personal information to strangers.” But what if **the stranger needs them to help me fix an issue?** 

“Quid pro quo" (Latin for "something for something") refers to a social engineering attack where the **attacker offers to exchange a service for information**. For instance, they might pose as an IT worker and **offer to inspect your computer for viruses to improve its performance**. All they need is your login credentials to access the required platform. Of course, you want them to be able to perform the promised service, so you comply without giving it a second thought. Little do you know, you have just **directly placed your valuable data into the wrong hands**. 

## How to prevent social engineering attacks

Evidently, social engineering is a **severe security threat that can lead to devastating consequences**. Fortunately, though, it is **preventable**. If you would like to drastically minimize the likelihood of falling victim to a social engineering attack, **we recommend taking the following precautions for your safety**.

### Keep an eye out for suspicious messages and links

Since many legitimate messages aim to redirect users using an attached link, it can be tricky to spot a social engineering attempt confidently. Luckily, there are some common indicators of smishing and e-mail phishing attacks to look out for:
* The message asks you to **click on an URL with a domain that does not correspond to the service’s name**. Furthermore, shortened URLs (f.e. starting with bit.ly, cutt.ly, and shorturl.at) are generally not trustworthy in the context of e-mail and SMS messaging.
* The message is **very generic** – Legitimate senders generally include the package number, your bank’s name, or your name/nickname, depending on the context.
* The message **contains spelling- or grammatical errors** - Texts from service providers are usually automated, so the possibility of a typo would be extremely low.
* The **number or e-mail address** of the sender and the service provider they claim to be, **do not match**. Moreover, when you receive a message from bigger service providers (f.e. banks, post offices, or delivery services), they will mostly display their company names instead of their numbers.
* The last warning - If you do click the attached link and a **warning pops up that the site you will be redirected to is not secure**, do not proceed.  

If the text or mail you received is **guilty of at least one of the formerly listed signs, refrain from opening attachments or links**. Furthermore, **replying or calling the attacker would be counterproductive** – Doing so confirms that your number/e-mail address is in use, making you a potential target for more attacks. Instead, **please block the sender and report the message to your country's national cyber security center**.

### Limit the information you share on social media

While it feels great to share the joys of your life with others, bear in mind that **the more information that is available about you online, the simpler it will be for attackers to manipulate or even impersonate you**. Think about it: Would you be more likely to be suspicious of a spam e-mail sent en-masse or a personal text supposedly coming from your boss or a family member? To avoid falling victim to spear-phishing, we strongly recommend **keeping personal details private or limited for viewing**. 

### Enable Two-Factor-Authentication (2FA) 

Enabling **[2FA or Multi-Factor-Authentication (MFA)](https://zitadel.com/features#multifactor)** adds an additional layer of security to your account that is **[significantly harder for attackers to bypass](https://zitadel.com/blog/2fa-bypass-attacks)**. This protection measure requires users to **provide a second factor** (such as off-device access codes, biometric factors, or a physical token) in addition to their password to confirm their identity. Thus, you will **immediately get notified** if someone attempts to log into one of your virtual identities.

### Do not give away your login credentials!

Whether it’s your online friend, a service provider, or a platform admin, **a person or entity directly asking for your user credentials should always raise suspicion**. It is crucial to note that **a legitimate service or platform never requires users to confirm their password** or access code by sending it to them via e-mail or text message. 

Even if the person asking for your credentials is **someone you know personally** (such as a family member or co-worker), it is **safest to confirm that the person truly is who they claim to be**. For instance, you can ask them in person, call them, or invite them to continue the chat on another platform. Of course, the same principle applies if they request you to make a (high-value) purchase.

## The Takeaway

Since **social engineering attacks can be carried out by virtually anyone**, we are bound to encounter an attempt at least once in our lifetimes. To prevent yourself from falling victim, **your account and personal information must be adequately safeguarded**. 

With **ZITADEL** as your organization’s authentication solution, you can easily protect your end-users’ accounts and sensitive data with the help of **phishing-resistant MFA options (f.e, passkeys), a wide variety of 2FA alternatives, and [many more cutting-edge security features](https://zitadel.com/features)**.



This article discusses the six most commonly encountered social engineering tactics and how to protect your account from cybercriminals.

Social Engineering - How Hackers are Manipulating You

This follow-up article shows how a Web Application and a Single Page Application can securely authenticate end-users and gain access to protected resources using ZITADEL and OIDC.

Secure Logins and Resource Access with ZITADEL and OpenID Connect - Part 2



## 1. Introduction

ZITADEL allows you to add login to your applications to authenticate your users and authorize your application to access those users’ protected resources on their behalf, with or without explicit consent, depending on the type of application you are building. This post will primarily cover how you can do this on ZITADEL with OpenID Connect (OIDC). 

## 2. OAuth2 and OpenID Connect 
First, let’s look at the different grant types introduced in OAuth2, and therefore OIDC, to figure out how to select a grant type for an application based on what kind of app they are. 

### 2.1 OAuth2

[OAuth2](https://oauth.net/2/) is a widely used authorization framework that allows third-party applications to access protected resources on behalf of their owner without requiring the owner to share their username and password with the third-party application. OAuth2 defines several grant types. They specify how you can obtain an access token. In other words, you need to select a grant type based on how you, as the application developer, intend the users of your application to access their protected resources (which reside in a separate resource server) within your application. 

In basic terms, when you specify a grant type, you are telling the authorization server something along the lines of: 


_Dear Authorization Server,_ 

_Here is how I, the client application, would like to receive an access token to access my user’s protected resources on their behalf. As a client app registered with you and assigned a unique identifier, I trust you will make it happen._

_Thanks,_

_Client App X_

#### 2.1.1 Main Grant Types
The introduction of different grant types in the OAuth2 framework, as well as the extensions that are capable of defining new grant types, was necessary to support a variety of use cases and scenarios where access tokens need to be issued. For example:

- [Authorization Code](https://oauth.net/2/grant-types/authorization-code/) grant type is used for web server applications that can securely store a client secret. This is the most commonly used grant type for web-based applications. It involves the client application redirecting the user to the authorization server's login page, where the user logs in and grants the client application access. The authorization server then redirects the user back to the client application with an authorization code, which the client application can exchange for an access token.
- [Proof Key for Code Exchange (PKCE)](https://oauth.net/2/pkce/) grant type is an extension to the Authorization Code flow that protects against Cross-Site Request Forgery(CSRF) and authorization code injection attacks. The PKCE flow ensures that the authentication process is secure by using a code verifier and a code challenge, which are sent to the authorization server to obtain an access token.  PKCE is not a replacement for a client secret, but it is recommended even if the client is using one. PKCE was developed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for any type of OAuth client, including web apps that use a client secret.
- [Client Credentials](https://oauth.net/2/grant-types/client-credentials/) grant type is used for server-to-server communication, where no end user is involved, and the client application is the resource owner. 
- [Device Authorization](https://oauth.net/2/grant-types/device-code/) grant type, also known as the Device Code Grant, is used to allow devices with limited input capabilities to obtain an access token. This grant type involves a set of steps that allow a user to authorize a device. Once the user authorizes the device, the device can use the authorization code to obtain an access token.
- [Refresh Token](https://oauth.net/2/grant-types/refresh-token/) grant type is used to obtain a new access token using a previously obtained refresh token. This grant type is typically used in situations where long-lived access to a resource is required.

#### 2.1.2 Deprecated Grant Types 

- [Implicit](https://oauth.net/2/grant-types/implicit/) grant type (deprecated in [OAuth 2.1 draft](https://oauth.net/2.1/) is used for browser-based applications (such as single-page applications) that cannot keep a client secret confidential. It involves the client application requesting an access token directly from the authorization server by including the access token request in the URL of a redirect URI.
- [Resource Owner Password Credentials (ROPC)](https://oauth.net/2/grant-types/password/) grant type (deprecated in [OAuth 2.1 draft](https://oauth.net/2.1/)  is used for trusted applications that can securely store user credentials and directly exchange them for an access token (without an intermediary access code).  ROPC, however, is often discouraged due to its potential security risks.

#### 2.1.3 Other Grant Types 

OAuth also allows for the definition of new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks. One such grant type is the JSON Web Token(JWT) Profile. 

- [JSON Web Token(JWT) Profile](https://www.rfc-editor.org/rfc/rfc7523) is an extension grant type that uses a JWT Bearer Token to request an OAuth2 access token as well as for use as client credentials without a direct user-approval step at the authorization server.  

### 2.2 OpenID Connect (OIDC)

[OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html), on the other hand, is an extension built on top of OAuth2 that provides additional functionality for authentication and obtaining user identity. The use of this extension is requested by client applications by including the `openid` scope value in the authorization request. Information about the authentication performed is returned in a JSON Web Token (JWT) called an ID Token. The JWTs include claims, which are statements about an entity (typically, the user), as well as additional metadata. A set of standard claims is defined in the OpenID Connect specification. Name, email, gender, birth date, and so on are among the standard claims. If you want to capture information about a user and there isn't a standard claim that best reflects that information, you can create custom claims and add them to your tokens.

While OIDC uses OAuth2 as the underlying protocol for obtaining access tokens, it adds to the grant types by providing a set of **authentication flows** to obtain ID tokens and access tokens, depending on the type of client application and the requirements of the use case. These flows include:

- **Authorization Code Flow** returns an authorization code to the client application, which can then exchange it for an ID token and an access token directly. This provides the benefit of not exposing any tokens to the user agent and possibly other malicious applications with access to the user agent. The authorization server can also authenticate the client before exchanging the authorization code for an access token. The authorization code flow is suitable for clients that can securely maintain a client secret between themselves and the authorization server.
- **Implicit Flow** is mainly used by client applications implemented in a browser using a scripting language. The access token and ID token are returned directly to the client, which may expose them to the end user and applications that have access to the end user's user agent. The authorization server does not perform client authentication.
- **Hybrid Flow** is a combination of the Authorization Code and Implicit grant types, and is used to obtain both an authorization code and an access token in a single request. When using the Hybrid Flow, some tokens are returned from the authorization endpoint and others are returned from the token endpoint. 

The specification places additional requirements on how the grant types are used for authentication and identity management.

#### 2.2.1 Application Types
Because we are looking at adding authentication to the apps, let’s focus on the different application types mentioned in OpenID Connect. There are three primary application types:
- **Web Applications**: These are traditional web applications, such as those built with Java or .NET,  that run on a web server and use a browser to interact with the user. Web applications should use the ***Authorization Code Grant with PKCE*** to obtain an access token.
- **Single-Page Applications (SPAs)**: These are web applications that run entirely in the browser, without a back-end server. SPAs should use the ***Authorization Code Grant with PKCE*** or the ***Implicit Grant (if PKCE is not feasible)*** to obtain an access token.
- **Native Applications**: These are applications that are installed and run natively on a device, such as a mobile app or a desktop app. Native applications should use the ***Authorization Code Grant with PKCE*** or the ***Device Authorization Grant(if the device has no display or mechanism for user input and therefore needs another device)*** to obtain an access token.

### 2.3 Recommendations 
In summary, the **Authorization Code Grant with PKCE** is considered the most suitable grant type for web apps, native apps, and user agents due to its secure method of authentication, smooth user experience, versatility, and recommendation as a best practice by security experts and industry standards, such as [OAuth 2.0 Security Best Current Practice](https://oauth.net/2/oauth-best-practice/).

While **APIs (Application Programming Interfaces)** can be considered as a type of application in the broader sense of the term, they are not typically considered as an application type in the context of OpenID Connect. This is because APIs are not user-facing applications, and their primary function is to provide access to data and services for other applications to consume.
That being said, APIs can still play an important role in OIDC by acting as an OAuth Resource Server that can be accessed by user-facing applications on behalf of end users. In this context, the API may require an access token. The API can then use the access token to authorize access to protected resources on behalf of the user-facing application. These APIs will have to use a grant type such as the **JWT Profile** to access the authorization server’s introspection endpoint to validate the token. 

There will also be client APIs or systems that need to access other protected APIs/protected resources for their functionality and not for accessing resources on behalf of end users, such as the management API of the authorization server or another API that is not tied to user data. These client APIs or systems can acquire an access token using a grant type, such as **Client Credentials Grant**, **JWT Profile**, or another OIDC-compliant authentication flow. 
Each grant type has its own use case and application type. It's worth noting that the specific grant type used by an application will depend on various factors, such as the level of security required, the type of user experience desired, and the capabilities of the application. The choice of grant type should be made with consideration for the specific requirements of the application and the needs of the users.

From a purely technical standpoint, most OAuth2 grants and OIDC flows that support end-user authentication can be made to work in almost any scenario, but doing so has significant security implications. As a result, it is recommended that you adhere to the recommended flows.

## 3. How ZITADEL Authenticates End Users and Authorizes Applications as an OIDC Provider 
### 3.1 Application Types and OAuth2 Grant Types Supported

ZITADEL supports the following application types: 
- Web Application 
- Native Application (mobile or desktop apps)
- User Agent (browser-based apps/single-page applications)
- API

In these scenarios, users can authenticate through user interaction for the first three options (web, native, and user agent), or without direct interaction for the fourth option (API). 

ZITADEL can help with end-user authentication by providing various authentication methods, such as username/password, multi-factor authentication (MFA), passwordless authentication, single sign-on (SSO), and federated identity options. Understanding the different use cases can help in choosing the appropriate authentication method for a particular scenario.

For authorization, ZITADEL supports the following grant types in accordance with the OAuth 2 framework as well as the related specifications like [RFC 6749](https://tools.ietf.org/html/rfc6749), [RFC 8628](https://tools.ietf.org/html/rfc8628), [RFC 7636](https://www.rfc-editor.org/rfc/rfc7636), [RFC 7523](https://tools.ietf.org/html/rfc7523), and [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html). 

- Authorization Code
- Authorization Code with PKCE
- Implicit
- Client Credentials
- JSON Web Token(JWT) Profile
- Refresh Token

ZITADEL does **not** support the following grant types: 
- Resource Owner Password Credentials  (as this is not recommended and will be deprecated in OAuth 2.1)
- Device Authorization Grant (In progress)

### 3.2 Choosing an Authentication Flow for an Application 

<figure>
  <img
    src="/blog/2023-02-27-secure-logins-with-zitadel-part-1-01.png"
    width="100%"
    alt="Applications and Grant Types Supported in ZITADEL"
  />
  <figcaption>
    Figure 1: Applications and grant types supported in ZITADEL
  </figcaption>
</figure>


For each of the following application types (**where end-user authentication is required**), ZITADEL supports the following methods: 

**Web Application (with dedicated server-side component):**
- ***Authorization Code (with PKCE) - Recommended*** 
- Authorization Code 
  - Authorization Code (without PKCE)
  - JSON Web Token Profile
  - POST (including the client credentials in the request body) - Not recommended


**Native Application (mobile/desktop/smart device application):** 
- ***Authorization Code  (with PKCE) - Recommended*** 

**User Agent (SPA/browser-based application):** 
- ***Authorization Code (with PKCE) - Recommended*** 
- Implicit 

**API:**

If you have an API that behaves as an OAuth resource server that can be accessed by user-facing applications and need to validate an access token (either by calling the introspection endpoint or other mechanism such as verifying a private key) in order to grant access to the resource, it is categorized as an API application in ZITADEL. You can use the following methods to register these APIs in ZITADEL: 

- ***JSON Web Token (JWT) Profile (Recommended)*** 
- Basic Authentication 


**Service Users:**

If there are client APIs or systems that need to access other protected APIs/protected resources and do not want to access resources on behalf of end users, these APIs or systems must be declared as service users. A service user is not considered an application type in ZITADEL. These client APIs(service users) can obtain an access token by using a grant type, such as Client Credentials Grant, JWT Profile or an OIDC-compliant authentication flow. The following mechanisms are available for service users to obtain an access token: 

- ***JSON Web Token (JWT) Profile  (Recommended)***
- Client Credentials
- Personal Access Tokens (PAT)

## 4. Wrap Up

In this post, we discussed the OAuth2/OIDC grant types, authentication workflows, and the various ways in which ZITADEL supports them so that you can secure your application in the most optimal way. In [Part 2](https://zitadel.com/blog/secure-logins-with-zitadel-part-2) of this series, we will walk you through the process of registering a web application with ZITADEL, using the recommended Authorization Code with PKCE approach. Hope this post was informative and useful. Thanks for reading, and we'll see you in Part 2!

















This article explains how applications can securely authenticate end users and control application access to protected resources using ZITADEL and OpenID Connect.

Secure Logins and Resource Access with ZITADEL and OpenID Connect - Part 1


**Usernames and passwords** - this combination represented the go-to method of authenticating users for multiple decades. However, as time passed, it has become increasingly evident that relying solely on two words to safeguard personal data is not without its devastating risks. Consequently, countless platforms continue turning to more complex authentication methods to increase their users’ safety.

Perhaps the most commonly used alternative to traditional password-based authentication is **[Two-Factor-Authentication](/features#multifactor) (2FA)**, also known as 2-step verification. 2FA is a security measure that requires users to **provide a second factor** (such as an off-device code, biometric factor, or a physical token) in addition to their password to confirm their identity. While this extra layer of protection can undoubtedly make it more difficult for attackers to access your account, **it is still not entirely foolproof**.

This article discusses five typical methods attackers use to bypass two-step verification or two-factor authentication and some precautions you may take to protect your account.

## The most common 2FA Bypass Attacks

### 1. Password reset

One of the easiest and, therefore, most common ways to bypass two-factor authentication is by **simply utilizing the password reset function of websites and applications**. 

Although **every login function should require the second authentication factor** after two-factor authentication is enabled, one of them is often forgotten. A surprising number of platforms **allow users to access an account after obtaining a password reset token without additional verification**. Obviously, such a blatant security hole makes the job of attackers significantly easier. 

### 2. Social Engineering

Another non-technical method of bypassing two-factor authentication is **Social Engineering**. While this notorious attack takes on many forms, they all share a **common goal of tricking a person into giving away private information**. 

Even if the attacker has **already obtained your user credentials**, they still need to **acquire the additional authentication factor** to gain access to your account. To receive the required code from the victim, **the criminal might call, text, or email them with a seemingly plausible justification**. Of course, they will likely do so disguised as a trusted entity, such as Google or Apple, to minimize suspicion. Make sure to always **double-check the sender’s identity**, as well as the **content of the text message**, to avoid falling victim to a hacking attempt. 

![Social Engineering attempt via text message](/blog/2023-02-16-2fa-bypass-02.png "2FA bypass with SOcial Engineering")

### 3. Man-in-the-middle Attacks

Tech-savvy attackers can even bypass two-factor authentication **without knowing the victim’s login credentials. Man-in-the-middle (MiTM)** attacks describe the phenomenon of **a third party**, also known as a man-in-the-middle, **intercepting the communication between two systems**. 

Similarly to Social Engineering, MiTM attacks **rely on deception to obtain valuable information** from their victim. However, instead of directly asking for the two-factor authentication code, the latter method uses a **malware to extract user session cookies**. Since the cookies contain the user’s data and track their activity, **hijacking them allows the attacker to bypass 2FA easily**. 

A **phishing website** is one of the most popular tools to conduct MiTM attacks. By posing as a trusted entity, the criminal **prompts the victim to authenticate themselves via an attached link**. Due to the website the user is redirected to often seeming legitimate, many people **unsuspectingly enter their credentials to the proxy login page**. Unfortunately, doing so allows the phishing site to obtain **sensitive data about the user**, including personal information, passwords or less secure second factors, and place them into the wrong hands. 

### 4. OAuth Consent phishing

Consent phishing is a relatively **new yet dangerously calculated tactic** attackers use to compromise user accounts. Unlike other 2fa bypass attacks that prey on session cookies and login credentials, this technique **targets users who are already signed in** - making it **immune to all kinds of login protection measures**, such as two-factor authentication and passwordless.

If you are **registered to any type of cloud-based application** (such as Google Workspace and Microsoft 365), you are likely already familiar with the concept of user consent. For instance, when you **use your pre-existing Google account** to sign up for a third-party website or application, a **consent screen will ask for your approval to access the specified data on your Google profile**. Since constenting to this commonly seen prompt is **necessary to utilize the platform**, we tend to disregard it as a pointless reading exercise and routinely click "Accept."

![Consent Screen describing what the app will have access to](/blog/2023-02-16-2fa-bypass-01.png "2FA Bypass with Consent Phishing")

And just like that, all it took was **one button hit to give the person behind the screen unrestricted access to your account**, which is retained **even if you change your password or turn on two-factor authentication**. The actions the platform may take using the obtained information can range from **exploiting your credentials to writing files and sending messages on your behalf**.

While the consequences of user consent might sound concerning, if the platform requesting your permission was legitimate, it is quite unlikely that they had ulterior motives. However, **OAuth 2.0, the standard protocol that lies behind these consent screens, enables almost anybody to register an application**. This makes it possible for cybercriminals to exploit a seemingly reliable OAuth 2.0 authorisation exchange, by **deceiving the user to grant a malicious platform access**.

### 5. Duplicate-Generator

Akin to many other 2FA bypass attacks, the **Duplicate-Generator** is also intended to exploit the security holes in this authentication method. Or, more specifically, **the flaws of the one-time-password (OTP)**. 

Interestingly, many platforms seem to rely on **number generators** to create the security key used as the second authentication factor. These generators typically **begin with a randomly chosen seed value, which is used to produce the first number in the verification code**. If this seed and the algorithm are learned, the attacker **can produce a duplicate of the victim’s generator** that will display the identical set of numbers - and thus, find out the OTP.

### 6. SIM-Jacking

Similarly to Duplicate-generator, this attack operates by exploiting one-time passwords. However, rather than relying on an OTP copy, **Sim-jacking** ensures that **the authentication code lands directly in the hands of the hacker**. 

As the name suggests, this OTP bypass method involves the attacker **hijacking a user's SIM card** to take over their phone number. Given the complexity of contemporary hacking techniques, **the criminal does not need to physically possess the SIM to exploit it**. Simply **tricking a mobile phone provider** into adding the targeted number to the attacker’s phone will allow them to get all text messages intended for the victim - including the OTP.

## How you can protect your account

Despite its shortcomings, **two-factor authentication still remains among the most effective methods for safeguarding your own account**. Although some may have figured out how to bypass 2FA, there are several **countermeasures** to stop such an attack from happening.

## Be Careful With OTPs

Due to their straightforward usage and quick setup, **OTP security codes** have established themselves as the **go-to secondary authentication factor** for numerous accounts. Unfortunately, their simplicity is also their most significant vulnerability. 

**If you are worried about falling victim to sim-jacking or a duplicate-generator attack, consider applying one of the following practices:**

* **Switch to an alternate [2FA method](/blog/passwordless#:~:text=The%20most%20popular,an%20authentication%20software)** - such as biometric authentication or physical tokens.
* **Use an authenticator app to receive the OTP** - such apps (f.e. Authy) exclusively display the verification code on the device you are using and do not rely on an SMS.

## Switch to Passkeys

Passkeys is an alternate authentication method that entirely **relies on a private-public key exchange between a device and the service** to verify a user’s identity. The private key is securely stored on the device and requires the user to **provide a second factor**, such as biometrics, to unlock the key. Although both two-factor authentication and passkeys undoubtedly surpass traditional password-based logins in terms of security, the latter method is **less susceptible to phishing and cyber-attacks due to their complete waiver of passwords**. 

## Evaluate Consent Requests

To **prevent a fraudulent website or application from using OAuth 2.0 to delegate access**, we strongly advise users to **carefully review the consent request**, as well as the data and the permissions it is asking for. If you spot a **spelling or grammatical error** within any text the application displays, the platform is probably illegitimate. Even if the domain appears to be trustworthy, keep in mind that **attackers frequently spoof these to appear to be from a reputable service or company**.

If you have any suspicion about a platform attempting consent phishing, **please report it** either **directly on the consent prompt or to the national cyber security center in your country**.

## Never share your Authentication Code!

Last but not least, consider the age-old rule of keeping your account safe: **Never share your verification code/link** with anyone. Remember: **No legitimate service will ever ask you to reply with the credentials they have (supposedly) just sent you.**

## In Conclusion

As methods for bypassing two-factor authentication advance, so must our countermeasures. With **ZITADEL** as your organization’s **authentication solution**, you can easily protect your end-users’ account and sensitive data with the help of a **safe mechanism for password reset, phishing resistant MFA options (f.e passkeys), a wide variety of 2FA alternatives and [many more cutting-edge security features](/features)**.


This article discusses five typical methods attackers use to bypass two-step verification or two-factor authentication and some precautions you may take to protect your account.

How Attackers Bypass Two-factor Authentication (2FA)


## Key outcomes

- Chapati Systems uses self-hosted instances of ZITADEL for centralized user and access management for both internal users and external customers. 
- Overall, Chapati Systems' use of ZITADEL has improved the user experience and security for their internal and external applications such as Alphalerts. 
- ZITADEL's  ability to authenticate and manage users across various systems, as well as its ability to share data across different apps, will enable Chapati Systems to expand and improve its offerings to customers.


## Introduction

[Chapati Systems GmbH](https://chapati.systems/), founded and led by [Christoph Miksche](https://www.linkedin.com/in/cmiksche), is a new software development company that has been in operation since 2022. Christoph has experience creating software solutions for a variety of industries, including automotive, marketing, and manufacturing. Currently, Chapati Systems' focus is on creating financial and project management applications.

One of Chapati Systems' core offerings, [Alphalerts](https://alphalerts.com/), is a SaaS platform hosted in Germany that allows customers to set filters based on key performance indicators (KPIs) to receive alerts when certain stock, option, or crypto events occur.
The target customers for the app are investors looking for advanced filters and real-time alerts, who want to analyze and build their own strategies.

Alphalerts offers over 80 KPIs for stocks on NYSE and Nasdaq and allows customers to search through thousands of stocks and get alerts when specific events occur.
Users can also query the options and crypto-currencies databases, and receive alerts via SMS, email, or app notifications.

The service allows users to create custom alerts based on their preferred stocks or crypto-currencies, and also offers a 14-day free trial for users to test the platform and its capabilities in addition to the Basic, Pro, and Biz plans. The number of alerts and advanced filters available depends on the subscription plan chosen. 

## Problem

Alphalerts required a centralized identity and access management solution to allow its users to access their accounts securely and seamlessly. Chapati Systems  wanted to offer their users the flexibility to log in to Alphalerts through either a traditional password-based method or their Google accounts because almost all users had a Google account. Additionally, they also wanted to enable MFA, which is optional for the users. 

At the same time, Chapati Systems also required a Single Sign-On solution that allowed their internal users to simplify access to their internal applications, namely their Gitea instance for source control,  CI/CD application, and project management system. 

## Solution

ZITADEL was chosen as the identity and access management solution for Alphalerts, which allowed Chapati Systems to easily identify and authenticate customers.  They also decided to use ZITADEL for internal user authentication and Single Sign-On. Chapati Systems chose to self-host ZITADEL on a Virtual Private Server (VPS) in Germany along with all their internal applications. 

According to Christoph, one of the main reasons for choosing ZITADEL was the simplicity the product offered.
Another was that it allowed an organization to register multiple applications, whereas other identity and access management solutions that were evaluated demanded a separate registration for each application.
So, ZITADEL was used not only to improve security but also to enable Chapati Systems to offer services such as bundle deals for separate applications (Alphalerts and other upcoming apps) and share data across these apps.

## Centralized Identity and Access Management for Alphalerts

<figure>
  <img
    src="/blog/2023-02-09-success-story-chapati-systems-alphalerts-01.png"
    width="100%"
    alt="Application Architecture of Alphalerts"
  />
  <figcaption>
    Figure 1: Application Architecture of Alphalerts
  </figcaption>
</figure>

The architecture for Alphalerts  includes a front-end written in plain Javascript and JQuery, with users able to log in to the system via ZITADEL, and users can create custom queries for alerts based on their preferred stocks or crypto-currencies, then subscribe to alerts via SMS, email or push notifications.

Alphalerts utilizes a Python backend that is integrated with Firebase for push notifications, Twilio for SMS notifications, and an email server for email notifications to provide a variety of notification options, giving users the flexibility to receive alerts in the way that best suits them.

The “Collector” component in the backend continuously collects data from various financial data APIs and feeds the stock data into a MongoDB database. Data related to users are stored in an SQLite database. The backend is also responsible for processing the user's filters and sending out notifications based on those filters. This allows for alerting and ensures that users receive the most up-to-date information on the stock, option, or crypto events they are interested in. 

ZITADEL allows Alphalerts to easily authenticate and manage access for each user, ensuring that only authorized users have access to the platform and their personalized alerts. ZITADEL uses PostgreSQL as the  database  to store user data. 

All the core components of the Alphalerts application are hosted on its own VPS. ZITADEL is hosted on a separate VPS with the rest of the internal applications of Chapati Systems. 

## Single Sign-On for Internal Applications

To manage user identities and access across their internal projects and public applications, Chapati Systems chose ZITADEL as their central user management and identity solution. ZITADEL's centralized platform allows Chapati Systems to easily manage and authenticate internal users across their various systems, including their Gitea instance, CI/CD, and project management systems. The internal users currently use Google login with optional MFA. For MFA, they use  OTP code and passwordless with Apple FaceID/TouchID.

<figure>
  <img
    src="/blog/2023-02-09-success-story-chapati-systems-alphalerts-02.png"
    width="100%"
    alt="Use of ZITADEL for Single Sign-On for Internal Applications"
  />
  <figcaption>
     Figure 2: Use of ZITADEL for Single Sign-On for Internal Applications
  </figcaption>
</figure>

## Future Plans

os.money is a new app being developed by Chapati Systems that allows users to track their existing portfolio of companies and receive updates on any significant changes. The app will use certain key performance indicators (equity-to-debt ratio, revenue growth rate, and other audit KPIs) to identify potential red flags in a company's financials that are often overlooked by investors but are crucial for auditing and assessing the trustworthiness of a company's balance sheet. 

In summary, Alphalerts is a tool designed to help users discover new investment opportunities, while os.money is focused on providing a way for users to monitor and assess the safety of their existing investments. However, the two apps will share some similarities.

ZITADEL will play an important role in os.money by providing user authentication and allowing for data sharing across the app, Alphalerts, and other upcoming products. This will enable users to use their os.money portfolio data in Alphalerts and create additional filters that only check companies from their existing portfolio or companies not yet in their portfolio. This data sharing will allow the system to better understand the user's interests and make personalized suggestions based on the data from both apps.

<figure>
  <img
    src="/blog/2023-02-09-success-story-chapati-systems-alphalerts-03.png"
    width="100%"
    alt="ZITADEL's Organization Structure Allowing for Sharing of Resources Between Projects"
  />
  <figcaption>
     Figure 3: ZITADEL's Organization Structure Allowing for Sharing of Resources Between Projects
  </figcaption>
</figure>

This is possible due to the fact that ZITADEL has the ability to [grant different projects](/docs/concepts/structure/granted_projects) to customers individually, which is a significant advantage for these cases.

For example, if a customer has a subscription for Alphalerts and wants to purchase os.money, the grant for project os.money can be easily added to the Alphalerts organization in ZITADEL through automatic processes, such as a call from the subscription component. This offers the following benefits:

- Self-service (e.g., authorizing users) can be done like with Alphalerts.
- Clients can discover available and authorized services.
- Downgrading is as easy as removing the grant, which is then propagated to all users.

Therefore, in addition to the standalone subscription, Chapati Systems will also offer combined subscription plans for os.money and Alphalerts at a discounted rate for existing Alphalerts users. This will allow users to benefit from the full suite of Chapati Systems products and make the most of their investment decisions.

## Testimonials

<img
  src="/blog/2023-02-09-success-story-chapati-systems-alphalerts-04.png"
  width="200px"
  alt="Portrait of Christoph Miksche"
/>

“ZITADEL is the best identity management system I have used. It is perfect for managing users across multiple apps, and it offers innovative features like passwordless authentication, which I got used to.

I plan to use ZITADEL for managing users across all my different programs for both customers and employees. Third-party login definitely makes it easier for customers to sign up, and as a single source of trust, it can be used for combined marketing and data sharing efforts across multiple apps.” - [Christoph Miksche](https://www.linkedin.com/in/cmiksche) founder of [Chapati Systems GmbH](https://chapati.systems/)

Read Christoph's own opinion on selecting an open-source identity provider [here](https://blog.m5e.de/post/open-source-authentication-solutions/).

Chapati Systems uses self-hosted instances of ZITADEL for centralized user and access management for both internal users and external customers.

Built with ZITADEL: Improved User Experience and Security for Chapati Systems

Last month, we said goodbye to the old year by reflecting on the **[many ways ZITADEL improved in 2022](https://zitadel.com/blog/best-of-zitadel-2022)**. Now that that is all said and done, it is time to **take a peek at the horizon**.

As a company that always strives for innovation in an ever-changing digital world, our biggest goal is to **provide our customers with the best possible user experience and the most value for their money** by constantly keeping ZITADEL up to date. This article showcases **the most significant features [scheduled to launch in the year 2023](https://zitadel.com/roadmap).**

## 1. Configurable Social/Enterprise Login Templates

After lengthy anticipation, **the new [social login](https://zitadel.com/blog/social-logins) options for ZITADEL** are just around the corner!

Social login, and more generally [identity brokering](https://zitadel.com/blog/what-is-an-identity-broker), is an authentication method that utilizes users’ pre-existing **social media identities to facilitate sign-ups** on third-party platforms. This popular alternative for the standard username-password login **does not require completing a registration form**, thus saving you valuable time and the hassle of remembering yet another password.

Whereas thus far, ZITADEL has exclusively supported OIDC-compliant identity providers, this restriction will soon be completely removed to provide a **wider range of options** - ensuring that both you and your customers can **seamlessly log in using your preferred social media profiles**.

Our new identity providers include:

* Google
* Github
* Gitlab
* and Azure AD

## 2﻿. Fully customizable Login UI

Ever since the launch of the platform, ZITADEL has enabled businesses to **seamlessly authenticate their users with a customizable [hosted login and registration page](https://zitadel.com/docs/guides/solution-scenarios/b2c#hosted-login)**: a fixed authentication endpoint that is secure by default. Whereas so far, you have had the option to disable the hosted registration page and **build your onboarding process from scratch**, a **custom login API was not yet implemented**. While the hosted login page offers various personalization options for branding purposes - such as colors, logo, and typography – the range of potential alterations is ultimately limited. 

Within the course of 2023, we would like to give businesses with specific needs the option to **replace the default hosted login page and build their [own login User Interface (UI)](https://github.com/zitadel/zitadel/issues/5015).** While this alternative will completely lift the limitation on the scope of aesthetic personalization, the core functionality of the custom login UI will remain unchanged to satisfy the highest security standards.

## 3. New Event Audit Log – Filters and Threat Detection

Thousands of **modifications are performed on ZITADEL instances every minute**, ranging from minor adjustments like adding a user nickname to prominent ones like an improved password policy. Every crucial information about these so-called “events” is **collected and stored in a log** - including the event’s date, description, and the user who initiated it.

With the introduction of the **new ZITADEL event audit log**, every action and modification performed on an organization will be **accessible and reviewable directly in the console or via our APIs**. Users may utilize a variety of filters to quickly and efficiently sort and find specific events. Having this report readily available will not only **facilitate general surveillance,** but also **troubleshooting security investigations, and compliance reporting**. Should you detect a suspicious event (such as unauthorized access), the audit log allows you to flag and report it right away.

Furthermore, the log will provide developers the opportunity to **create an action using custom code** for each possible ZITADEL event, enabling them to construct unique workflows.

## 4. Client Credentials as JWT & PAT Alternative

In the year 2022, ZITADEL’s service accounts could **authenticate by using a JSON Web Token (JWT)-Profile** or directly generate a **[Personal Access Token (PAT)](https://zitadel.com/blog/new-personal-access-token)** for authorization. While the former method is undoubtedly the more secure path to take, it is not universally supported. As a response, PATs were introduced to authenticate service users that have trouble integrating their accounts with JWT Profile.

Since both of these options come with their respective weaknesses in terms of compatibility and usability, we have decided to implement a **3rd alternative to authenticate service accounts: [Client Credential Grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.4)**. By using this grant type, clients are enabled to request an access token to **retrieve protected resources under their control** or those of **another resource owner** that have been previously arranged with the authorization server.

## 5. Device Authorization Grant

While obtaining an access token should be quick and simple, **authenticating a device that does not have an easy way to enter text** can be frustrating at best and impossible at worst.

In the following months, ZITADEL aims to fix this inconvenience by **implementing [Device Authorization Grant](https://github.com/zitadel/oidc/issues/264)**. This extension **allows input-constrained devices,** such as smart TVs and printers, as well as **devices with no browser**, **to obtain an access token** with the help of a secondary device.

## 6. More ZITADEL Cloud Data Regions

When it comes to **data processing**, there is no "one size fits all"; different businesses tend to have their main customer base, offices, and headquarters at distinct locations. The country or **region where an institution will store and process your organization’s data should be carefully considered** to prevent latency problems and possible data loss.

Since the latest version of ZITADEL Cloud launched in 2022, the platform’s **SaaS service offers [three data regionality options](/docs/legal/service-description/cloud-service-description#data-location)** to choose from: Switzerland, Global, and GDPR-compliant regions. To facilitate our customers' decision in choosing the right data center, the latter two options **automatically select three housing regions** based on the locality of end-users.

While this automation comes as a big help to many, in 2023, we would also like **to give users more directly selectable data locations to choose from**, such as “Germany”, “Japan” or “Canada”. Which locations are ultimately chosen will rely on both user demand and if they adhere to ZITADEL's privacy standards.

Do you have a data region you would like to suggest? **Please feel free to share your ideas on [Github](https://github.com/zitadel/zitadel) or by contacting us directly.**

## 7. Improved Developer Experience

Since documentation is essential for offering **additional information about a platform's functionality**, ensuring that the guides are coherent and easily comprehensible should be a top priority.

In the following months, ZITADEL is planning a **complete rewrite of its [documentation](https://zitadel.com/docs)** that will additionally **provide a more efficient way to explore our APIs** and **more example applications in your language of choice** to facilitate your onboarding process.

But documentation is not enough to offer a great experience and have a pre-configured ZITADEL platform that is ready to use within minutes. This year, we are implementing some **essential tweaks** that will make this **onboarding process faster and easier than ever,** including:

* New users will be offered additional assistance with the first relevant steps.
* Fewer steps will be needed to create a new instance.
* Relevant settings will be easier to find with the help of an improved console.

 An **improved documentation, quickstarts and an easy to understand user interface** make it overall faster and easier to use ZITADEL. Not only to get started quickly, but also to make it your own.

## 8. More Trust

We are happy that our **community of open source and ZITADEL Cloud users is thriving** and many discussions and questions happen in the open on Github or our [Chat](http://zitadel.com/chat). However, there are situations when **disclosing some private information is necessary to resolve a problem**. So far, our customers have only been able to do so via email. Our goal is to provide a **more seamless private and secure support channel** to share relevant information directly with our engineers to get help as easily as possible.

**Transparency and Support** are keystones for us in building trust. This year we want to prove that we are **fully committed to safeguarding your data**. Not only are we **[GDPR-compliant](https://zitadel.com/gdpr)**, and conduct regular security audits of our platform and **[publish the results on our website](https://zitadel.com/blog/tags/pentest)**, but we strive to certify our information security standards through an external audit this year. With that, we can provide you with certifications for the highest compliance requirements.

This article showcases the most significant features scheduled to launch in the year 2023.

Blog.