Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog

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.

Browser Fingerprinting: What Is It and Why Is It Used?


![Recap of 2022 with people raising their glasses in the background](/blog/2022-12-29-best-of-zitadel-2022-00.png)

Another long year is slowly ending and it is almost time to drown our sorrows in champagne and turn a new page in life.
However, before we plunge too deeply into our fresh new year’s resolutions, we are taking a moment to reflect on the milestones we have reached this year and to express our gratitude for the overwhelming support we were given along the way. 

This brief recap showcases the most significant ways ZITADEL has improved in the year 2022. 

## We Raised $2.5 Million!
One of the most significant milestones in ZITADEL's development was the successful closing of our seed funding round led by [Nexus Venture Partners](https://nexusvp.com/).
Ever since the [big announcement](/blog/fundraising-nexus) saw the light in June, this generous grant has played a vital role in helping ZITADEL become the best open-source alternative for identity management needs. 

With this incredible achievement under our belts, we are beyond excited to see what else we can accomplish with our remarkable supporters and valued customers on our side.

## Introducing our next major release of ZITADEL
In August of 2022, ZITADEL underwent its most significant upgrade to date.
The new version introduced a [new selection of features and upgrades](https://github.com/zitadel/zitadel/releases/tag/v2.0.0) that ensure easier use, expanded compatibility, more value for your money and, as always, still the highest possible data security. 

The most significant changes brought on by V2.x include the following: 
- [New Virtual Instances](/blog/introducting-v2-0#:~:text=New%20Virtual%20Instances,by%20the%20platform.)
- Extended database compatibility to [PostgreSQL](/blog/postgresql-support)
- [More Social Logins](/blog/social-logins#:~:text=ZITADEL%20will%20support,for%20all%20users.) and
- [Easier Development](/blog/introducting-v2-0#:~:text=Easier%20to%20Develop,features%20more%20straightforward.)
- The implementation of [SAML 2.0](/blog/saml-support)

While the development team focused on new upgrades and implementations, the UI and UX department was responsible for enhancing ZITADEL's visual appeal and ease of use.
With the help of a reimagined navigation system, content filters, keyboard shortcuts, and [many more new features](https://github.com/zitadel/zitadel/issues/2944), the new console of ZITADEL is now easier to use than ever before.

## Relaunch Of Our Cloud Service
Concurrently with the release of  ZITADEL’s new version, we also relaunched our cloud service. Instead of being limited to single organizations, each of our customers can now set up new instances - an own logically separated setup of ZITADEL - from our customer portal. This also came with features to make ZITADEL Cloud invisible to your users, like using a custom domain for your login page and defining your own SMTP server for emails.

Given all of the improvements ZITADEL undertook this year, it was time for us to revisit our cloud pricing structure as well. We swiftly identified the path the adjustments should take concerning our core philosophy of not placing a premium on security features: 

To allow users to gradually expand the platform based on their organization’s specific needs, we have removed subscription tiers and their respective feature locks altogether.
With these changes implemented, our users are granted a platform that scales along the rest of your infrastructure requirements with [more features](/blog/pricing-updates-v2) to enjoy than ever.

Our pricing also differentiates us in the market and resembles the cost of infrastructure more closely than a per-seat cloud service. We are the best identity management platform for not only consumer identities but also your B2B customers/partners. With that, we wanted to create more reasonable pricing that works for all your identities, and you don’t have to worry about any unpredictable costs.

## New Findings With Pentest
As a team behind the platform handling sensitive data, we firmly believe that a transparent working process is essential for establishing trust in our project and cloud service. Accordingly, we highly prioritize publicizing the findings of our systemic security screenings. 

In November of 2022, we tested ZITADEL against the [OWASP Top Ten risks](https://owasp.org/www-project-top-ten/) and the configuration of our systems with the help of an external party.
With just one significant issue instantly resolved throughout the test, we were glad to find that the platform was assessed as confidential.
If you are interested in a more detailed overview of the results, feel free to [read the full report](/blog/2022-12-01-pentest-results-h2-2022-01.pdf).

As an additional effort to promote transparency, we have decided to reduce the number of sub-processors with access to customer data.
Our updated [Trust Center](/trust) displays a coherent list of every relevant provider and the specific data they have access to.

## Rising Blog Readership

Every week, our [ZITADEL Blog](/blog) is enriched with new stories, news, updates and opinions all about authentication and cybersecurity. While our articles have generally enjoyed an incredible rise in readership this year, three posts must be highlighted for drawing a particularly remarkable number of visitors.

Here are the TOP 3 articles from 2022 that you found most intriguing:

- [#3](/blog/smishing): Smishing - How to Recognize Dangerous Text Messages
- [#2](/blog/jwt-vs-opaque-tokens): JWT vs. Opaque Tokens
- [#1](/blog/magic-links): Magic Links - Are They Actually Outdated?

[![Thumbnail of our blog Are magic links outdated?](/blog/2022-06-22-magic-links-00.png)](/blog/magic-links)

## ZITADEL Beyond The Digital World
As a team working on a platform all about cybersecurity, it likely is not surprising that most of our work is done virtually. This year, however, we were granted some incredible opportunities that helped us expand our horizons and spread the word about ZITADEL beyond the digital world. 

These were the most notable events and conferences we visited in 2022:

- [Swiss Cybersecurity Days](https://swisscybersecuritydays.ch/) (SCSD): The largest cybersecurity convention in Switzerland, featuring world-renowned experts and politicians.
- [Gophercon UK](https://www.gophercon.co.uk/): A conference and workshop dedicated to Go programming information and training
- [Devoxx UK](https://www.devoxx.co.uk/): A conference for developers to learn, sharpen their skills and get hands-on experience with the latest tech
- [Websummit](https://websummit.com/): An event in Lisbon bringing together 70,000+ people to redefine the tech industry
- [Startup Nights](https://startup-nights.ch/): A convention in Winterthur with over 5’000 startups presenting their services and products

![Fabienne, Silvan, Max, and Florian in front of our ZITADEL booth at Websummit](/blog/2022-12-29-best-of-zitadel-2022-01.png)

## And Finally: A Thank You

While we are very proud of how far our authentication solution has come in 2022, it would be disingenuous for our team to take all the credit for this success. Our valued customers, supporters and anyone who takes time out of their day to interact with ZITADEL are all crucial factors in our growth as a startup. 

We are profoundly grateful for your trust in ZITADEL and look forward to seeing what more we can achieve together in the upcoming year and beyond.


This brief recap showcases the most significant ways ZITADEL has improved in the year 2022. We are profoundly grateful for your trust in ZITADEL!

The Best Of ZITADEL 2022

Since a single password only safeguards so much personal information, it is sadly unsurprising that some people take advantage of the flaws in this security technique to **access sensitive data**. While you might already be familiar with some of the most used hacking methods, such as phishing, malware and brute force attacks, researchers have recently shed light on an unexpectedly bizarre new attack alternative: **Thermal Attacks**.

One of the most common method of thermal tracking is called the "**Thermanator**". This somewhat strange name for the hacking method combines the title of the famous cyborg assassin “Terminator” with the prefix “therm” (meaning heat), thus accurately reflecting the attack's strategy: **using user-left heat signatures to exploit keyboards**.

This article discusses the phenomenon of thermal attacks and how we can avoid falling victim to them. 

## W﻿hat are Thermal Attacks?

If you have ever looked into a thermal camera, you might find **traces of human touch remain visible** on an object or surface in the form of fingerprints. This phenomenon also applies to common input devices such as phones and keyboards, which you may use to enter sacred credentials. Unfortunately, hackers are no strangers to this fact. 

While the prints fade after a while, there is always a window of time where **thermal energy measurements from input devices can be collected** to retrieve recently submitted information, which can range from a harmless text message to a password you use to access sensitive data. 

![Thermal Attacks use user-left heat signatures to exploit keyboards](/blog/2022-11-14-thermal-01.gif "How Thermal Attacks work")

I﻿mage Source: [SciencePhotoLibrary](https://www.sciencephoto.com/media/682484/view)

## The Thermanator

This hidden danger of seemingly harmless thermal residues was unveiled within the framework of an experiment carried out by [three scientists from the University of California, Irvine (UCI)](https://arxiv.org/pdf/1806.10189.pdf). The researchers analyzed a distinct type of insider attack they titled “thermanator,” which involves an **attacker exploiting the function of a thermal camera to reveal passwords** that have been entered on a keyboard. Astonishingly, this thermanator-experiment led the researchers to **correctly recall whole sets of key presses as late as 30 seconds** after the initial character was entered, following four simple steps:

> “**STEP 1**: The victim uses a keyboard to enter a genuine password as part of the log-in (or session unlock) procedure. 
>
> **STEP 2**: Shortly after that, the victim either: (1) willingly steps away or (2) gets drawn away from the workplace.
>
> **STEP 3**: Using thermal imaging (e.g., photos taken by a commodity FLIR camera), the adversary harvests thermal residues from the keyboard.
>
> **STEP 4**: Later, the adversary uses the “heat map” of the images to determine recently pressed keys. This can be done manually (i.e., via visual inspection) or automatically (i.e., via specialized software).
>
> **REPEAT**: The adversary can choose to repeat STEPS \[1-4] over multiple sessions.”

## ThermoSecure: The Thermanator gets an Upgrade

While the previously mentioned Thermanator attack already had a high success rate in guessing passwords with the help of thermal residues, it ultimately comes with the **handicap of a time limit**. For the attack to work, the attacker would have to take the picture with the thermal camera just thirty seconds after the first key was entered; accordingly, this practice might prove extremely hard to conduct in an everyday scenario.

However, thermal attacks do not admit defeat just yet. In a newer study for [ACM Transactions on Privacy and Security](https://dl.acm.org/doi/10.1145/3563693), the research team led by Dr. Khamis could astonishingly reveal that the **time limit and the accuracy of the guesses can be further expanded by leveraging deep learning techniques**. According to the team, due to machine learning becoming increasingly accessible, it is more and more likely that attackers will employ it to improve their thermal attacks.

This discovery of the **ThermoSecure** attack was made possible by the researchers' probabilistic training of an artificial intelligence model to efficiently scan the thermal photos and generate educated predictions about the passwords from the heat signature clues. Evidently, the help of an AI has significantly changed the success rate of this hacking method: Not only did **ThermoSecure guess passwords of an average length (8 characters) with 93% accuracy** within 20 seconds after they have been entered, but the attack could even reveal **long passwords of 16 characters with almost 70% accuracy**.

However, the biggest revelation lies in the technique’s capability of accurately revealing passwords, even if the thermal image was taken **over a minute after the keys were pressed**. The success rate of the AI guessing the secret code lies at 62% at the 60-second mark. 

## How to stay safe

As thermal cameras become cheaper and easier to access, the chance of misuse is correspondingly increasing as well. Fortunately, there are some factors that can significantly decrease the success rate of thermal attacks.

### Touch typing over Hunt-and-Peck

Despite using keyboards for the same ultimate purpose, surprisingly, the **technique by which people press the keys** has a significant effect on the quality of thermal imaging data. Generally, typists can be grouped into two main categories:

* **Hunt-and-Peck typists** - Keyboard users who do not rest their fingertips on the home row and usually spend more time looking for the key to press.
* **Fast / Touch typists** – They rest their fingers on (or lightly touch) the home row while typing.

It likely comes as no surprise that the former method, which involves the person only touching the keys included in the password, leaves little room for interpretation. Accordingly, **hunt-and-peck typists are more vulnerable to thermal attacks** than fast typists, with a success rate increase of around 10%.

### PBT keycaps

Even though typing behavior can influence the success rate of thermal attacks, there is another factor at play that is arguably even more relevant: the **interface of the keyboard in use**. While the material of the keycaps usually plays a lesser role in the purchase of a new keyboard for most people, in the context of thermal attacks, it becomes imperative.

Objects created out of a **material with a lower heat conductivity** can retain the thermal trace of human touch for a more extended period. This rule, of course, also applies to keyboards: As an example, **Polybutylene Terephthalate plastic (PBT) keycaps** are known to be significantly **less vulnerable to thermal attacks** than ones made out of Acrylonitrile Butadiene Styrene plastic (ABS) due to the faster fading of its heat traces. 

Regardless of the length of your password, using a PBT keyboard is a reasonably practical protection measure against thermal attacks. However, it is worth noting that higher durability comes with a higher price.

### The ultimate solution – Ditching passwords

While a thermal attack might seem like an unlikely crime to fall victim to, unfortunately, it is but one name on the **long list of cyber-attacks exploiting the simplicity of password-based authentication**.

The main reason behind the increasing vulnerability of passwords is evident: The paradox of it having to be **both complex and easily recallable**. This dilemma of choosing a password often leads people to either select a string of characters that could be hacked in seconds or one that they might forget the next day – a middle ground is increasingly harder to find. 

Fortunately, there are alternate authentication methods that are more effective in protecting you from attacks that prey on your password. One of the most notable examples is **[Multi-Factor Authentication (MFA)](https://zitadel.com/features#multifactor)**. MFA commonly **utilizes a passwordless factor** (such as Fingerprint, Face ID, or physical tokens) **in addition to the regular username-password login** method, providing a secondary layer of security for your data. While each method of MFA is significantly safer than a password alone, in the context of protecting yourself from a thermal attack, an **out-of-band or off device factor** would generally be most effective. Thus, even if an attacker manages to take a picture of your keyboard, they **could still not access your account without the additional authentication factor** sent to the other device.  

Alternatively, you can protect your data by authenticating yourself using a** [passwordless](https://zitadel.com/blog/passwordless) method**. This alternative **completely substitutes passwords with a passwordless factor**, whereas the formerly mentioned MFA operates using a combination of the two. Akin to the case of MFA, it is advised to authenticate yourself via an off device passwordless factor to minimze your chances of falling victim to a thermal attack.

While you might be familiar with common hacking methods, such as phishing and malware, researchers have discovered a bizarre new alternative: Thermal Attacks.

Thermal Attacks - How Heat From Fingertips Can Reveal Passwords


Silent-login and silent-refresh require the use of iFrames, which has to be allowed by ZITADEL.
This brings some disadvantages in terms of security.
You should be aware of the drawbacks and benefits, that is why we provide you with the basis for decision-making here.

### Where are iFrames needed?
There are a few use cases where an iFrame is reasonable and needed, e.g silent-login or silent-refresh.

#### Silent-login and Silent-refresh
Silent-login and -refresh assumes that the user is already logged in and the existing session can be reused.
The existing OpenID session should be reused for a new authentication request without the user noticing anything.
This requires the prompt= none in the authentication request.
To find out more about the possibilities of the request you can use the [OIDC Authentication Request Playground](https://zitadel.com/docs/apis/openidoauth/authrequest?prompt=none).
Silent-login is a general use case, regardless of the app type, whereas silent-refresh is mostly used in SPAs. The authentication request is usually triggered in an iFrame that the user won’t see.


### How does ZITADEL handle it?
To maximise the security during login and in the ZITADEL Console UI, ZITADEL follows security best practices by setting a Content-Security-Policy (CSP) and X-Frame-Options:

```
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: deny
```

These settings block the use of serving it in an iframe to prevent clickjacking attacks.

#### CSP
Content Security Policy (CSP) is a security standard that helps detect and mitigate certain types of attacks, including cross-site scripting (XSS), clickjacking and data injection attacks.

The policy is a string that contains the guidelines that describe your content security policy. The string can include a series of policy directives, each of which describes a certain resource type or area.

Relevant Examples:
```
Content-Security-Policy: default-src 'self'
```
All content should come from the site’s own origin (including subdomains).

```
Content-Security-Policy: default-src 'self' acme.com *.acme.com
```
Content from a trusted domain and its subdomains is allowed.

```
Content-Security-Policy: frame-ancestors ‘none’
```
“Frame ancestors” defines if it is allowed to embed the page. With none it is not allowed to embed the page.

```
Content-Security-Policy: frame-ancestors 'self' https://www.acme.com;
```
“Frame ancestors” defines if it is allowed to embed the page. The own site is allowed as well as https://www.acme.com

#### X-Frame-Options
The X-Frame-Options can be used to define if a browser is allowed to render a page in a ```<frame>```, ```<iframe>```, ```<embed>``` or ```<object>```.

X-Frame-Options:
DENY: It is not allowed to display the page in any frame
SAMEORIGIN: It is allowed if all ancestor frames are the same origin as the page itself.

### Enable iFrame use for your ZITADEL instance
The iFrame option is always enabled on your whole ZITADEL instance. Follow the steps below to apply the option:
Navigate to the instance settings in your ZITADEL Console
Click on the Security Policy tab
Enable the “Allow iFrame” and add the host(s) from which you load the iframe from

This will change the CSP of ZITADEL to the following:

```
Content-Security-Policy: frame-ancestors https://custom-domain.com
```
and remove the X-Frame-Options header.




It's important to secure the myriad of connections between the devices in an IoT network and the services they communicate with. This is where IoT authentication plays its vital role. In this article, you'll learn how authentication in IoT works and how you can achieve device authentication in an IoT system.

How to handle silent-login in ZITADEL?


The term [Internet of Things (IoT)](https://www.oracle.com/internet-of-things/what-is-iot/) refers to a group of things or objects that have sensors and software built into them in order to exchange data with each other over the internet and other networks. Nowadays, with IoT, you can connect almost any electronic object to the internet for seamless communication with other devices and humans. 

The *Things* in the Internet of Things can be anything as simple as a light bulb you can switch on or dim with your smartphone application, or as complex as cabin climate control devices in airplanes. IoT has already become one of the foremost technologies in the past few decades.

Because IoT is becoming an increasingly important aspect of our daily lives, there is growing concern in regard to security and privacy. It's important to secure the myriad of connections between the devices in an IoT network and the services they communicate with. This is where IoT authentication plays its vital role. In this article, you'll learn how authentication in IoT works and how you can achieve device authentication in an IoT system.

## Why You Need IoT

As you will see, IoT is important to individuals and businesses alike. The technology aims to help people live smarter and gain total control over many aspects of their daily lives. As a business, IoT enables you to have real-time insight into your processes and the performance of all your business domains and assets. With the automated and interconnected system that IoT provides, you can easily cut down waste, improve productivity, and preemptively develop strategies to address challenges before they even occur.

IoT is used by organizations across several industries to improve operational efficiency and derive more value from their decisions. In a typical IoT ecosystem, devices will have embedded sensors, processors, and other technologies that enable them to share and act on data acquired from their environment. 

Although [IoT, as an idea, has been in existence for a few decades](http://www.chetansharma.com/correcting-the-iot-history/), the technology was brought to life through the successes attained in the development and advancement of several technologies. Some of these are as follows:

* Access to affordable and low-power electronic sensors
* More efficient data transfer over a host of internet network protocols for cloud connection
* Advances in machine learning (ML) and data analytics to gather insights faster from real-time sensor data
* Breakthroughs in artificial intelligence (AI) that have made IoT devices more appealing to everyday users, with digital assistants, like Siri, Alexa, Google, and Cortana.

These technologies and many more facilitated the growth of IoT.

### Use Cases of IoT

There are many aspects of life—private or public—where the Internet of Things can be used. Following are some of these use cases:

#### Location Tracking

Location tracking is one of the most popular use cases of IoT where smart sensors that are capable of monitoring GPS location, detecting surrounding devices, and transmitting data over a network are incorporated into devices in several industries.

[Wearable technologies](https://en.wikipedia.org/wiki/Wearable_technology) have made it easy to track the location of humans, pets, and mobile equipment. This application of IoT has aided parents in tracking their children, farmers in tracking the location of their herds, healthcare companies in tracking the real-time location of their patients with electronic implants or patient-assistance tools, and industries in tracking products throughout their lifecycle, from the assembly line to retailers' shelves.

#### Fleet Management

IoT sensors installed on vehicles within a fleet help to manage the complexities associated with fleet management. Smart sensors connect to IoT networks that then collect fleet data for performance analysis, pollution reduction, geolocation, fuel savings, and telemetry. 

For example, key metrics such as total vehicle load, temperature of sensitive cargo, and fuel tank level can be monitored with IoT sensors and then transmitted for further processing. IoT enables the interconnectivity of vehicles, drivers, and fleet managers in real time, making it easier to improve operational efficiency.

In practice, a fleet manager can easily reroute trucks passing through a certain route with bad weather. Thanks to IoT, the trucks are equipped with sensors that can communicate over the internet.

#### Smart Farming

The increasing global population has called for constant innovations that assist humanity in meeting the increasing nutritional demands. IoT is an innovation that already holds great promise as a solution to improving the productivity of agriculture in the most cost-effective way.

Almost every stage of traditional agricultural processes can be improved and automated with IoT. Smart irrigation makes it easy to efficiently use water, as sensors in the soil send information about the status of the soil to the IoT network, triggering it to release water as needed. [Greenhouse](https://en.wikipedia.org/wiki/Greenhouse) sensors can help you maintain optimum conditions around-the-clock by monitoring temperature, moisture level, and carbon dioxide concentration. You can also conveniently track livestock on your farm to manage the key data for their growth.

## How IoT Authentication Works

IoT authentication is a vital part of the trust framework for IoT machines and devices to identify one another in their network with the goal of protecting data and controlling access. Strong authentication is required so that connected IoT devices and machines can trust each other and be protected against unidentified access. This means every device receiving information in the IoT network must be able to automatically verify the source of that information.

### Why You Need IoT Authentication

Security and privacy are major concerns with IoT. The billions of data points generated by billions of IoT devices connected to the internet make the technology highly vulnerable to cyberattacks. For example, in 2016, [Dyn](https://account.dyn.com/), the largest domain name system infrastructure provider, was hit with a [DDoS attack](https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/) that brought down popular websites like Twitter, Netflix, and CNN. At the time, it was tagged as the largest [DDoS attack the world has ever seen](https://www.theguardian.com/technology/2016/oct/26/ddos-attack-dyn-mirai-botnet), and the attackers used poorly secured IoT devices to gain entry.

As a developer in your IoT-driven organization, you must consider IoT authentication as a key part of your security strategy. IoT poses a huge risk to your company's critical infrastructure, and bad actors tend to take advantage of the connectivity and entry points in the IoT network. For instance, unauthorized access can lead to data tampering which will possibly cause your team to make wrong decisions that could endanger machines and humans alike. Authentication helps you protect your devices and services from these unauthorized users and devices.

## How You Can Best Implement IoT Authentication

On a generic level, IoT developers and administrators register each device and deploy each one with [public key infrastructure (PKI)](https://www.tutorialspoint.com/cryptography/public_key_infrastructure.htm) that is linked to public key certificates for device authentication. PKI helps the IoT network to establish the legitimacy of a device in a network.

Ultimately, your organization must choose the best authentication strategy that suits your IoT system, and you need to do this by considering the type of devices in the network, the location, and the nature of data to be transmitted or received.

There are several ways you can implement device authentication in an IoT system. However, every device should be able to verify the source of information in a system consisting of hundreds, or maybe even thousands, of devices that are sending large volumes of data in milliseconds. This is why it is essential to have a trusted platform that can automatically handle device identity verification. [ZITADEL](/iot) is one such platform:

<img
  className="hidden dark:block object-contain my-auto mx-0rounded-lg"
  src="/images/iot/iot-02-dark.svg"
  alt="Authentication with short lived tokens"
/>
<img
  className="block dark:hidden object-contain my-auto mx-0 rounded-lg"
  src="/images/iot/iot-02-light.svg"
  alt="Authentication with short lived tokens"
/>

ZITADEL lets devices authenticate themselves with a device key and then uses tokens to send data to a backend service. These backend services receive the short-lived keys and carry out validation independently. For more information about the different token types available and their benefits, check out [this ZITADEL blog](/blog/jwt-vs-opaque-tokens).

For example, assume you manage the IT infrastructure in a hydroelectric power generation dam that uses IoT water level sensors to automatically control a floodgate. The floodgate has to open or close at certain water levels as measured by the IoT sensor in real time. In such a high-risk operational situation, the floodgate controls must securely verify that the data being received is coming from your sensor. At first, the sensors will request an OAuth token from ZITADEL as a [service user](/docs/guides/integrate/serviceusers#authenticating-a-service-user:~:text=and%20machine%20users%20%22-,Service%20Users,-%22.) by first enrolling with the private-public key pair generated in Zitadel,and with this key, the sensor can create a JWT token that it can now exchange with an OAuth token. After this, the device will send the data with the requested tokens to the floodgate control system. Before the incoming water level sensor data is processed, the receiver automatically contacts ZITADEL to verify the device with the access token. If verification is successful, the floodgate control system processes the water level data and takes action accordingly.

As you can see, cryptographic keys, or tokens, form an essential part of IoT device authentication with ZITADEL. You must ensure that the generated keys for [authentication are securely stored](/iot#:~:text=How%20to%20securely%20manage%20cryptographic%20keys) such that if they were compromised, your IoT system would still be secure.

## Conclusion

Proper execution of IoT authentication is immensely beneficial to the security of your IoT system. Similarly, having a good understanding of how IoT authentication works is highly important for you as an IoT solutions developer, whether you're adopting an IoT authentication service or building a bespoke solution for your business.

In this article, you learned how the Internet of Things authentication works and how you can best execute it with ZITADEL.

[ZITADEL](/) is an open source identity management platform that provides you with a wide range of features like OpenID Connect, secure Machine-to-Machine communication, 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 [Idowu Odesanmi](https://portal.draft.dev/writers/recr2TiHgJUuws1iP).*

Blog.