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


Maintaining proper password hygiene does not end with creating a strong password - **How your passwords are subsequently stored** is equally pivotal to the safety of your personal data.

The most common practice enterprises use to authenticate their users is implementing a system that **compares offered credentials to those stored in a centralized database.** Due to the comprehensive collection of user passwords in this database, it has unfortunately emerged as an **attractive objective for malicious actors.**

This article discusses the **importance of password hashing and salting** to secure password storage.

![Hashed Password Illustration](/blog/2023-05-18-password-hashing-01.gif "Password Hashing")

## What is Password Hashing and why is it used?

The term "password hashing" refers to the process by which a **cryptographic algorithm** converts a password irrevocably into a **string of characters and numbers known as a hash**. After this conversion, **the password is stored on the company’s server in its hashed state instead of plain text**. 

But why is it necessary to **store passwords as a string of code?** The answer is simple: Doing so helps to **safeguard it against a potential attack on the database**.

Imagine you are a user attempting to sign in to your company’s server. After entering your password, it is **automatically hashed and compared to the hash stored in the platform’s database**. If an attacker gained unauthorized access to this database, they could still only see a code in your password’s place. Since **password hashing is a one-way function**, it is impossible for them to determine the actual password from the hash alone. 

## The Importance of Salted Passwords

While holding a hashed password in a server's database is unquestionably safer than displaying it in plain text, **password hashing is still not immune to all types of cyberattacks**.

As an example, if the attacker were to **learn the hash function used by the hashing algorithm,** they could try conducting a **brute-force attack by entering random passwords into the function** until a matching hash is found. While this particular attack might often prove inefficient, because **hash functions can be configured to take a long time to execute,** there is, unfortunately, another method at the attacker's disposal:

One of the most common methods attackers use to crack password hashes is called the **“Rainbow Table Attack.”**

### Rainbow Tables 

Rainbow tables are **large databases containing precalculated hash values for common passwords**. If a hacker manages to compromise a hash already listed on the table, they can **trace that hash chain backward** to determine the original password.

Think of hashing a plaintext password as an equivalent of **translating a word into another language.** Just like how “Katze” is consistently translated as “cat,” the hash code for the password “qwerty” will always be represented by **the same combination of characters and digits.** Rainbow tables are similar to dictionaries, storing a list of passwords along with their corresponding “translations.” Therefore, **if a hacker figures out this universal hash** for “qwerty,” they would automatically be able to **recognize this password in every database** - as if it were written in plain text.

### Adding Salt to Hashing

As proven by the security issue posed by brute-force attacks and rainbow tables, **Password Hashing alone is not entirely foolproof.** Fortunately, a specific technique can be used to **boost hashes and subsequently counteract rainbow table attacks.** This method is called **Salt Hashing**, also known as adding Salt to a password.

In this context, **the term “salt” describes a random string of characters added to the password prior to hashing.** The hash is then created based on **the combination of the random salt and the password** instead of the password alone. Since the value of the salt is uniquely generated for every hashing process, **even if two users have the same password, their hash codes will differ.** Thus, making the rainbow table useless.

This technique of salting passwords has become a **fundamental element of modern hashing algorithms, such as bcrypt.** As opposed to weak hashes found in older algorithms, an attempt at breaking the robust architecture of salted hashing functions would require **far more computational power** than ever before. 

![Adding Salt to Hashes](/blog/2023-05-18-password-hashing-02.png "Password Salting")

## Hashing and Salting with Bcrypt

In the age of ever-evolving cyberattacks, **password hashing and salting are indispensable components of every current password management system.** Fortunately, a reliable **authentication solution** can lift these administrative responsibilities off your company's shoulders.

**ZITADEL** is a rapidly growing open-source platform that assists thousands of businesses in keeping sensitive information out of the wrong hands. The solution uses **bcrypt**, a ready-to-use high-level function **that handles the salt, hashing, and string encoding.** Due to bcrypt’s adaptability and integrated work factor, this tool is **highly successful in preventing unwanted access to user accounts.** Migrating users from a system that does not support bcrypt requires users to reset their passwords, as it is **impossible to transform one hash to another hash function** on the fly.  Thus, we will **expand the options of available hash-functions** in the future, such that **multiple hash functions are supported**. 


This article discusses the importance of password hashing and salting to secure password storage.

How Password Hashing and Salt Can Enhance Password Security


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

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

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

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

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

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

## What is Federated Identity Management (FIM)?

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

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

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

## SSO vs. FIM

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

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

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

### Range of Access and Scalability

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

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

### Complexity and Cost

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

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

### Security

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

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

## In Conclusion

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

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


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

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


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

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

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

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

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

## ZITADEL vs. Firebase

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

### Firebase Authentication

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

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

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

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

### ZITADEL Authentication

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

You can use the following authentication features with ZITADEL:

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

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

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

### Firebase Integrations

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

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

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

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

### ZITADEL Integrations

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

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

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

### Firebase Use Cases

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

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

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

### ZITADEL Use Cases

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

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

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

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

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

## Conclusion

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

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

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


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


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

Comparing ZITADEL to Firebase


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

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

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

## Who does GDPR apply to?

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

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

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

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

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

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

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

## The Liabilities of the Data Processor

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

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

## The Liabilities of the Data Controller

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

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

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

## In Conclusion

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

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

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

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


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

Why an Authentication Solution Is Crucial for GDPR Compliance


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

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

## What is social engineering?

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

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

## 6 Common types of social engineering attacks

### 1. Phishing and Whaling

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

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

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

### 2. Baiting

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

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

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

### 3. Pretexting

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

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

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

### 4. Honey Trap

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

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

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

### 5. Tailgating and Piggybacking

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

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

### 6. Quid pro Quo

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

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

## How to prevent social engineering attacks

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

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

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

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

### Limit the information you share on social media

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

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

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

### Do not give away your login credentials!

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

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

## The Takeaway

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

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



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

Social Engineering - How Hackers are Manipulating You

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

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



## 1. Introduction

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

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

### 2.1 OAuth2

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

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


_Dear Authorization Server,_ 

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

_Thanks,_

_Client App X_

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

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

#### 2.1.2 Deprecated Grant Types 

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

#### 2.1.3 Other Grant Types 

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

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

### 2.2 OpenID Connect (OIDC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 3.2 Choosing an Authentication Flow for an Application 

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


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

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


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

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

**API:**

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

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


**Service Users:**

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

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

## 4. Wrap Up

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

















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

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


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

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

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

## The most common 2FA Bypass Attacks

### 1. Password reset

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

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

### 2. Social Engineering

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

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

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

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

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

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

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

### 4. OAuth Consent phishing

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

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

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

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

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

### 5. Duplicate-Generator

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

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

### 6. SIM-Jacking

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

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

## How you can protect your account

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

## Be Careful With OTPs

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

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

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

## Switch to Passkeys

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

## Evaluate Consent Requests

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

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

## Never share your Authentication Code!

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

## In Conclusion

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


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

How Attackers Bypass Two-factor Authentication (2FA)


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?

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.

All posts/ #security