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


The most distinct feature of ZITADEL is how you can structure your identity architecture around Users and Organizations.
Whether you're building a customer-facing app and looking for a CIAM solution to handle authentication for you, or trying to offer hundreds of business customers and partners the ability to use their identities and delegate permission management to your customer, it's worth understanding how you can build your solution scenarios with ZITADEL.

This article aims to give you an overview of the overall concepts used and explain the most important points, so you can get started with enough knowledge at hand.

## Organization vs. Instance

The highest level of separation in ZITADEL is an [instance](/docs/concepts/structure/instance).
ZITADEL allows you to operate multiple virtual instances on the same system with the same database.

Access across instances is not possible.
Instances can be managed with the [System API](/docs/apis/introduction#system) as described in this [Guide](/docs/guides/integrate/access-zitadel-system-api).

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-12.png"
    width="80%"
    alt="Two instances with each organizations in it using the same database"
  />
  <figcaption>Two isolated instances with individual organization structures using the same database</figcaption>
</figure>

It's important to note that some settings can only be set per instance, specifically:

- SMTP Service: All emails within the instance will be sent from this service
- Custom Domain: You can define under which domains (eg, `login.demo-vendor.com`) the ZITADEL service can be accessed

> **Note:**  
> At the time of writing, token lifetimes can only be configured on instance level.
> There is no technical limitation, but it is an outstanding [feature](https://github.com/zitadel/zitadel/issues/5219).

Instances provide one form of multi-tenancy in ZITADEL, where each tenant is completely isolated.
However, most scenarios might involve some form of self-service or fluidity between the different tenants to reduce administrative overhead.
These cases most often leverage our organization model within a single instance.

## Organizations

Think of an organization as a way to group users and set shared policies (our term for "settings") such as login, security, branding.
Organizations also allow you to manage applications centrally and grant other organizations to them.

### User Management

In the following diagram, you can see two organizations.
One for a service provider, for example a software vendor or project like you, and one for a customer organization.
Each organization has its own users.

![](/blog/2023-04-15-multi-tenancy-with-organizations-01.png)

[Users](https://zitadel.com/docs/concepts/structure/users) will always belong to one [organization](https://zitadel.com/docs/concepts/structure/organizations).
You have a high degree of flexibility when it comes to how you structure your identities.
You can put all your users in one organization and use ZITADEL like any other CIAM.
Just as well, you might want to split users in different groups.
For example, you may want to separate your customers from your team members or employee identities.
Alternatively, you may want to keep each of your customers' identities in its own organization.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-02.png"
    width="100%"
    alt="List of organizations of an instance"
  />
  <figcaption>List of organizations of an instance</figcaption>
</figure>

### Managing Roles and Applications

Each organization can have multiple [projects](https://zitadel.com/docs/concepts/structure/projects), and each project can contain multiple applications with a shared set of [roles](https://zitadel.com/docs/concepts/structure/projects#roles).
Think of a project like a "shared security context" for [applications](https://zitadel.com/docs/concepts/structure/applications) that logically belong together.
For example, a web app and mobile app, or a front-end and back-end of the same service.

In the example below, you can see that the service provider has the two projects **Portal** and **Data Cube**.
**Portal** would serve as customer portal for all customers to access their services and contains roles like **reader**, **admin**, **support:read**, **support:write** to grant users a different set of permissions.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-03.png"
    width="100%"
    alt="Multiple projects in one organization"
  />
  <figcaption>Multiple projects in one organization</figcaption>
</figure>

The service **Data Cube** may require different roles, such as **analyst**, **engineer**, **manager**, and could be granted to customer organizations based on a subscription option.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-04.png"
    width="100%"
    alt="Multiple applications in a project that share the same roles"
  />
  <figcaption>Multiple applications in a project that share the same roles</figcaption>
</figure>

### Login and Access Policies

For each organization, you can define individual policies around login, access, branding, and domains.

With the [security settings](https://zitadel.com/docs/concepts/structure/policies) per organization, it is possible, for example, to configure different external identity providers per customer organization.
You could configure one organization to allow login with a customers' AzureAD tenant, while configuring another customer organization to login with a local password and 2FA.

At this point, you might ask yourself: How to redirect users to the correct domain?

One way would be to setup [domain discovery](/docs/guides/solution-scenarios/domain-discovery) on your instance to route users according to their login name or email address.
Another option is to send a reserved scope with your auth request to enforce the organization's policies on the login.

## Delegated Access Management

> **Broken Authorization is a Major Risk to Web Applications**  
> The highest-ranking risk for web-applications is [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/), according to the [OWASP Top 10](https://owasp.org/Top10/).
> Providing a secure way of authorization in a multi-tenancy setup, while allowing for self-service, is difficult to achieve.
> We built ZITADEL, based on our experience, from the ground up with this particular challenge in mind, so you don't have to worry about it.

Now we get to the more interesting part of the setup.

How can you give other organizations access to a project and its applications?
And once the organization has access, how can they give permissions to their users?

That is where the unique delegated access management feature of ZITADEL comes into play.

Instead of copying over all projects or applications to each customer organization, which would result in quite some overhead to manage at scale, you can [grant projects](https://zitadel.com/docs/concepts/structure/granted_projects) to other organizations.

### Project Grants

With a [project grant](https://zitadel.com/docs/concepts/structure/granted_projects), you can select a subset of roles that the receiving organization can assign to their users.

![](/blog/2023-04-15-multi-tenancy-with-organizations-01.png)

As an example you could keep certain administrative roles for support or developers in your own organization.
Or you might want to only grant a role once the customer has subscribed to a feature in your application.

Think of a project grant as creating a link to the project.
You don't need to manage the applications within each organization, but only grant them to other organizations.
The receiving organization will see an incoming projects as a "Granted Project" and cannot change the project and that project's applications directly, but only use the roles to authorize their own users.

In the following screen, you can see that the project **Portal**, which is owned by the organization **Demo-Vendor**, has two active grants to **Demo-Customer** and **Demo-Customer2** respectively.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-05.png"
    width="100%"
    alt="Project grants from Demo-Vendor to customer organizations"
  />
  <figcaption>Project grants from the service provider Demo-Vendor to customer organizations</figcaption>
</figure>

The organization **Demo-Customer2** sees the granted project under the tab "Granted Projects". When clicking on it, you can't edit the project itself, like how Managers of **Demo-Vendor** could, but only assign the granted roles to your users, given you have the permissions.
We will discuss Managers in the next section.

<figure>
  <img src="/blog/2023-04-15-multi-tenancy-with-organizations-06.png" width="100%" alt="List of granted projects" />
  <figcaption>Granted (incoming) projects in the customer organization</figcaption>
</figure>

You can always get an overview of all authorizations under the **Authorizations** tab in the ZITADEL console.
Here you can also see that the user **Eric Employee** has the role **reader** in the granted Project **Portal**.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-07.png"
    width="100%"
    alt="Authorizations can be given to granted projects"
  />
  <figcaption>Authorizations can be given to granted projects</figcaption>
</figure>

When **Demo-Vendor** removes the project grant to an organization, then all authorizations will be removed as well.

### Delegate Self-Service to Customers

[Managers](https://zitadel.com/docs/concepts/structure/managers) allow you to let organizations self-assign roles to users, thus authorizing them to access the granted Project.
Managers are an internal role and permission concept of ZITADEL.
The concept offers many use cases for delegating [self-service](https://zitadel.com/docs/concepts/features/selfservice) to users in other organizations.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-08.png"
    width="100%"
    alt="Machine and human users can take on different manager memberships"
  />
  <figcaption>Machine and human users can take on different manager memberships</figcaption>
</figure>

For example, in a SaaS application, you might assign a manager role to the first user in a new organization.
With that, this user could, for example, configure SSO and assign roles to their team members.

Integrate self-service features for managers into your application by using our APIs, or start your POC by letting users configure their organization via the branded console.
The console will always be scoped to the manager permissions of a user.

## Authorize Users Outside of Your Organization

But wait... there is more 🤯! We've already learned that you can isolate tenants with [instances](/docs/concepts/structure/instance). We also saw how create a multi-tenancy setup with [organizations](https://zitadel.com/docs/concepts/structure/organizations) that allow for grouping users, individual security policies (such as configurations of external identity providers), and delegating access management using [managers](https://zitadel.com/docs/concepts/structure/managers).

So, how about a situation where one of your customers wants to invite users from another of your partners/customers and give them access to their organization's resources?

Here are a few of use cases for this:

- Accounting: You offer an accounting platform for SMEs. Your customers are the SMEs but also fiduciaries and accounting firms as partners that manage the finances of the SMEs. Each SME and partner would have their own organization with their own users and either log in with their business account or with a local account on your platform. The SMEs can grant access to their organization by inviting users of partners and authorize them with specific roles as part of your organization, so that they get access to the data they need.
- Education: You are an EdTech provider for different schools. You have an organization per school with teachers and students as users. Some teachers are, however, also responsible for conducting classes at another school. You can create a user grant for these teachers to the secondary placement. Note: in case the accounts would not be managed by one primary school, you would anyway set up two accounts and manage the logic to select an account in your application.
- Healthcare: A university hospital is sponsoring a platform for cross-hospital knowledge and case exchange (e.g., scientific boards). Instead of creating separate accounts for each participant in your organization, you could create an organization for each participating organization. Then let users sign in with their existing accounts from their hospital and create a user grant, such that they get access to your project where you assign roles for the digital collaboration workspace.

Technically this would look similar as indicated in the next diagram.
As service provider, for example for a time-keeping app, ACME organization owns a project with the roles **Accountant** and **Developer**.
The project is granted to both Alpha and Beta where Beta has assigned Bob already the role **Developer**.

Alice from Alpha is the accountant of Beta and requires regular access to the time-keeping app to do her job.
Beta can create a User Grant for Alice and assign her the role **Accountant** in self-service.
Alice can now access the Project as external user of Beta with her role.

ACME must implement the application permissions for such cases within their application.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-10.png"
    width="100%"
    alt="User Grants allow you to grant access to users managed by another organization and assign them roles"
  />
  <figcaption>
    User grants allow you to grant access to users managed by another organization and assign them roles
  </figcaption>
</figure>

This feature goes beyond a traditional multi-tenancy approach by also allowing delegated access management tenant-to-tenant via user grants.
You can integrate such external user management with ease in your application using our [APIs](/docs/category/apis/resources/auth/user-authorizations-grants).

Here is how you can set up a user grant via the ZITADEL console:

1. Go to **Authorizations** and press **N** (or click the button) to create a new authorization.
2. Under the text field **Loginname** there is a hint "If you want to grant a user of another organization click here".
3. Click on **click here** to switch to external users.
4. Enter the loginname of the external user and select a granted or owned project.
5. Go to the next screen and add the roles to the user.

<figure>
  <img
    src="/blog/2023-04-15-multi-tenancy-with-organizations-11.png"
    width="100%"
    alt="Create a user grant in the console"
  />
  <figcaption>Create a user grant in the console</figcaption>
</figure>

The user will be now visible under Authorizations.
You can't view or edit the user's details, since it is being managed by another organization.
But you can change the associated roles like for internal users.

## Conclusion

We went through several aspects of multi-tenancy of ZITADEL:

- Use instances to completely separate tenants
- Use organizations to group users, security policies, and other settings
- Manage your project centrally in one organization and grant the project to other organizations
- By assigning a Manager, a receiving organization can give permissions to their users via the incoming project
- You can also invite external users from another organization to your organization and give them permission to your owned or granted projects

In conclusion, ZITADEL has a high degree of flexibility to fit your use case. ZITADEL's multi-tenancy features provide a comprehensive solution for managing users, projects, and security policies across multiple tenants, ensuring a secure and efficient environment for your applications and services.
Check out our [Solution Scenarios](/docs/guides/solution-scenarios/introduction) and try out the [Sample B2B application](https://github.com/zitadel/zitadel-nextjs-b2b) for more hands-on learning.


This article explains the most important concepts on how you can structure your multi-tenancy identity architecture with organizations.

Multi-Tenancy and Delegated Access Management with Organizations


Whether it is a social media site, an online game, or even a banking app - **registering to any platform generally necessitates the determination of a new password**. To diminish the risk of higher-scale data breaches, this set of login credentials **should not be reused** across multiple platforms. But is it realistic to anticipate individuals to remember each distinctive password for their conceivably dozens of virtual identities?
 
In recent years, numerous businesses have implemented solutions like **federated identity management (FIM) and single sign-on (SSO) to enhance authentication process security** while minimizing password fatigue. While both of these tools aim to facilitate access to resources, they present **two distinct approaches to identity and access management (IAM)** that differ in scope and complexity.
 
This article discusses the difference between Federated Identity Management (FIM) and Single-Sign-On (SSO) and their respective uses.

![SSO Illustration](/blog/2023-04-27-sso-vs-fim-01.png "Single-Sign-On")

## What is Single-Sign-On (SSO)?

**Single-Sign-On (SSO)** is a mechanism that enables you to delegate end-user account creation and administration to a **centralized Identity Provider (IdP)**, thus allowing users to **access multiple resources within the same organization with a single login process** seamlessly. Though the same server manages these individual accounts, they are still entirely separate from each other: For instance, Google only requires its users to **authenticate once with the central identity provider to access multiple resources**, such as YouTube, Gmail, and Drive.

One of the most significant advantages of SSO is that it **improves business security by lowering the number of passwords that users must manage**. To achieve this, SSO relies on authentication protocols, such as **[Security Assertion Markup Language (SAML)](https://zitadel.com/blog/saml-support) and [OpenID Connect (OIDC)](https://zitadel.com/blog/secure-logins-with-zitadel-part-1)**, which enable users to authenticate once with a central identity provider and then access multiple resources without having to re-enter their credentials. Furthermore, unlike it is used to be the case within an enterprise setup, **applications with an SSO feature only receive authentication tokens instead of the credentials themselves**. Thus, the leakage of passwords/credentials to compromised applications/services can be prevented. 

Since passwords are a common attack vector, lessening dependence on them minimizes the possibility of data breaches and social engineering attacks.

## What is Federated Identity Management (FIM)?

**Federated Identity Management (FIM)** connects identity management systems by establishing a trusted relationship between **different organizations**, allowing them to **utilize the same digital identity to access all their applications** and networks (single access). The reason behind its development was to **enable entities on one domain to access user information held in other domains**.

The enterprises are **linked via third-party identity providers that store their credentials**. Furthermore, FIM enables the safe transfer of authentication and access information between domains by **relying on robust security protocols such as SAML and OpenID Connect (OIDC)**, akin to SSO. Accordingly, users are provided with a secure and streamlined login experience, while allowing the respective organizations to retain control over user authentication and authorization.

A real-life example of FIM is using Facebook credentials to log into several services federated with Facebook, such as Instagram, Netflix, and Disney+.

## SSO vs. FIM

It goes without saying that Single Sign-On and Federated Identity Management seem relatively similar at first glance: **They both simplify authentication for consumers and businesses by merely requiring a single set of credentials to access various resources**. In fact, they can even be used jointly because **FIM significantly relies on SSO technology** to authenticate users across domains.

So, **since FIM can technically give us SSO as well**, it should be a no-brainer for every company to deploy FIM, right? Not necessarily. 

Despite their similarities, the two approaches operate in quite different ways and have **unique applications**. To assist you in determining which technique's implementation would suit your organization better, the following paragraphs showcase **the most notable distinctions between SSO and FIM**. 

### Range of Access and Scalability

The most prominent distinction between the two mechanisms is their **range of access**. While both approaches allow users to access a plethora of resources through a single login procedure, in the case of **SSO**, this admission **only pertains to a specific organization or a set of related organizations**. On the other hand, **identity federation** takes a step further by **allowing access across various organizations and domains within the federated group**.

SSO's smaller range of access may also pose a **scalability challenge** for businesses that use a diverse set of apps and platforms. Thus, **switching to a federated identity provider** would enable users to **access their employers' entire array of services, provided they support identity federation**.

### Complexity and Cost

Given its significantly broader range of access, it is no surprise that **FIM solutions are generally more complex and costly to operate**. They require managing more resources and may require specialized expertise to implement and maintain. Additionally, FIM **necessitates the establishment of trust relationships** among various identity providers.

Ultimately, both of these attributes **highly depend on the size of your organization, the number of applications you wish to integrate,** and the **specific requirements of your security and compliance policies** - neither FIM nor SSO comes with a predefined price tag.                                                                                                                                                                                                                                                                                   

### Security

Due to their diverse built-in security integrations, **both SSO and FIM are highly secure mechanisms for protecting personal data**. However, one contentious aspect of SSO stems from its reliance on a single identity provider: Accordingly, **if the IdP suffers a security compromise, it may impair access to numerous resources** and applications as a result. In the case of federated identity management, **the user credentials are not stored in a centralized location**; thus, the danger of a single breach compromising all accounts is lower.

However, it is worth noting that **most SSO vendors enforce strict security policies to ensure the password is as safe as possible**, such as giving it an expiration date or locking the account after some failed login attempts. 

## In Conclusion

Ultimately, **the decision to implement Federated Identity Management or Single Sign-On should be based on your company's specific characteristics**. For instance, companies that use a limited number of apps and services may find SSO a more suitable fit. In contrast, **FIM is often preferred in larger enterprises with several identity providers** and service providers or when cross-organizational collaboration is required. 

Whether you wish to deploy SSO or FIM, **with ZITADEL as your organization’s authentication solution, both options are well accounted for**. You may implement our **SSO feature** or utilize our **JSON Web Token Identity Provider (JWT IDP)** to use an (existing) JWT as a federated identity. 


Numerous businesses have implemented solutions like federated identity management (FIM) and single sign-on (SSO) to enhance authentication process security while minimizing password fatigue. This article discusses the difference between these two approaches.

Single Sign-On (SSO) vs. Federated Identity Management (FIM) - The Key Differences


[ZITADEL](https://zitadel.com) is an open source identity platform that addresses the challenges of self-service, authentication, and authorization by integrating them into your project. It supports multi-tenancy for business-to-business (B2B), identity brokering, multifactor/passwordless authentication, delegated access management, in-context audit trail, [OpenID Connect](https://openid.net/connect/), SAML 2.0, and [OAuth 2.0](https://oauth.net/2/). 

In contrast, [Firebase](http://firebase.google.com/) is a backend as a service (BaaS) that provides developers with a variety of tools and services to help them build quality applications. It's categorized as a NoSQL database platform because the data is stored in a JSON-like format.

With ZITADEL, you can avoid hours of creating, configuring, and operating complex authentication and authorization systems. Meanwhile, Firebase on the other end provides you with commodity features for all of your backend needs, including cloud messaging, testing, crashlytics, authentication, and real-time databases.

Developing with a powerful and feature-rich platform can be essential in creating a reliable and high-quality mobile and web application. It takes a lot of dedication and time to manage files and resources, server configuration, analytics, and other related operations.

In this article, you'll compare ZITADEL and Firebase authentication and look specifically at where they differ in regard to their authentication and authorization features, integrations, and architecture.

## ZITADEL vs. Firebase

ZITADEL and Firebase can both be used to achieve authentication and authorization in your application. However, there are a few factors, like authentication features and integrations, that can help you decide which platform is best for you. Let's take a look at the authentication features each platform offers:

### Firebase Authentication

The main goal of an authentication provider is to be able to identify each user in your application, which is where Firebase Auth comes into play. With Firebase, you have to obtain an authentication credential from the user in order to sign them into your application. The user's email address and password or an OAuth token from a third-party service can serve as these credentials. If you choose to upgrade to Firebase Authentication with Identity Platform, you can authenticate users on your platform with any identity provider that supports [OIDC](https://firebase.google.com/docs/auth/web/openid-connect) or [SAML](https://firebase.google.com/docs/auth/web/saml).

You can incorporate a quick sign-up and sign-in feature for your users using FirebaseUI Auth. By doing so, users spend less time creating profiles or signing up, which boosts conversion rates. Additionally, it tackles scenarios that can be tricky to manage appropriately in terms of security, such as [account recovery and account linkage](https://firebase.google.com/docs/auth/web/firebaseui). Furthermore, the Firebase SDK Authentication is also an authentication function you can include in your application. It gives you various authentication functions, including the following:

- **Email and password authentication:** Users that sign in with their email addresses and passwords can be created and managed using the Firebase Authentication SDK.
- **Third-party-powered authentication:** Google, Facebook, Twitter, and GitHub user accounts can be used to log in using the Firebase Authentication SDK's APIs.
- **Phone number authentication:** Users can be authenticated after receiving a one-time password (OTP) SMS message on their phones.
- Other authentication channels include custom authentication using a limited list of [federated identity providers](https://firebase.google.com/docs/auth/where-to-start#firebasesdk), any third-party identity providers on a [pricier plan](https://firebase.google.com/docs/auth#identity-platform), and anonymous authentication for temporary accounts.

Firebase authentication can also be achieved using an identity platform. You have the option to add an optional authentication feature (like multifactor authentication, blocking function, multi-tenancy, SAML, and OIDC) to your application using the [Identity Platform](https://firebase.google.com/docs/auth).

### ZITADEL Authentication

ZITADEL provides you with the option to use third-party-powered authentication to provide trust between your application and the users. For instance, if you set Google as an identity provider, ZITADEL can redirect the user to log in with their Google account and give ZITADEL access to take their credentials as a form of identification on the platform.

You can use the following authentication features with ZITADEL:

- You can register an OIDC client of your choice and add a ZITADEL callback redirect (make sure the provider is OIDC 1.0 compliant with a proper [discovery endpoint](/docs/guides/integrate/login-users). This will give your users the option to log into your ZITADEL-powered application using the OIDC authentication feature.
- You can use a SAML sign-in option that gives your users the ability to authenticate once and gain access to multiple secured parts of your application without resubmitting their credentials.
- You can choose to let your users log in with a traditional username and password.
- You can authenticate via external identities, such as Google, Microsoft, or Apple.
- You can force a user to register and use multifactor authentication through a universal second factor, such as OTP, alongside their pin.
- You can decide to use passwordless login authentication. Your user can either use device-dependent (e.g., fingerprint, face recognition, and [Windows Hello](https://support.microsoft.com/en-us/windows/learn-about-windows-hello-and-set-it-up-dae28983-8242-bb2a-d3d1-87c9d265a5f0)) or device-independent (e.g., [YubiKey](https://www.yubico.com) and [SoloKeys](https://solokeys.com)) access.
- You can use multi-tenancy authentication to allow a user to authenticate themselves once with authorizations in multiple organizations. It simplifies the whole authentication process for users regardless of their tenancy, while allowing you to have multiple organizations with different users. ZITADEL ensures each tenant has complete privacy regarding their data, a highly-customizable login flow, and on-demand scaling.

As you can see, both ZITADEL and Firebase provide numerous ways to authenticate your users. However, ZITADEL stands out in that it gives you open access to any third-party [identity broker](/docs/concepts/features/identity-brokering) without any complex pricing plans. You can use OIDC or SAML to connect with any third-party identity provider and provide your users with the authentication they want.

If you're in need of a quick authentication feature for your application, Firebase is a good option. However, if you need more advanced authorization, user self-service, and multi-tenancy features for your application, ZITADEL is the superior choice because it's built to handle your authentication needs, no matter the complexity of your application.

### Firebase Integrations

Programming in C++, Java, JavaScript, JavaScript/Node.js, Objective-C, and Swift is supported by the [Firebase SDK](https://firebase.google.com/docs/firestore/client/libraries). Database bindings and libraries with limited functionality in [Angular](https://github.com/angular/angularfire), [Backbone.js](https://github.com/googlearchive/backbonefire) and [Ember.js](https://github.com/FirebaseExtended/emberfire) are also supported.

For the uninitiated, bindings are basic mappings of APIs to in-code functions that carry out standard operations like CRUD. However, they're not as detailed as SDKs, and sometimes a binding scan can go beyond the basic CRUD operations and offer cosmetic improvements or alternatives to existing methods and features, in which case they are often referred to as auxiliary or supplementary bindings.

Google has added a few supplementary bindings and libraries like [FirebaseUI](https://github.com/firebase/firebaseui-web), [GeoFire](https://github.com/googlearchive/geofire), [Firebase Queue](https://github.com/FirebaseExtended/firebase-queue), and [FirebaseJobDispatcher](https://developer.android.com/topic/libraries/architecture/workmanager/). These auxiliary bindings add more functionality to your application, including [drop-in authentication with FirebaseUI](https://firebaseopensource.com/projects/firebase/firebaseui-web) and [real-time location queries with GeoFire](https://firebaseopensource.com/projects/firebase/geofire-android/).

Additionally, Firebase allows for integration with [Elasticsearch](https://www.elastic.co/what-is/elasticsearch) and the import of big JSON data collections. You can find out more about implementation in the official [Firebase docs](https://firebase.google.com/docs/guides).

### ZITADEL Integrations

ZITADEL is younger than Firebase and provides gRPC, gRPC-web, and Rest APIs, which are supported by most common programming languages, including Angular, React, [Flutter](https://flutter.dev/), [Next.js](https://nextjs.org/), Java, Python, Go, .NET, and [Dart](https://dart.dev/). In addition, you can opt for either the cloud SaaS version or [self-host](/docs/guides/deploy/overview) it using the [open-sourced repo](http://github.com/zitadel/zitadel). To see a few different ways integrations can be used, check out [ZITADEL's official docs](/docs/sdk-examples/introduction).

ZITADEL provides ample APIs and SDKs to help you integrate with most programming languages. You can also easily integrate your apps with open standards such as OpenID Connect, OAuth 2.0, SAML, etc., when using ZITADEL.

Both ZITADEL and Firebase integrate with a wide range of programming languages, which gives you the ability to work with whatever language or framework you're most comfortable with.

### Firebase Use Cases

As previously stated, Firebase is a full-featured BaaS platform, offering all the capabilities required to swiftly create complex, collaborative apps that can support millions of users. The architecture of Firebase is designed to work in any of the following situations:

* **Firebase-powered application:** Firebase sits in between your application and your client. All you need to worry about is the client side of the application, while Firebase handles the complex backend structure. Resource sharing and storage are both handled by Firebase.
* **Firebase-powered application with server-side:** Firebase is positioned between the server and clients in this architecture. In other words, your server interacts with Firebase to send and receive resources from clients. You can decide who has full access to the data and how it should be handled using your security settings and Firebase rules. Then your server code keeps an eye out for any data changes made by clients and reacts as needed. Even though you're still running a server, Firebase is handling all the heavy lifting of scale and real-time updates.
* **Firebase-powered functionality in an existing application:** In this architecture, Firebase can be integrated alongside your existing server. Your clients will establish connections to both your server and Firebase, using Firebase to power your real-time features while keeping the rest of your application running smoothly.

Using any of these capabilities, you can add a real-time notification system for your users, integrate a chat feature into your website, produce a real-time comment feed, and more. An easy way to start using Firebase is to test out some of its minor functionalities.

### ZITADEL Use Cases

ZITADEL offers you much more control over how your IAM system is deployed. You can use ZITADEL in any of the following use-cases:

* **Out-of-the-box integration with your apps:** ZITADEL can offer you a central login experience that can handle all your users in one place. When a user requests to authenticate, you send them over to the central login widget of ZITADEL to retrieve their details once they're successfully authenticated.
* **Multi-tenancy support:** When building business-to-business (B2B) apps, you need to enable your customers to have control over their authentication flow. They should be able to choose and customize things like branding, federation, and policies. This is often not possible with providers like Firebase Auth because it was originally intended for business-to-consumer (B2C) apps. ZITADEL enables you to support your B2B customers and provide their users with the best experience possible.
* **Self-service experience:** As mentioned above, B2B customers need control over their branding and access rules, and it's not scalable for you to approve or moderate changes. ZITADEL offers you a complete self-service platform that your customers can use to easily self-manage their projects in your apps.
* **Using existing identities:** Many B2B customers want to rely on established third-party identity providers or their own company logins instead of going down the generic email-password route. Federated login flows only partly solve this problem because they don't allow you to choose *any* third-party provider, and reusing a company login is an even more complex task. ZITADEL works best in this case since you can allow your customers to use common protocols like OIDC and SAML to register any recognized identity provider with the IAM solution and manage it on a centralized platform.

Internally, ZITADEL is composed of [two principal architectural styles](https://zitadel.com/docs/concepts/architecture/software): command and query responsibility segregation (CQRS), and event sourcing (ES). Combining ES and CQRS improves ZITADEL's consistency and offers numerous advantages.

Due to the nature of Event Sourcing, ZITADEL has the singular ability to create a robust audit record of everything that occurs on its resources—all while maintaining storage costs and audit trail length.

In summary, if your application needs backend functionality, authentication needs, or real-time data alongside your existing server, Firebase gives you the ability to integrate it with your application at any stage (development or production). Meanwhile, ZITADEL's easy integration into your application helps you handle the authentication, authorization, and self-service parts of your application. If you're looking for a platform that will manage your user identity and provide you complete control over it, ZITADEL is the superior choice.

## Conclusion

In this article, you learned about the key differences between Firebase Authentication and [ZITADEL](https://zitadel.com/). You saw how they compared to each other and how you can integrate them into your project, their architectural choices, as well as the different features they offer.

Firebase in general provides you with backend functions that you can use while building your application's frontend or when scaling your applications. In contrast, ZITADEL gives you flexibility with your programming language and unlimited authentication options.

[ZITADEL](https://zitadel.com/) is an open source identity management platform that provides you with a wide range of features like OpenID Connect, SAML 2.0, OAuth 2, FIDO2, OTP, and an unlimited audit trail. With ZITADEL, you can solve all your authentication and authorization needs. Check out the ZITADEL repo and give us a [GitHub star](https://github.com/zitadel/zitadel). We appreciate the feedback.


*This article was contributed by [Aransiola Ayodele](https://portal.draft.dev/writers/rec2hTGbxNzwgQITY).*


The purpose of this article is to guide readers on what are the differences between ZITADEL and Firebase

Comparing ZITADEL to Firebase


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

Blog.