Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

Read the blog

Sign up

Login

Pricing

Jobs

Blog


## Introduction

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

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

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

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

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

## A Practical Use Case

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

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

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

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

## How to Configure Flat Role Claims in ZITADEL

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

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

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

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

- Internal Authentication
- External Authentication
- Complement Token

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

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

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

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

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

``` JavaScript

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

```


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

## Closing Remarks

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

Thanks for reading!

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


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

Configuring Custom Claims in ZITADEL

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

API Access and Token Introspection with OpenId Connect in ZITADEL


## New Features

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

### Dynamic Issuer

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

### Token Exchange (RFC 8693)

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

### Device Authorization (RFC 8628)

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

## Test Coverage

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

## Refactoring

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

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

## The Future

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

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

## Conclusion

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


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

OIDC Version 2.0 Release


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

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

## What is social engineering?

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

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

## 6 Common types of social engineering attacks

### 1. Phishing and Whaling

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

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

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

### 2. Baiting

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

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

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

### 3. Pretexting

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

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

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

### 4. Honey Trap

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

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

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

### 5. Tailgating and Piggybacking

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

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

### 6. Quid pro Quo

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

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

## How to prevent social engineering attacks

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

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

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

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

### Limit the information you share on social media

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

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

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

### Do not give away your login credentials!

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

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

## The Takeaway

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

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



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

Social Engineering - How Hackers are Manipulating You

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

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



## 1. Introduction

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

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

### 2.1 OAuth2

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

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


_Dear Authorization Server,_ 

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

_Thanks,_

_Client App X_

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

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

#### 2.1.2 Deprecated Grant Types 

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

#### 2.1.3 Other Grant Types 

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

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

### 2.2 OpenID Connect (OIDC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 3.2 Choosing an Authentication Flow for an Application 

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


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

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


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

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

**API:**

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

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


**Service Users:**

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

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

## 4. Wrap Up

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

















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

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


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

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

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

## The most common 2FA Bypass Attacks

### 1. Password reset

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

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

### 2. Social Engineering

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

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

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

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

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

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

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

### 4. OAuth Consent phishing

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

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

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

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

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

### 5. Duplicate-Generator

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

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

### 6. SIM-Jacking

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

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

## How you can protect your account

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

## Be Careful With OTPs

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

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

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

## Switch to Passkeys

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

## Evaluate Consent Requests

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

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

## Never share your Authentication Code!

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

## In Conclusion

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


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

How Attackers Bypass Two-factor Authentication (2FA)


## Key outcomes

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


## Introduction

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

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

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

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

## Problem

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

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

## Solution

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

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

## Centralized Identity and Access Management for Alphalerts

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

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

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

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

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

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

## Single Sign-On for Internal Applications

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

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

## Future Plans

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

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

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

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

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

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

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

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

## Testimonials

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

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

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

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

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

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

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

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

## 1. Configurable Social/Enterprise Login Templates

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

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

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

Our new identity providers include:

* Google
* Github
* Gitlab
* and Azure AD

## 2﻿. Fully customizable Login UI

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

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

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

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

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

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

## 4. Client Credentials as JWT & PAT Alternative

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

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

## 5. Device Authorization Grant

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

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

## 6. More ZITADEL Cloud Data Regions

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

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

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

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

## 7. Improved Developer Experience

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

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

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

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

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

## 8. More Trust

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

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

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

8 Exciting New Features Coming to ZITADEL in 2023


A single-page application (SPA) is an approach to website implementation that aims to provide a better and faster user experience without necessarily hitting the server every time a user interacts with the site. The SPA pattern is a popular approach to designing websites and web apps, with many prominent sites—including [Airbnb](https://www.airbnb.com), Facebook, Gmail, [Jira](https://www.atlassian.com/software/jira), [LinkedIn](https://www.linkedin.com/), and [Netflix](https://www.netflix.com/)—utilizing it.

Security issues are not unique to SPA websites, but this type of solution poses several security drawbacks that aren't present in typical server side websites—that is, a website that loads new pages when you click a link. This is due to the architectural pattern of SPAs, where they sometimes use access tokens to incorporate secure API endpoints in an insecure environment known as the browser. This exposes the site to some [security issues](https://appcheck-ng.com/single-page-applications), such as ​​cross-site scripting (XSS) attacks, cross-site request forgery (CSRF), and session tracking and authentication.

In this article, you'll learn about single-page applications, some security issues associated with the approach, and how to improve the security of any SPA site using [Cloudflare Workers](https://workers.cloudflare.com/) and [ZITADEL](https://zitadel.com/).

## Security Concerns

Let's look at some of the specific security concerns that hackers might exploit in a site that uses the SPA approach.

### Cross-Site Scripting Attacks

![Cross-site scripting (XSS) attacks](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-01.png)

Cross-site scripting, or XSS for short, is a web security vulnerability where hackers inject malicious client-side scripts into the application (in this case the SPA). Using this technique, hackers can steal an access token that was kept in the browser storage. The extracted access token can then be used by the attacker to access resources through the API endpoints. As long as the access token is valid the malicious actor will be able to access any resources that the original user of the token had permissions for.

Additionally, when content security policy (CSP) settings are not properly set, hackers can use the stolen token on an external system.

### Cross-Site Request Forgery

![Cross-site request forgery (CSRF)](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-02.png)

Cross-site request forgery (CSRF) is also known as a one-click attack or session riding and is occasionally abbreviated XSRF. Regardless of what it's called, it's an online security vulnerability where a user is deceived into doing an unwanted activity on a site that they are logged in.

For instance, a hacker may send a user an email that asks them to change their password and provides them with a malicious link through which to do so. The link contains a hidden trigger, such as a hidden form request. When the user follows the link and changes their password, the hidden form request is made along with the submitted password.

As a result, the hacker might be able to access the application API endpoints using the stolen password or other sensitive information. If the compromised user has a privileged position inside the application, the hacker may ultimately gain control of all the data and functionality of the application.

### Session Tracking and Authentication

A single-page application is made up of two primary parts, the frontend systems and API endpoint (backend) systems:

- The frontend systems can consist of websites built with HTML, CSS, and JavaScript, as well as assets that load on the browser, such as photos and JavaScript libraries.
- The backend systems are made up of one or more API endpoints that handle business logic and data processing.

Similar to the conventional multipage approach, an SPA must be secure; however, to achieve an optimal level of security, the web server employs session cookies—a server-specific cookie to proxy the API endpoints. Although session cookies are also vulnerable to cyberattacks, when configured correctly, they can be more secure and offer fewer security risks. Let's take a look at a few additional security measures that can further secure your SPA.

## SPA Security Tips

Following are some tips for improving your SPA security:

### Don't Store Tokens in the Browser

As discussed in the previous sections of this article, SPAs operate primarily in an unverified environment. Storing sensitive information, such as the token from an SSO provider like ZITADEL, can have serious security implications. It is highly recommended that you only use cookie-based sessions.

Although cookie-based sessions can't offer your SPA hundred-percent security from attackers, they're a much better practice than browser storage. Additionally, some attributes may be added to your cookie-based sessions to ensure that your SPA has sufficient security.

One attribute is secure HTTP (HTTPS). If this attribute is enabled, it blocks scripts from non-HTTPS sources (*ie* those that are not secure) from accessing the backend server, even if they have access to the cookie.

The SameSite attribute gives the browser instructions on how to manage cookies. This attribute has three different options, with each option having distinct behaviors:

- **Lax:** This is the default SameSite option if the SameSite attribute isn't set. This option only grants access to the backend server if the domain in the URL bar is the same as the cookie domain (first-party only).
- **Strict:** This option only grants access to the backend server if the domain in the URL bar is the same as the cookie domain and the request isn't coming from an external (third-party) site.
- **None:** This option grants access to the backend server from any domain, regardless of the source (third-party or first-party site).

Properly configuring the CORS headers in your SPA may also help shield against unwanted attacks, especially CSRF attacks.

### Rely on Cookies from a Proxy Instead of Storing SSO Tokens

Instead of storing sensitive information in the browser storage, a better and securer option is to utilize cookies from a proxy, such as Cloudflare Workers.

A proxy, in this context, is a server application that acts as an intermediary between the backend servers and the frontend server:

![Backend for frontend (BFF) approach](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-03.png)

This technique of utilizing cookies from a proxy rather than directly from the token is referred to as the backend for frontend (BFF) approach. In this method, the frontend receives a secure cookie from the token handler (proxy module), and the token is completely concealed from the browser, making it impossible for an attacker to access it. Additionally, the security of the SPA is strengthened, and any security issue that may occur will be from the backend server (API endpoints).

An example of a proxy module is Cloudflare Workers, and you can leverage Curity's [Cloudflare Workers OAuth Proxy Module](https://curity.io/resources/learn/cloudflare-oauth-proxy-module/) to integrate Cloudflare Workers into your SPA.

## How to Secure an SPA Using React and ZITADEL.

In this section, you'll walk through how to set up a secured SPA using [React](https://reactjs.org/) and ZITADEL.

### Prerequisites

You'll need a few things to follow along with this tutorial:

- [ZITADEL](https://zitadel.com/) account.
- [Cloudflare Workers](https://workers.cloudflare.com/) account and Cloudflare subdomain.
- [npm](https://www.npmjs.com/) or [Yarn](https://yarnpkg.com/) installed in your environment.

### Create a React SPA

Run `npx create-react-app <NAME-OF-REACT-APP>` to initialize a new React application. However, you can use an existing React application if you have one.

You also need to install an [OAuth](https://oauth.net/)/[OpenID Connect](https://openid.net/connect/) client to connect your react SPA with ZITADEL. Run the command `npm install oidc-react` to install the client library.

### Set Up Your Cloudflare Workers

The first thing to do in this step is to install Wrangler, which is a CLI for building Cloudflare Workers. Wrangler enables you to initialize, develop, and publish your Workers projects.

Use either of the following commands to install Wrangler:

* If you're using npm, use the command `npm install -g wrangler`.
* If you're using Yarn, use the command `yarn global add wrangler`.

> **Please note:** Wrangler requires Node.js v16.13.0 or higher.

The next step is to authenticate Wrangler.

Run `wrangler login`, and your browser will launch. You'll be routed to a screen requesting that you log into the Cloudflare dashboard. After you log in, Wrangler will ask whether it has permission to modify your Cloudflare account. Scroll down and click **Allow** to proceed.

Change the directory (`cd`) to your react app directory, and use the following command to start a new Wrangler project:

```
`wrangler init <YOUR_WORKER>`; 
```

The value of `<YOUR_WORKER>` can be any name you decide.

In your terminal, you'll be asked the following questions:

* "Would you like to use git to manage this Worker? (y/n)": Indicate `y`.
* "No package.json found. Would you like to create one? (y/n)": Indicate `y`.
* "Would you like to use TypeScript? (y/n)": Indicate `n` to continue with JavaScript.
* "Would you like to create a Worker at demo_one/src/index.js?": Select **None**.

![Wrangler initialization process](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-04.png)

### Create a ZITADEL Application and Set Up SSO

Log into your [ZITADEL Cloud account](https://zitadel.com/signin) and click **New** at the top right to create a new instance. You can select either a free instance or a premium (pay-as-you-go) instance for this tutorial.

Follow the prompts to create the instance and log into the instance once it has been created. It will look like the following screenshot:

![ZITADEL instance](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-05.png)

Click the domain link to access the console:

![ZITADEL console](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-06.png)

Click the **Create Project** button and insert your project name.

Once the project has been created, click the **+** button to create an application.

Fill in the application details as required by the form wizard:

1. Insert your application name and select the **User Agent** option:

![Create a ZITADEL application: **Name and Type**](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-07.png)

2. Select the **PKCE** option:

![Create a ZITADEL application: **Authentication Method**—Select PKCE](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-08.png)

3. Insert your SPA dashboard URL (such as `http://localhost:3000/dashboard`) in the **Redirect URIs** section and set the **Post Logout URIs** to `http://localhost:3000`:

![Create a ZITADEL application: **Redirect URIs**](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-09.png)

> **Please note:** You'll need to enable development mode in your project's **Redirect Settings** for these URLs to work.

4. Review your selections and click the **Create** button at the bottom right:

![Create a ZITADEL application: **Overview**](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-10.png)

### Configure SPA with ZITADEL Authentication

Go back to your SPA and create a new file with the name of your choice. Import the `AuthProvider` component from the installed `oidc` package to the new file:

```
`import { AuthProvider } from "oidc-react";`
```

Create a constant variable containing an object with the required parameters:

```
const oidcConfig = {
    onSignIn: async (response: any) => {
      alert(
        "You logged in :" +
          response.profile.given_name +
          " " +
          response.profile.family_name
      );
      window.location.hash = "";
    },
    authority: "https:/[your-domain]-[random-string].zitadel.cloud", // replace with your instance
    clientId: "YOUR-CLIENT-ID",
    responseType: "code",
    redirectUri: "YOUR-REDIRECT-URL",
    scope: "openid profile email",
  };
```

`YOUR-CLIENT-ID` should be replaced with the generated client ID of your ZITADEL application. To locate this, navigate to the **Project** tab of your ZITADEL console and select **Configuration**:

![Client ID](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-11.png)

`YOUR-REDIRECT-URL` should be replaced with the redirect URL you specified when creating the application. If you need to be reminded, you can select **Redirect Settings** on the project tab to see your redirect URL.

Wrap the authenticated components/sections in the `AuthProvider` component and pass the constant variable as a prop using the JSX Spread operator:

```
function Dashboard() {
  return (
    <AuthProvider {...oidcConfig}>
      <div className="App">
        <header className="App-header">
          <p>Welcome Back</p>
        </header>
      </div>
    </AuthProvider>
  );
}

export default Dashboard;
     
```

Install [React Router](https://reactrouter.com/) into your React application by running `npm i react-router-dom@latest`, and then set up the router in the `App.js` file by importing the `react-router-dom` components with the command `import { BrowserRouter, Routes, Route } from "react-router-dom";`.

Import the dashboard, home, and other created components into the `App.js` file:

```
import Dashboard from 'path/to/file/Auth'
import Home from "path/to/file/Home";
```

Use the imported components:

```
function App() {
  return (
    <BrowserRouter>
      <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/dashboard" element={<Dashboard />} />
      </Routes>
    </BrowserRouter>
  );
}

export default App;
```

### Publish Your Application Using Workers

Change the directory (`cd`) into your React application and create a file called `wrangler.toml` with the following contents:

```
name = "<NAME-OF-REACT-APP>"
account_id = '<YOUR_CLOUDFLARE_ACCOUNT_ID>'
usage_model = 'bundled'
compatibility_date = "2022-09-19"
workers_dev = true
main = "<FOLDER-NAME-OF-THE-WORKER-SITE>/index.js"
[site]
bucket = 'build'
```

To get your `<YOUR_CLOUDFLARE_ACCOUNT_ID>`, log into your Cloudflare Workers account, click on **Workers** on the sidebar, and copy your **Account ID** from the right side of the page:

![Cloudflare Workers **Account ID**](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-12.png)

Change the directory into `<FOLDER-NAME-OF-THE-WORKER-SITE>` and create a file named `index.js`; then paste in the following code snippet:

```
import { getAssetFromKV, mapRequestToAsset} from "@cloudflare/kv-asset-handler";

/**
 * The DEBUG flag will do two things that help during development:
 * 1. we will skip caching on the edge, which makes it easier to
 *    debug.
 * 2. we will return an error message on exception in your Response rather
 *    than the default 404.html page.
 */

const DEBUG = false;

addEventListener("fetch", (event) => {

  try {
    event.respondWith(handleEvent(event));
  } catch (e) {
    if (DEBUG) {
      return event.respondWith(
        new Response(e.message || e.toString(), {
          status: 500,
        })
      );
    }
    event.respondWith(new Response("Internal Error", { status: 500 }));
  }
});

async function handleEvent(event) {
  const url = new URL(event.request.url);
  let options = {};
  /**
   * You can add custom logic to how we fetch your assets
   * by configuring the function `mapRequestToAsset`
   */
  options.mapRequestToAsset = (req) => {
    // First let's apply the default handler, which we imported from
    // '@cloudflare/kv-asset-handler' at the top of the file. We do
    // this because the default handler already has logic to detect
    // paths that should map to HTML files, for which it appends
    // `/index.html` to the path.
    req = mapRequestToAsset(req);
    // Now we can detect if the default handler decided to map to
    // index.html in some specific directory.
    if (req.url.endsWith("/index.html")) {
      // Indeed. Let's change it to instead map to the root `/index.html`.
      // This avoids the need to do a redundant lookup that we know will
      // fail.
      return new Request(`${new URL(req.url).origin}/index.html`, req);
    } else {
      // The default handler decided this is not an HTML page. It's probably
      // an image, CSS, or JS file. Leave it as-is.
      return req;
    }
  };
  try {
    if (DEBUG) {
      // customize caching
      options.cacheControl = {
        bypassCache: true,
      };
    }
    return await getAssetFromKV(event, options);
  } catch (e) {
    // Fall back to serving `/index.html` on errors.
    return getAssetFromKV(event, {
      mapRequestToAsset: (req) =>
        new Request(`${new URL(req.url).origin}/index.html`, req),
    });
  }
}

```

The previous code snippet is required for an SPA made with React, [Vue.js](https://vuejs.org/), or [Angular](https://angular.io/). It monitors the Cloudflare Workers for any incoming requests and serves the corresponding asset from Workers KV.

Change the directory back into the root of the React app and run the command `npm install @cloudflare/kv-asset-handler`.

Build your application by running the `npm run build` command, and then publish your application to Cloudflare Workers by running `wrangler publish`:

![Wrangler publish](/blog/2023-01-26-increase-spa-security-with-cloudflare-workers-13.png)

To access the application, open your browser and go to `https://<workers-name>.<cloudflare-subdomain>/`, where `<workers-name>` is the `<NAME-OF-REACT-APP>` and `<cloudflare-workers-subdomain>` is your Cloudflare Workers subdomain.

You can see all the code used in this tutorial in [this GitHub repo](https://github.com/Olaogunjames/cloudflare-workers-react).

## Conclusion

This article provided a basic overview of single-page applications as well as the security issues associated with SPAs. You've also seen how you can set up a secured SPA using React and [ZITADEL](https://zitadel.com/). With ZITADEL, you can seamlessly scaffold your application access-control level (ACL) and assign roles to your users using ZITADEL's role-based access control (RBAC).

[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 our repo and give us a [GitHub star](https://github.com/zitadel/zitadel). We appreciate the feedback.

*This article was contributed by [James Olaogun](https://portal.draft.dev/writers/rec8roCYYfi889uRl).*


In this article, you'll learn about single-page applications, some security issues associated with the approach, and how to improve the security of any SPA site using Cloudflare Workers.

Increase Your SPA Security with Cloudflare Workers


Role-based access control (RBAC) is a method for restricting system access by assigning users roles that grant one or more permissions. Each permission unlocks a specific function within the system.

RBAC is popular because it results in granular but scalable authorization structures. You can reliably assign each user the bare minimum set of functionality that their position requires. This avoids [the security threats](/blog/why-zero-trust-is-important) of over-privileged user accounts.

In this article, you'll learn how RBAC works, what security use cases it enables, and how you can implement it to effectively authorize your users.

## What Is RBAC?

The following three main entities are involved in RBAC:

- **Permissions** map to functions in your system. They're discrete tasks, such as raise invoice, issue quote, and ship order.
- **Role** groups one or more permissions. You could have a sales role with just the issue quote permission, a cashier role with raise invoice and ship order, and an administrator role that includes all three permissions. Roles allow commonly combined permissions to be assigned collectively, and they're a bridge between your organization's structure and the system's functions.
- **Subjects** are assigned one or more roles. They're able to use the functions referenced by the permissions in each role. Subjects can be human users or service accounts, such as API keys.

These fundamental concepts provide a powerful set of benefits:

### Define User Access by Feature

Users can be assigned the specific features they require instead of all-or-nothing access to the entire application. This reduces risk by preventing users from encountering features they have no reason to interact with.

### Limit Internal Access Threats

Many security threats [come from within](https://www.cisa.gov/defining-insider-threats) organizations. Phishing campaigns, lost credentials, and disgruntled employees can all result in privileged user accounts being weaponized and used against you. Restricting accounts to specific features helps to limit the extent of these threats.

### Create an Audit Trail

Good [RBAC systems](/) create extensive audit trails. You can log when roles were created, which users were assigned to them, and who failed an authorization challenge while accessing an off-limits resource. This increases visibility into security operations and can be a vital compliance tool.

### Manage Authorization at Scale

Even the largest organizations are able to maintain RBAC-based security at scale. Admins can centrally define roles and then reuse them across hundreds of users, groups, and departments. This promotes automation, too: you could script your RBAC provider's APIs to clean up redundant roles, identify users who aren't using assigned permissions, and detect abnormal authorization patterns.

## Managing Authorizations with RBAC

Real-world RBAC implementations usually go beyond simple permissions, roles, and users. The most powerful platforms provide tools for achieving [fine-grained authorization](/blog/zitadel-vs-keycloak) that's robust, scalable, and versatile. Here's how to use RBAC to manage authorizations at the enterprise scale:

### Create Precise Roles

Roles and permissions are additive. If a user is assigned two roles, they inherit the permissions from both of them. This characteristic means it's beneficial to use multiple smaller roles instead of one larger one.

The [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege) states users should receive the bare minimum set of roles that support their responsibilities. In the previous cashier and sales examples, cashiers don't need to issue quotes, as that task's handled independently by sales. However, cashiers will need to retrieve an existing quote before they can raise an invoice.

Using a single role that can interact with quotes would prevent you from enforcing constraints. By splitting the role into individual actions (issue quote and retrieve quote), you can accurately model your organization's structure within the authorization system. Cashiers get assigned one role, while sales staff are granted both. The additive nature of roles means the sales employees receive the entire set of quote-related permissions.

#### Defining Roles with ZITADEL

[ZITADEL](/) is an open source identity management platform. It's available as a software-as-a-service (SaaS) cloud solution and a self-hosted option, which you can deploy on your own servers.

ZITADEL groups users and projects into [organizations](/docs/guides/manage/console/organizations). [Projects](/docs/guides/manage/console/projects) represent a collection of related services that users in your organization authenticate to, such as a web app and its accompanying API. Resources in different organizations are separated from each other, but you can delegate access to other organizations by [creating an explicit grant](/docs/concepts/structure/granted_projects).

After you've created an organization and project, you can define your roles by heading to the **Roles** page from the **Projects** details screen. Click the blue **New** button to create a role:

![Screenshot of creating a role in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-01.png)

Use the next screen to enter the data about your role. The **Key** is the role's unique identifier to reference in your application. The **Display Name** is what you'll see in the ZITADEL console when you're allocating the role to users:

![Screenshot of defining a role in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-02.png)

Click the **Save** button to add the role to your ZITADEL project. It will appear in your project's list of roles:

![Screenshot showing roles defined in a ZITADEL project](/blog/2023-01-12-authorization-with-role-based-access-control-03.png)

Next, use the sidebar on the left to switch to the **Authorizations** page. This is where you assign your roles to users. Click the **New** button to add authorization for the role you've just created:

![Screenshot of creating an authorization in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-04.png)

You'll be prompted to select the users who'll be granted the role. Use the drop-down to add one or more users to the authorization, then press **Continue**:

![Screenshot of selecting users for authorization in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-05.png)

The next screen will display the roles available in your project. You can assign multiple roles in a single authorization—they'll be applied additively, so all the selected users receive every selected role. Click the blue **Save** button to confirm your authorization:

![Screenshot of adding roles to authorization in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-06.png)

Return to your ZITADEL **Projects** settings and enable the **Assert Roles on Authentication** option on the **General** page:

![Screenshot of enabling the **Assert Roles on Authentication** project setting in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-07.png)

Now you can retrieve the user's authorizations in your application by calling the [OIDC `userinfo` API endpoint](/docs/apis/openidoauth/endpoints#userinfo_endpoint):

![Screenshot of using Postman to make an OAuth 2.0 authorization request to ZITADEL and get a user's roles](/blog/2023-01-12-authorization-with-role-based-access-control-08.png)

## Attribute-Based Access Control for Fine-Grained Authorization

Attribute-based access control (ABAC) is an adjacent authorization approach that looks at user attributes instead of roles. Users are annotated with metadata that you can look up in your app. Metadata is simple key-value pairs of characteristics, such as the user's role, the team they work in, and any security clearances they hold.

Attributes are also applied to the resources in your system, such as invoices and quotes. You might tag the user who created the resource, the department it belongs to, and any special attributes that users require before they can interact with it. The authorization platform compares the attributes of the resource and user when a challenge occurs.

ABAC is more powerful than RBAC. ABAC is a fine-grained approach to authorization that supports richer access control conditions. Systems that use ABAC are able to closely model your business rules and processes more.

RBAC falls short when it comes to protecting individual resources. Splitting roles up (such as the previous issue quote and retrieve quote examples) defends against unauthorized actions, but this mechanism alone can't accommodate the role to retrieve quotes relating to the user's department. Implementing this policy requires the authorization platform to know what the user's department is, and ABAC metadata provides this information.

### Using ABAC in ZITADEL

ZITADEL supports ABAC through its [user metadata](/docs/guides/manage/customize/user-metadata) system. You can configure metadata on your users and then retrieve it in your application using the ZITADEL API. Authorization checks can refer to the metadata when evaluating whether a user should be granted access.

To set metadata fields on a user, head to their details screen within the ZITADEL console. Switch to the **Metadata** page using the sidebar on the left. Click the blue **Edit** button to open the editor:

![Screenshot of viewing user metadata in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-09.png)

Use the dialog to define your key-value metadata pairs:

![Screenshot of editing user metadata in ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-10.png)

Your application can [retrieve the metadata](/docs/guides/manage/customize/user-metadata) by including the `urn:zitadel:iam:user:metadata` reserved scope when you request authorization. The [`userinfo` API](/docs/apis/openidoauth/endpoints#userinfo_endpoint) will include the metadata object when you send an ID token that's been generated with this scope. The metadata values are encoded as Base64:

![Screenshot of making a Postman request to get a user's metadata from ZITADEL](/blog/2023-01-12-authorization-with-role-based-access-control-11.png)

## The Future of RBAC and ABAC

RBAC, ABAC, and the broader concept of fine-grained authorization have become standard ways to manage access control at scale. These approaches still form the foundations of advanced patterns for implementing globally consistent distributed authorization, of which [Google Zanzibar](https://zanzibar.academy) is a prominent example.

Zanzibar goes beyond permissions, roles, and subjects to support namespaced configurations, per-resource authorization checks, concentric relationships, and nested resource hierarchies. This creates a graph-like structure [that's traversed to check](https://www.osohq.com/post/zanzibar) whether users can perform an action against an object within a particular context. Contexts could be a web app, API, or an external link to a file shared from another organization.

## RBAC, Audits, and Automation

One of RBAC's advantages is the ease with which you can audit your authorization policies and apply any changes you require. For example, you might find that a role unintentionally includes extra permission. There's a risk that users will perform an action that's supposed to be forbidden. To fix the situation, you can simply remove the permission from the role. This immediately prevents users from continuing to carry out the action.

Authorization platforms like ZITADEL provide a comprehensive [audit trail](/features#audit) that lets you step back in time. You can use this data to address any doubts about a user's past activity. Role assignations, revocations, login attempts, and metadata changes will all be recorded, creating a historical record of changes to your authorization structure.

RBAC is also easy to automate, which aids integration with your existing systems. You can use APIs to bulk update roles, [validate access tokens](/docs/apis/openidoauth/endpoints#introspection_endpoint), query for users who can perform an action, and revoke access after your tools detect a compromised account. This makes it easier to set up and maintain large-scale authorization structures without depending on repetitive manual actions.

## Conclusion

Role-based access control is an approach to fine-grained authorization that helps reduce the risks of over-privileged accounts. It is scalable to large teams, creates an audit trail that helps with compliance, and is capable of advanced policy-based authorization decisions when you set attributes on your users and objects.

You can quickly add RBAC to your own system using [ZITADEL's open source identity management platform](/). Users sign in to your app with their OpenID Connect, OAuth 2, or FIDO2 provider. You can [retrieve the user's roles](/docs/guides/manage/console/roles) by calling the ZITADEL API or choosing to include role data in access tokens. ZITADEL solves all your authentication and 


*This article was contributed by [James Walker](https://portal.draft.dev/writers/recdueDghXBkpM6Qj).*


In this article, you'll learn how RBAC works, what security use cases it enables, and how you can implement it to effectively authorize your users.

How to Manage Authorizations with Role-Based Access Control

Whether it be an online store, a news site, or even this very page – the browser you use to access websites contains more information about you than you might realize. Astonishingly, this **data stored in browsers can be used to uniquely identify site visitors** and to track their online activity. This technique, also known as **Browser Fingerprinting**, is frequently used to **reduce fraud and suspicious website traffic**.

Although fingerprinting is a remarkably accurate method of identifying unique browsers, it has attracted some criticism regarding its **seemingly invasive nature**. This prominent divide on the topic might leave some people wondering if browser fingerprinting is indeed a cause for concern. This article aims to put this debate to rest by analyzing the unique **purpose, functionality, and legality of fingerprinting** and how its use could benefit the public.

![Illustration of Browser Fingerprinting](/blog/2022-12-05-fingerprinting-01.gif "Browser Fingerprinting ")

## 1. What is Browser Fingerprinting?

Although they have the same name, "fingerprint" has a slightly different meaning in an online setting than in the real world: Whereas both meanings allude to an effective medium used to identify a person, a digital fingerprint accomplishes so by **analyzing respective browser signals**. While solely relying on browser information to identify users might sound vague at first, realistically, the **chance for another user to have completely matching configurations is near impossible**: Thus, they can effectively serve as user IDs. 

Due to their high accuracy as user identifiers, **browser fingerprinting technologies have become a pillar for developer-led fraud protection** that cuts through spoofing efforts. Their use significantly facilitates the efforts of developers in **triaging suspicious traffic and restricting access to users attempting to hack into accounts** to spam or make fraudulent purchases. Additionally, the accuracy of browser fingerprinting can be further increased when it is combined with usage history, fuzzy matching, and probability engines.

## 2. How Browser Fingerprinting works

Whether online or in real life, the key to identifying a suspect is to **gather the needed information** that leads to their recognition: While in an analogous setting, detectives would collect clues such as analogous fingerprints, cameras, and testimonials, in the case of browser fingerprinting, the evidence is written all over the **suspicious visitor’s browser configuration**.

But how exactly can some browser parameters lead to exposing a criminal’s real-life identity? To answer this lingering question, it is essential to clarify **what signals the services generally capture**.

### Which parameters are captured?

The creation of a browser fingerprint relies typically on the following parameters:

* Hardware details (screen resolution, battery usage, device memory)
* User-agent details
* IP Adresses and TSL Sessions
* WebGL parameters
* Browser plugins and extensions used
* The browser and OS settings (f.e. language)
* Keyboard Layout
* Whether cookies are enabled

As a rule, the digital fingerprinting function **automatically gathers these details when a visitor first lands on a webpage**. The captured information is saved in a database that is left untouched unless the data is required to identify a returning visitor who was observed behaving suspiciously or engaging in fraudulent activities. 

### How accurate is fingerprint-based identification?

When the public is looking for a wanted criminal, the **chances of identifying them gradually increase with every single additional information about the person**. Thus, the more details that can be added to the criminal sketch, the clearer the portrait of the perpetrator will be. 

The same principle applies to virtual attackers. Due to the **large number of specific attributes provided by browser fingerprinting, the culprit can be reliably located in a sea of online users** - In fact, a study carried out by [Electronic Frontier Foundation](https://coveryourtracks.eff.org/static/browser-uniqueness.pdf) found that 83.6% of tested browsers were unique. 

This **accuracy of fingerprinting is even higher in the case of device fingerprinting** - a technique that enhances browser fingerprinting with the additional feature of identifying users of a native mobile app. By relying on a **visitor ID**, device fingerprinting can **recognize a returning user [99.5%](https://dev.fingerprint.com/docs/understanding-our-995-accuracy) of the time**.

However, it is worth noting that real-life criminals and digital ones alike generally go out of their way to **conceal as many of their identifiers as possible**: Akin to how a robber might hide behind a face mask and dark clothing, a hacker usually uses incognito mode, browses via a VPN/Proxy  and keeps their cookies disabled. Fortunately, **fingerprinting can associate suspicious visitors without needing discreet identifiers like cookies or IP addresses**; thus, identity-concealing techniques do not pose an obstacle. With a little extra help from **[bot mitigation mechanics](https://fingerprint.com/products/bot-detection/)**, even **sophisticated threats that go undetected by traditional means of detection** can be effectively prevented.

## 3. Is Browser Fingerprinting legal?

Due to the many unique identifiers browser fingerprinting can capture on a whim, **it is only natural to second-guess the morality and legality of this technique**. To quickly answer the latter concern:

**Yes, browser fingerprinting is entirely legal**, since it only captures data deemed to be publicly available and **no personal information is being collected**. That said, each fraud solution that captures data must adhere to all applicable laws, such as local laws and GDPR. 

Regardless of the practice's legality, the seemingly invasive nature of fingerprinting might raise some valid concerns regarding user privacy. While the feeling of being “watched” is an apprehension many of us have, it is worth considering that **such security measures are often the key to identifying suspicious individuals and preventing attacks**. Such protection tools are not exclusive to the digital world either: Nowadays, most stores and institutions handling valuable goods (f.e. banks) are equipped with a security camera. Whereas these cameras come with the expense of surveilling all activity in the building, they simultaneously capture the most solid evidence in case of an intrusion. Of course, no such surveillance would be necessary in an ideal world. Yet, as long as the risk of an attack persists, **we must make the inevitable choice to observe every, including innocent, activity - or none at all**.

## 4. Browser Fingerprinting vs. Cookies

You may have noticed that many websites prompt visitors with a window asking permission to enable 3rd party cookies. This annoying nature of a "reading exercise" in the way of the desired content frequently inclines individuals to apathetically click "accept" to get past the barrier, much like it is commonly done with the terms of service before downloading a program. While this reaction is understandable, it is still helpful to know that **by consenting to cookies, you prompt a unique identifier to be placed on your web browser**. Though they operate similarly, **cookies and browser fingerprinting are not to be used interchangeably**.

### Privacy and Security - The core difference 

Since cookies' core functionality might sound eerily similar to the concept of browser fingerprinting, you might wonder why only the former must specifically ask for the user’s consent. Astonishingly, **while the two techniques serve the same purpose, their methods of acquiring data could not be any more different**. Permission is needed for cookies because, unlike fingerprinting, they track personal data that nearly everyone can access. Thus, **cookies could grant third-parties access to private information about a user**, such as their name, address, and credit card number.

Although they collect unique personal information, cookies still need to catch up in successfully identifying suspicious site visitors. This is mainly due to the fact that, unlike browser fingerprints, **they can easily be concealed with the help of some widely accessible techniques**, such as using an adblocker. Alternatively, **the user can delete them** within their browser’s settings.

In conclusion, while cookies provide numerous advantages, such as enhancing user experience, the alternative of **browser fingerprinting also guarantees these benefits while protecting user privacy and personal data**.

## 5. How Browser Fingerprinting can benefit a Website

Now that we have discussed what browser fingerprinting is and how it works, there is still one crucial question that needs to be answered: **What exactly are the benefits of implementing this technique?** To answer this query, the following paragraphs provide an overview of the many uses of browser fingerprinting. 

### Account Fraud Prevention

One of the most notable benefits of browser fingerprinting is its **ability to prevent account fraud**. In combination with bot detection, this technique not only **detects advanced bots attempting to generate fake profiles but also mitigates account takeover** attempts by halting them at the source: By uniquely identifying visitors to your website, you are given a chance to immediately recognize brute force attacks and lone actors testing acquired credentials.

### Payment Processing

Browser Fingerprinting is especially valuable for e-commerce websites. With its help, you can seamlessly **identify the users behind every transaction**. In addition to recognizing attempts of **card cracking** (testing combinations of card details), you can **eliminate coupon abuse and credit card fraud** on your website. Thus, you can ensure that every purchase made on your website is legitimate.

### More effective Monetization

As the internet is gradually replacing other media sources for content consumption, more and more websites are relying on content **paywalls** as a significant source of income. The mandate for a subscription to read the articles on *The Wall Street Journal'*s website is an example of how **this monetization strategy effectively attaches a price tag to particular pieces of information**. Unfortunately, paywalls are not indestructible: Some experienced hackers have found a way to sneak past the barrier and read the protected material without paying. With the help of reliable visitor identification, **browser fingerprinting assists content providers in more successfully monetizing their platform**. 

## 6. Fingerprinting in practice 

### High-accuracy device identification with Fingerprint

If you are intrigued by Browser and Device Fingerprinting, **we strongly recommend you check out [Fingerprint](https://fingerprint.com/)**. On both the web and mobile, this best-in-class identifier software can reliably prevent fraud, spam, and account takeover with **99.5% accuracy**.

Data stored in browsers can be used to identify site visitors and to track their activity. Browser Fingerprinting can reduce fraud and suspicious website traffic.

Blog.