
With our recent release of [version 2.5.0](https://github.com/zitadel/zitadel/releases/tag/v2.5.0) of ZITADEL we introduce Support for Security Assertion Markup Language (SAML) as an additional technology standard used for authentication.
Our goal with ZITADEL is to build the best identity and access management platform for the serverless era.
With the addition of the standard we significantly extend the range of applications you can integrate and identity providers you can use for SSO.

Until today we provided Support for the more modern authentication standard OpenID Connect (OIDC).
Our [zitadel/oidc](https://github.com/zitadel/oidc) library for golang, which is being used in ZITADEL, also passed the [OpenID Connect certification](/blog/openid-connect-certification).
We still recommend to use OIDC, especially when you're working with Single-page-applications, Mobile native clients, REST APIs, or when it's stimply a tie between OIDC and SAML, as we have [discussed in a previous blog](/blog/saml-vs-oidc).

Nevertheless, there are still a lot of enterprise applications that can only handle SAML for SSO.
So if you would like to use your existing identites to sign-into tools like Atlassian, Gitlab, Google Workspace, AWS, Citrix Netscaler, etc. you need to do so via SAML.
While we are hoping that OpenID Connect replaces SAML over time, we decided to offer SAML support in ZITADEL, so that you don't have to worry about this fact.

To get started you might want to checkout [our guides how to integrate different applications](https://zitadel.com/docs/guides/overview).
For more technical details you might want to refer to the [SAML Endpoints](https://zitadel.com/docs/apis/saml/endpoints).

With our implementation we follow the given [open standards for SAML](https://github.com/zitadel/saml#Resources) and support the most relevant [SAML features](https://github.com/zitadel/saml#Features).
While we support POST- and Redirect-Binding we opted to leave out the more secure Artifact-Binding for now, as only few clients support the latter and most likely opt for the more conventient OIDC alternative.

We release SAML as an early feature. Although we have tested ZITADEL agains multiple applications, we expect to find some issues around clients being not conformant with the standard, or some technical problems over the next couple of weeks.

If you run into any technical problems or have specific questions, please raise an [issue over on Github](https://github.com/zitadel/saml) or [ask in our Discord](https://zitadel.com/chat) for help.


With the latest version of ZITADEL we introduced support for the security a session markup language protocol which gives you a broad range of new options for Single-Sign-On with your favorite apps

Does your application only support SAML? Fear not, ZITADEL can help you!


One of the critical challenges in designing software systems is identity management. User accounts need to be created, maintained, and promptly secured to ensure the safe and continuous functionality of critical business systems. However, doing so is easier said than done.

With the current diverse digital ecosystem, which includes various terminals, such as mobiles, IoT devices, smartwatches, and web applications, creating a unified security standard is imperative.

[OpenID Connect (OIDC)](https://openid.net/connect/) protocol addresses this challenge by providing a means for both verifying users and defining their permissions. It makes it easier for application developers to implement robust identity management.

In this article, you'll learn what OIDC is and develop a high-level overview of its working mechanisms. You'll also learn about the value it adds to your business. In addition, you'll learn about the options OIDC provides to help you customize the user login to improve security and user experience. 

## What Is OIDC

Before discussing OIDC, it's vital to distinguish two security concepts: authentication and authorization.

Authentication is the process of verifying who the user is. Authorization is the process of verifying what the user can do.

You can think of authentication and authorization as a gym membership card with several subscription levels. When you present the membership card to the receptionist, they need to do two things:

1. Ensure that the card is real and that you have permission to access the facility (*ie* to authenticate you).
2. Ensure that you can access the specific gym features based on your subscription level. For example, you may only be allowed to access the training area but not the sauna (*ie* to authorize you).

OIDC protocol does the same thing but in the digital world. It helps you to authenticate and authorize users and applications attempting to access your resources.

To achieve that, the OIDC protocol utilizes two security tokens:

* **Access token:** a time-limited [JWT ](https://en.wikipedia.org/wiki/JSON_Web_Token) or opaque token that can be used to authenticate and authorize the user.
* **ID token:** or a JWT token containing a set of claims (*ie* user characteristics). You can use these claims to add relevant information indicating which resources the user can access (among others). That is to *authorize* the user.


<div className="dark:hidden">
  <img src="/blog/2022-09-08-use-oidc-auth-request-01-light.png" alt="OIDC authorization flow courtesy of Mohammed Elrasheed"></img>
</div>
<div className="hidden dark:block">
  <img src="/blog/2022-09-08-use-oidc-auth-request-01-dark.png" alt="OIDC authorization flow courtesy of Mohammed Elrasheed"></img>
</div>

### Overview of the OIDC Protocol

Before explaining the typical OIDC protocol flow, it's important to explain what makes up the flow, which is mainly the resource provider and the authorization server.

The resource provider, where the data resides (denoted as "Resource Provider" in the previous visual), trusts (or considers the access tokens issued from the authorization server as a valid authentication method) the authorization server.

> Note: You'll also hear tech people say that the end-user identity is "federated" to an external party, the authorization server also known as the [OpenID Provider (OP)](https://infosec.mozilla.org/guidelines/iam/openid_connect.html).

For instance, imagine a scenario where the end user wants to authorize the application (client) to access their data in the resource provider. Here, the authorization flow takes place like this:

1. The client application that wants to access the data in the resource provider redirects the end user to the authorization server with an authorization request to log in.
2. The authorization server validates the end-user login request and returns the access token and ID token to the client application.
3. The client application uses the access token to authenticate and authorize against the resource provider.
4. The resource provider validates the access token with the authorization server.
5. If the access token is valid, the resource provider returns the response to the client application.

For more details about the inner workings of OIDC, [check out this video](https://www.youtube.com/watch?v=996OiexHze0).

## Why OIDC

Now that you know how OIDC works, it's important to look at the benefits it can offer:

### Single Sign-On

One of the key benefits of the OIDC protocol is that it enables single-sign-on (SSO). SSO is the process of authenticating the user against the authorization server and then signing in the user to all relevant applications that trust that authorization server. This is commonly used in enterprises where employees need access to several systems, such as HR, accounting, and training systems.

Rather than having the employee create an account for each system separately (with separate passwords for each), the user can log in once to the authorization server. After that, the user will automatically be logged into all relevant systems. This improves user experience and reduces password recovery requests.

### Ubiquitous Technology Access

The OIDC protocol supports a wide range of flows (*ie* versions) that enable you to use the protocol for various scenarios, including APIs, web applications, mobile applications, and devices.

### Centralized Credentials Store

In OIDC, all credentials are stored in a secure, centralized location: the authorization server. This cuts down on maintenance costs that would otherwise be required to maintain multiple credentials stores.

## How to Customize User Login with OIDC

Whenever your application sends an authorization request to the authorization server, it must provide a set of [required parameters](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) to specify the authorization request details. These parameters are as follows:

* **`scope`:** This must be at least `openid` to indicate that it is an OIDC protocol. It's also possible to send other scopes like profile or email. If the `openid` scope is missing in the request, its behavior is unspecified.
* **`response_type`:** The [authorization flow](https://www.scottbrady91.com/openid-connect/openid-connect-flows) to be used. The authorization flow indicates what type of client is requesting the tokens.
* **`client_id`:** A client identifier at the authorization server end.
- **`redirect_uri`:** A redirection URL to which the authentication response will be sent.

Besides these parameters, there are other optional parameters you can use. These optional OIDC parameters enable you to further customize and secure the login experience. These include the following:

* **`prompt`:** This parameter is a case-sensitive list of ASCII string values that indicates whether the authorization server should prompt the end user to authenticate again and consent. It supports the following values:

   * **`none`:** The authorization server must not display authentication or consent user interface pages (also called silent authentication). The authorization server will return an error message if the end user is not already authenticated.
   * **`login`:** The authorization server should trigger the end user to authenticate again with credentials via a UI prompt. It will return an error if it cannot authenticate the end user.
   * **`consent`:** The authorization server should get the end-user consent before returning data to the client. If it cannot get the consent, it must return an error.
   * **`select_account`:** The authorization server should prompt the end user to choose a user account. This is helpful if the end user has more than one account at the authorization server. If it cannot get an account chosen by the end user, it must return an error.
   * **`login_hint`:** This parameter hints to the authorization server about the login identifier the end user may use. A typical value to use in the `login_hint` is the email address, the user name or the login name. Passing the `login_hint` either prefills the email box in the sign-in form or selects the correct user session (if the user has multiple sign-ins, similar to what you can have in Gmail).
   * **`max_age`:** This specifies the maximum allowed time in seconds since the end user was actively authenticated by the authorization server. The end user will be prompted to reauthenticate if this time is exceeded.
   * **`state`:** The main objective of the `state` parameter is to protect against [cross-site request forgery (CSRF)](https://owasp.org/www-community/attacks/csrf) attacks. This is done by using a unique and hard-to-guess value and associating it with each authentication request. Later, you can protect against the attack by verifying that the value in the response matches the value you had in the request.
   * **`nonce`:** This is a string value used to associate a client session with the ID token to prevent [replay attacks](https://en.wikipedia.org/wiki/Replay_attack). The `nonce` will be included in the response from the authorization server. This enables the applications to correlate the ID token response with the initial authorization request.
   * **`ui_locales`:** This specifies the end user's preferred language, represented by a space-separated list of language tags. The list is ordered by preference. For example, the value `en-US fr ar` represents a preference for American English, French, and Arabic.
   * **`display`:** This is an [ASCII string](https://www.computerhope.com/jargon/a/ascii.htm) value that dictates how the authorization server displays the authentication and consent dialog to the end user. The following values are supported:

      * **`page`:** The authorization server should display the dialog with a full user-agent page view. This is the default behavior if the `display` parameter value is not specified.
      * **`popup`:** The authorization server should display the dialog with a pop-up user-agent window.
      * **`touch`:** The authorization server should display the dialog consistent with a device that uses a touch interface.
      * **`wap`:** The authorization server should display the dialog consistent with a ["feature phone"](https://en.wikipedia.org/wiki/Feature_phone)–type display.
      * **`id_token_hint`:** This is the ID token previously issued by the authentication server being used as a hint about the end user's current or past authenticated session. If the user is logged in, it returns a positive answer. Otherwise, it will return an error.

## Conclusion

In this article, you learned that OIDC is a protocol that enables you to federate the user authentication and authorization to an external authorization server, which simplifies your workload. You also learned about the SSO, ubiquitous access, and centralized security benefits that the OIDC protocol brings to the table.

In the end, you learned how to use several parameters to improve user login, such as the `prompt` parameter to control the reauthentication experience and the `display` parameter to control the login form view.

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

*This article was contributed by [Mohammed Osman](https://portal.draft.dev/writers/recvOT7Hsq96gfwnR).*

One of the critical challenges in designing software systems is identity management. User accounts need to be created, maintained, and promptly secured to ensure the safe and continuous functionality of critical business systems. However, doing so is easier said than done.

Use OIDC Authorize Request to Customize User Login


In our ongoing effort to build the best identity and access management platform for the serverless era, we extend the database compatibility of our solution.
We are happy to announce that with the recent [release of version 2.3.0](https://github.com/zitadel/zitadel/releases/tag/v2.3.0) ZITADEL supports the PostgreSQL database model.

Up until now ZITADEL was only available with CockroachDB as storage.
As already noted back in our talk with CockroachDB, which you can [find on our Blog](/blog/how-we-built-it-cockroach-labs), right from the start we considered going with plain PostgreSQL as storage.
But opted for CockroachDB first for the cloud-native approach and shared-nothing architecture which gave us great benefits in running globally-scalable and zero-downtime service for customers.

Over time, however, we have received more requests from our community to provide support for alternative databases.
As many already operate or use a managed PostgreSQL database for their own services, this helps reduce the learning curve and overhead in managing different database setups.
With that we've heard your wishes and implemented PostgreSQL support for ZITADEL. It is available for self-hosting setups from today in a beta stage.

To get started checkout the [Guide in our Docs](https://zitadel.com/docs/guides/manage/self-hosted/database#postgres). Note that you need to overwrite the values of the [base configuration](https://zitadel.com/docs/guides/manage/self-hosted/configure) with these values.

As mentioned above, this is an early feature. ZITADEL has been tested against a plain-vanilla PostgreSQL database. If you run into any technical problems or performance issues, please raise an [issue over on Github](https://github.com/zitadel/zitadel) or [ask in our Discord](https://zitadel.com/chat).

We extend the database compatibility of ZITADEL with support for PostgreSQL databases in addition to CockroachDB.

You wanted PostgreSQL? We got you covered.

As a result of partaking in a society, we humans are indirectly **confronted with the phenomenon of trust every day**: We trust teachers with educating our children, cooks with making our food, and banks with handling our money. Furthermore, trust is also a fundamental practice in our work lives. When our colleague, Joe, is sitting next to us in the office, we can safely assume that he is indeed himself and a member of our team. Can we, however, **still be this confident in his identity when all we see is his displayed name**? 

Given the ever-growing prevalence of **remote jobs, bring your own device (BYOD), as well as SaaS and cloud-based assets**, the importance of secure and trustworthy authorization and authentication processes has significantly increased. As a new alternative to traditional perimeter security, Zero Trust was developed with this modern digital environment in mind: Instead of defending network segments, it focuses on **safeguarding resources** (assets, services, processes, network accounts, etc.), as the location of the network is no longer considered to be the primary factor in its security posture. Thus, by utilizing a **reliable, verifiable source of identification**, Zero Trust aims to assure that a person is who they say they are.

This article explains the functionality of Zero Trust and its benefits over older security perimeters.

## What is Zero Trust?

Zero Trust describes a **strategic security framework** developed to reorient defenses away from network-based, static perimeters and toward users, assets, and resources. Its core functionality is to **eliminate fraudulent access to network systems by removing implicit trust** granted to accounts based on **superficial user traits such as location or asset ownership**. Simply put, Zero Trust is determined to take security measures **as though hackers have already gained unsolicited access to a network**: Accordingly, there is no such thing as a trusted insider within a specified perimeter anymore, and everyone is potentially guilty until proven innocent. Although this approach might sound harsh in theory, it only means that an AI is **discretely authenticating, authorizing and continuously validating users** or machine accounts before granting access to digital resources in order to eliminate the chance of an impostor on the network.

In addition to its core principle and functionality, Zero Trust's highly advanced security architecture is also attributed to its **numerous supporting technologies**. These include:

* **Multi-Factor Authentication (MFA)**: Ensures with the help of a second login factor (f.e. One-time-password, Biometrics, etc.) that the device is in possession of the intended user.
* **Privilege Access Management (PAM)**: Allows an access restriction to implement "least-access privilege" for every user.
* **Principle of least privilege (PLP)**: Requires secure authentication at every transaction instead of just at the "perimeter," thereby improving login security and preventing lateral movements.

## A passing trend or worth the hype?

As remote and hybrid work is becoming increasingly common, it is unsurprising that **products supporting zero trust are rising in popularity**. While this new security framework was initially considered a luxury feature, it has gradually evolved into a **necessity for businesses of all sizes**. According to [Statista](https://www.statista.com/statistics/1228254/zero-trust-it-model-adoption/), 72% of organizations participating in their 2021 survey **plan to adopt Zero Trust in the future or have already implemented it**. Naturally, this newfound supply originates from a **growing demand for higher security and trust earned through entity verification**: Given the drastic rise in cyberattacks in the 2020s, SME IT professionals ranked "adding layered security so work-from-anywhere is truly secure" as their [top priority for 2021 and 2022](https://jumpcloud.com/blog/zero-trust-benefits-smes). 

Fortunately, implementing Zero Trust has proven to be a valuable decision for countless enterprises: [IBM](https://www.ibm.com/security/data-breach) finds that the **average data breach cost** for organizations without zero trust deployment was USD 1 million higher. Not only is Zero Trust helpful for damage control, but it also significantly decreases the possibility of an attack: With the help of its security automation, breaches could be detected and contained [27% faster](https://www.teramind.co/blog/cost-saving-effect-of-zero-trust/). 

## Enabling Zero Trust with Identity Aware Proxies 

Now that the concept and benefits of Zero Trust have been established, it is essential to mention its core component that makes all the running: The **key element of enabling zero-trust** access is the help of an **Identity-Aware Reverse-Proxy (IARP)**. Not to be confused with IARP are forward Identity-Aware-Proxies (IAP); While the latter sits in front of a client and ensures that no origin server ever connects directly with that specific client, a reverse proxy sits in front of an origin server and makes sure that no client ever communicates directly with that server. 

Identity-Aware Reverse Proxy is a modern, context-aware, and identity-aware authentication and authorization mechanism that replaces the traditional VPN-based access control mechanism: While VPNs use session-based access, IARP permits only per-request application access. Furthermore, in contrast to a VPN, which often grants users access to a large portion of an internal network, a zero trust architecture frequently calls for **creating much smaller network segments** and protecting these with IAPs.Through the **mapping of identities registered with each resource**, IARP **centralized the definition of access policies** and access control for servers as well as applications. Therefore, it **facilitates the implementation of Zero Trust security** and makes gaining **widespread access to several resources considerably more difficult.**

## Zero Trust and ZITADEL

As in Identity and Access Management Platform, ZITADEL's highest priority and most significant promise is to **keep its user's data secure**. To ensure this promised level of protection, the **application has enabled the deployment of Zero Trust access through its support for [Identity Aware Reverse-Proxy](https://zitadel.com/docs/examples/identity-proxy/oauth2-proxy)**. This new architecture was implemented according to the NIST standard: An official guide by the *Computer Security Resource Center*, describing processes for safely migrating to a Zero Trust framework. Accordingly, ZITADEL **regulates access to all applications** and delivers **per-request application access**, regardless of where the users are located, how they are authorized, and what device they use.

To learn more about ZITADEL, visit our [Website](https://zitadel.com/contact). Should you have any questions, feel free to contact us anytime on our [Discord Server](https://zitadel.com/chat). Alternatively, you can reach us on our [Twitter](https://twitter.com/zitadel), [Linkedin](https://www.linkedin.com/company/zitadel/), or [Github](https://github.com/zitadel/zitadel) pages.

Given the ever-growing prevalence of remote jobs, bring your own device (BYOD), as well as SaaS and cloud-based assets, the importance of secure and trustworthy authentication processes has significantly increased. This article explains the functionality of Zero Trust and its benefits over older security perimeters. 

Why Zero Trust is Important

Given the explosive popularity of cloud services in recent years, we are now increasingly seeing organizations of all sizes seeking to utilize Software as a Service applications. While **SaaS is generally an ideal deployment option for businesses seeking a pre-configured platform**, many such applications are solely equipped with a single-tenant architecture, thus significantly **limiting the addressed use cases**. Therefore, if your organization is looking for a SaaS provider with enhanced scalability, a high level of customization and the opportunity for a Business-to-Business (B2B) use case, we strongly recommend **looking into the concept of multitenancy**.

This article will discuss multitenancy's definition and its benefits over a single-tenant SaaS architecture.

## What is multitenancy?

In a nutshell, multi-tenant architecture is a **cloud-oriented ecosystem** that uses scalable, available, and resilient architecture, allowing **one SaaS application to support multiple tenants**. It has the primary purpose of **sharing a database and codebase** across all clients with a similar data structure while their **data remains logically separated**.

At its core, multitenancy is conceptually similar to an **apartment complex**. Within this context, the apartment building represents a single SaaS environment that hosts multiple tenants (customers).

![](/blog/2022-08-17-multitenancy-02.png)

The business providing the multi-tenant SaaS application takes on the role of the construction enterprise and landlord. In this example, this buisness is called Apolon. Apolon’s SaaS solution serves three clients: Miho, Posh, and Cyane; the tenants of the “apartment.” While the **tenants share** their computational, networking, and storage **resources, their personal data is isolated** **and invisible to each other**; reminiscent of the fact that real-life apartment renters do not have unsolicited access to other flats either.

If you view multiple apartments of the same complex, you will likely find that despite their differences in furnishings and decorations, each flat shares the **same fundamental architecture**. The concept of a multi-tenant SaaS environment functions according to a similar scheme: While Apolon’s core application functionality is reused for each of its customers, they can **customize the certain aspects of their experience**, such as login according to their respective organization’s attributes (f.e. colors, logo, selected secondary login-factors, etc.).

To regulate access to specific aspects of the application, tenants generally **assign specific roles to each member of their organization**. Thus, each member of the organization automatically **receives the corresponding authorization** that their role entails.

## The Benefits

While the previous chapter explained the structure of a multi-tenant architecture as a metaphor for an apartment complex, within that same context, a single-tenant architecture would be best represented by tract housing. With these real-life parallels of these two technical concepts established, the differences they hold over each other become increasingly evident. The following paragraphs list **the most significant benefits multitenancy has over single-tenant architecture**.

### Shared resources and bases - Easier implementation

In the case of tract housing, the lots (SaaS) are constructed by the same enterprise (the business providing the single-tenant SaaS) and are, therefore, akin to apartments, identical in their fundamental architecture. However, unlike households within the same complex, the tenants of tract houses **do not share any commodities:** The environment only **serves a single customer**. For this reason, each tenant of a single-tenant architecture **requires dedicated computing, network, and storage resources, as well as data- and codebases** that would need to be **individually integrated** into each environment.

SaaS applications with a multitenant architecture, such as ZITADEL, include a **single codebase** along with a **code repository** with a few branches. By not having to individually implement every branch of code to a potentially large number of tenants, the **deployment process is easily carried out with the help of just one command** (one-click-deployment).

### Freehand maintenance

Similar to the maintenance of an apartment complex, in which the association maintains all expected amenities, the SaaS vendor is responsible for several aspects of database upkeep. To lift some weight off the provider’s shoulders, the multi-tenant server is **regularly launching automated upgrades and optimizations**, thus **preserving the performance and agility** of the application.

### Lower prices

The **shared commodities and responsibilities** provided by a multi-tenant architecture also result in **lower fees for the SaaS vendor:** Instead of paying for multiple deployment and maintenance processes individually provided to every tenant, the **cost of the environment is shared**. As a result of these low and predictable ongoing costs, the application can generally be sold for a set subscription price.

### Higher scalability and easy customization

Most multi-tenant SaaS applications provide tenants the ability to **scale on demand**. Furthermore, since every additional user receives access to the same basic software, the process of scaling has far **fewer infrastructure implications** than within a single-tenant solution.

Multitenancy also allows for a **facile, coding-free customization process**. For example, ZITADEL’s SaaS solution allows each tenant to personalize their login flow by determining the Federation (Azure AD, Google Workspace, etc.), password policies, colors, logos, domains and login multi-factors.

### Support for B2B

One of the most common use cases of multitenancy is within a B**usiness to Business (B2B)** context. Due to its formerly mentioned advantages, we recommend a SaaS with a multi-tenant architecture to B2B vendors that wish to **provide isolation and branding for their clients' organizations** without wasting money, time and resources.

## In Conclusion

The **resource-sharing capabilities** of multitenant services allow them to function with **lower infrastructure and maintenance costs** while simultaneously providing **higher operational effectiveness**. Despite the environment’s shared commodities, the **affordable multi-tenant SaaS solution of ZITADEL** ensures each tenant complete privacy regarding their data, a highly customizable login flow and on-demand scaling.

To lean more about ZITADEL, feel free to contact us anytime on our ZITADEL [Discord Server](https://zitadel.com/chat). Alternatively, you can reach us on our [Twitter](https://twitter.com/zitadel), [Linkedin](https://www.linkedin.com/company/zitadel/) or [Github](https://github.com/zitadel/zitadel) pages or on our [Website](https://zitadel.com/contact).

This article discusses multitenancy's definition and its benefits over a single-tenant SaaS architecture.

Everything you need to know about Multitenancy


As a result of many months of diligent effort from our community and developers, we are thrilled to finally announce the first significant upgrade to our Identity & Access Management (IAM) platform: ZITADEL Version 2.0. Discover a new selection of features and upgrades that ensure easier use, expanded compatibility, more value for your money and as always, still the highest possible data security.

This new upgrade is a massive milestone in the product’s lifespan, bringing us a big step ahead in providing developers with the best open-source alternative for all their identity management and authentication needs.

This article briefly lists the most noteworthy changes brought on by V2.0. For further information on the update and a migration guide, check out the [Release Notes](https://github.com/zitadel/zitadel/releases/tag/v2.0.0).

<p align="center">
  <strong>We're on <a href="https://www.producthunt.com/posts/zitadel">ProductHunt</a> and <a href="https://news.ycombinator.com/">HackerNews</a> today. <br/> Thanks for all the support from our great community!</strong>
</p>

## What is ZITADEL?

The journey of ZITADEL began in 2019 when an inspired startup team envisioned creating a **developer-first, open-source approach to solving identity management**. This vision resulted in a set of engineering and design principles, ultimately leading to the release of Version 1 in late 2020.

Within these two years, ZITADEL has established itself as a unique turnkey open-source platform that offers developers unprecedented flexibility by combining the best aspects of older IAM solutions, such as the **ease of Auth0 and the versatility of Keycloak**. Thanks to its secure login, user management, multi-factor authentication, social logins, authorization management and great APIs, ZITADEL exists to provide a **safe and customizable authentication server for software products**, be it in a self-hosted or Software as a Service (SaaS) version.

Thus, with the help of ZITADEL, your organization can s**pend more time and effort in building your main product and growing your business** while your login needs are taken care of.

## What’s new?

### New Virtual Instances

The introduction of virtual instances brings another significant change to our platform. Previously, when users wanted to operate a complete ZITADEL instance in addition to single organizations, they had to **upgrade their system from a public cloud service** or self-host their ZITADEL. Version 2.0 aimed to lift this barrier by granting **every ZITADEL user their own virtual instance free of charge**. As a result, users can now fully configure their instance policies for each organization instead of relying on the ones previously predetermined by the platform.

Suppose your organization needs an additional system or two (for example, for testing and production, respectively). In that case, you have the option to run multiple isolated ZITADEL instances simultaneously that share the underlying process and infrastructure. With the help of this communal framework, users are **spared the efforts of individually configuring each additional instance**.

Beyond the previously mentioned benefits of higher convenience, customization, and reduced cost, the **possession of a ZITADEL instance comes with some additional perks**, such as:

- The ability to configure multiple custom domains (such as login.mycompany.ch) and access to a simple route if you ever need to migrate them
- The possibility to send transactional e-mails from your mail server
- Configurable notification channels (SMTP, Twillio)
- A selectable [data residency](/blog/data-residency) (Switzerland, global, or GDPR-compliant regions)
 
### Easier to Develop

Setting up a local development environment that mirrors production can be time-consuming. By **facilitating the overall process in Version 2.0**, our goal is to relieve some of the developers' burdens and **make implementing new features more straightforward**.

New features that should facilitate development:

- [Terraform provider](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs) to make ZITADEL easy to use in GitOps flows
- [Helm Chart](https://github.com/zitadel/zitadel-charts) for our Kubernetes users
- Compatibility with serverless platforms, such as Knative and Google Cloud Run
- All services (Login, APIs, Assets, etc.) now run under one IP and port and are being routed through their paths
- Reworked [ZITADEL Docs](https://zitadel.com/docs/) to better reflect our users’ needs.

### Pricing Update

One of the most notable upgrades of our Cloud Service, running the Version 2.0, is the **reimagining of our cloud pricing system**. The idea behind this change is to facilitate the processes of getting started with ZITADEL and gradually expand the platform based on your organization’s specific needs.
To achieve this goal, we have decided to **remove subscription tiers and their respective feature locks altogether**.
With the help of the new **“Pay as you go”** pricing model, customers of ZITADEL are **freed from the restrictions of a predefined feature bundle**.
They can therefore experiment with much more of what ZITADEL has to offer **without hitting a paywall**.

More information on our new free features and the ZITADEL Cloud pricing model can be found in [this article](/blog/pricing-updates-v2).

### What’s next for ZITADEL?

While Version 2.0 has been a huge stepping stone in our product’s journey, in this ever-evolving digital world, the work of a platform handling sensitive data is never over. With new technological changes, enhanced security requirements, and sneakier cybercriminal tactics gradually emerging, ZITADEL must do its best to **retain its position as an innovative and highly secure open-source IAM solution**.

By constantly keeping track of the newest technological modernizations and evaluating individual feedback from its users, the team behind the platform always manages to set new goals to work towards. The following months of this year will bring an **extensive list of new features currently in development**.

**Features coming soon to ZITADEL:**

- SAML 2.0 – A new protocol alternative to OIDC
- More [Social Login options](/blog/social-logins)
- Significant improvements to the [Register Flow UX](/blog/six-ways-zitadel-will-improve-2022#3-improvements-based-on-prototype-feedbacks) based on user feedback
- Extend the database support to [Postgres](https://github.com/zitadel/zitadel/issues/3898)
- Each additional planned feature is listed on our [Roadmap](https://zitadel.com/roadmap).


As a result of many months of diligent effort from our community and developers, we are thrilled to finally announce the first significant upgrade to our Identity & Access Management (IAM) platform - ZITADEL Version 2.0.

Introducing ZITADEL Version 2.0!


Millions of kids today already possess a digital identity, whether in an online game, social media, or various other platforms and apps. While it might bring them lots of joy to share their thoughts with the world and make friends, **shared information can be misused**. Although younger generations are increasingly taught about online safety, given a child's natural innocence and subsequent naiveté, they might not adequately apply this theoretical knowledge in practice; thus, making them an **interesting target for ill-wishers** intending to **take advantage of their wide-eyed nature**.

![](/blog/2022-07-14-children-01.gif)

As the world is becoming increasingly digital, cybersecurity measures are constantly evolving to provide the highest possible safety to users online. Unfortunately, **it is not only people with good intentions adapting to technological innovations**: Given the numerous tactics of contemporary cybercriminals, such as advanced hacking methods and phishing attempts, an approach to simply limiting a child's digital information for viewing may not be the single best method. Therefore, it is crucial for parents, guardians, and caregivers to **be aware of the risks of possessing a digital identity** and the measures they can take to **protect children's data** without having to give up on the cyber world entirely.

## New digital threats kids are subjected to 

To understand what measures we can take to protect our youngsters, it is essential to be **able to recognize a threat coming their way**. As the number of children owning smartphones and other digital devices gradually increases, it is only consequential that most have at least created one digital identity. Sadly, however, doing so inevitably places a target on their backs: According to the [FBI Internet Crime Center Report](https://www.fbi.gov/news/press-releases/press-releases/fbi-releases-the-internet-crime-complaint-center-2020-internet-crime-report-including-covid-19-scam-statistics), in 2020, the crime against children increased by 144% compared to the previous year. The data show that **eight children per day are facing online exploitation**. Similarly to the US, [Europe’s cybercrime](https://www.europol.europa.eu/media-press/newsroom/news/covid-19-sparks-upward-trend-in-cybercrime) also undewent a significant increase in recent years, including a sharp spike in detection of online child sexual abuse material.

The following chapter lists some of the most prevalent online threats children face today.

### Phishing

The ever-evolving phishing phenomenon has established itself as one of the **most notorious cybercrimes in the last 20 years**. While it takes on various forms (for example, **[Smishing](https://zitadel.com/blog/smishing)**), phishing is generally characterized by an attacker masquerading as a trusted entity to **trick random people into giving away valuable private information**, such as login credentials or credit card information. The criminal usually aims to deceive the victim by sending a message or mail **depicting a situation that is known to grab their attention**, such as a package delivery notification, a purchase confirmation, or a credit card suspension notice; these are mostly tied to an URL the recipient is requested to click on, to follow up on the situation at hand. In some cases, **clicking the provided link can initiate a download process of viruses** or malware, which the cybercriminal can use to access all data and information stored on the victim's device.

While phishing poses a significant threat to people of all ages, due to most children's more minor experience with online scams, they are **far less likely to spot a perpetrator posing as a legitimate institution** or person compared to their older counterparts. Knowing this behavior, numerous **cybercriminals are present on websites, apps, and games with a high percentage of young users**.

**Some of their most common phishing tactics targeting children include:**

- Spreading malware disguised as free games
- Claiming to give away in-game currency of popular games for free (f.e. V-Bucks Generators)
- Assuming the identity of a person or service the child trusts
- Small games designed to collect personal information (f.e. Enter your full name and birth date to find out which Disney princess you are)

### Identity Theft

In the digital age, it is not just material items that can be stolen but also someone's entire identity. Some scammers use the accessed data to **claim the essence of their victim** for various diverging causes apart from stealing money, such as filing phony health insurance claims, committing tax fraud, or even reselling data to other criminals.

The perniciousness of juvenile identity theft is heightened by the fact that **kids often don't receive financial records**, credit card statements, and other correspondences that can alert adults to questionable economic activity. Consequently, the crime may continue for a long time before being discovered.

### Registration and Access Requests

While many people believe that users of digital platforms are only subject to cyber threats once an account is already created and in use, this assumption might not prove entirely true, it is significant to **weed out as many potential risks as possible** during the first stage of a person's online presence: Registration.

Should the child in your care wish to join a platform with a base of registered users, you might want to **read the Terms and Conditions carefully**; not only do they include what user data they will request and utilize, but also what they will be used for. If, for example, a platform entirely unrelated to activities involving your address makes it mandatory for it to be entered, it might be eye-opening to read up on the reason for this request. Furthermore, scammers and predators can **exploit the information entered upon registration** to target unsuspecting children. Accordingly, it is advised to be aware of the site the child is joining and what information and data it aims to gather.

## How can I protect the children in my care?

With the previous chapters explaining the most common digital risks kids (and people in general) are subjected to, this chapter aims to aid guardians in minimizing the chance of their children falling victim to such cybercrimes with the help of some **useful technical measures**.

### Enable Passwordless or MFA

As an enthusiastic six-year-old in the mid-2000s registering to an online platform for the first time, my father advised me to choose a password I could remember effortlessly. Thus I went with “marzipan”; the knowledge factor I would go on to use for each of my accounts for the following three years. However, as the years passed, **password requirements have become increasingly strict**, and accounts merely protected by a simple word such as “marzipan” could be hacked within less than a second. Whereas the normalization of “stronger” passwords has helped safeguard countless user profiles, their usage simultaneously **contradicts the original purpose of knowledge factors being easily recallable**: With this being said, how many six-year-olds would be able to flawlessly remember a password with 18 characters, including numbers, symbols, and majuscules?

To sum up, while the usage of passwords has been the industry standard for decades, the evolution of technical knowledge amongst the public also opened the door for more and more cybercriminals who **take advantage of the simplicity of this authentication method**. As a result, more and more platforms are turning to more secure login alternatives, such as **[Multi-Factor Authentication (MFA)](https://zitadel.com/features#multifactor)** or **[Passwordless](https://zitadel.com/blog/passwordless)**. The former commonly utilizes a passwordless factor (such as Fingerprint, Face ID, or physical tokens) in addition to the regular username-password login method, while the latter provides a single-factor approach that completely substitutes passwords with a passwordless factor. Enabling either of these two methods make it **significantly harder for criminals to hack into the user’s account**, even if they manage to get ahold of the password. Therefore, we strongly recommend people of all ages consider switching to the usage of MFA or passwordless whenever possible.

### Checking the operating system

Since such a number of phishing attacks and digital scams have the motive to install malware on the victim’s devices, it is strongly recommended to double-check the viability and security of your operating system. Optimally, **the system should be updated to its newest version/patch, and the security recommendations** (f.e. Windows Defender) **enabled**. Alterantively, independent antivirus programs serve to **automatically detect malicious applications, websites, and files** that could pose a threat to your device's security.

### Use a VPN

To ensure a safer registration process, make sure the platform the child submits their private information to uses a **verified SSL certificate**: It serves as a confirmation that communication between the browser and the server is encrypted. The possession of this certificate by a website is typically indicated by a **closed lock symbol and a URL prefixed with HTTPS**. Since some platforms are still not equipped with this feature, a trusted VPN service can help hide some information.

**Virtual Private Network (VPN)** software provides **privacy by encrypting all your incoming and outgoing traffic**, no matter where you are located and which network you use. This protection is achieved by the VPN **hiding your internet protocol (IP)** **address**, thus making it nearly impossible for others to track your online activities (including file downloads), so that cybercriminals and other unwanted parties cannot see them.\
\
Using a VPN is especially important when browsing via a **public Internet Connection (WiFi)**. If the person connected to an unsafe network logs into an unencrypted site, other connected users will be able to see what they send and view. With the help of manual encryption of all data traffic, a VPN-router is an optimal way to **prevent third-parties from unwantendly accessing private information** shared via a public network.

### Enable Adblocker and Content Blocker

Anyone who has used the internet before has most likely encountered online advertisements. Unfortunately, some of them have been **designed with a purpose beyond their traditional functionality**: These malicious ads can **gather precious information from the individual viewing them**. To prevent the creators of such advertisements from spying on your children, you have the option to add **ad-blocking extensions** to their browser. Doing so also dramatically reduces the risk of them seeing commercials for highly unsuitable services for minors.

In the unclearly regulated world of the internet, it is not only ads and popups that can lead to involuntary exposure of kids to malicious, unsafe, or inappropriate content. You can ensure that the child in your care is kept safe from such threats by using **content blockers**: expansions designed to **filter out specific types of websites and platforms**. However it is worth noting that this measure comes with the tradeoff of potentially “overblocking” innocent content that has been mistakenly or unnecessarily flagged as inappropriate.

### More privacy best-practices measures that are also still relevant

While it is of great importance that we use programs, apps, and extensions designed to ensure the highest possible protection of our devices, we must **not underestimate the power of teaching privacy and online-safety best practices** either. Those practices seem traditional, as they have been around since the dawn of the digital age, but are still valid to raise awareness regarding issues that can (not yet) be solved technologically. **These include, for example:**

- Advising the child to utilize a username that does not contain personal information (such as real name or birth year) to hinder attempts of identity theft. Alternatively, using “throwaway” email addresses is also an option.
- Teaching them to cover or unplug their webcams when they are not in use
- Show them how to keep their digital profiles limited for viewing and messaging to decrease phishing attempts
- Tell them to share only minimal information online and never to share their phone number  or address with anyone that does not have a valid reason to obtain this information.
- Explain to your children the value of using different passwords (if required) for each account to reduce the impact, if a certain account was breached.

## Knowledge is power

While it is essential that we, as “wise” and responsible adults, do our best to keep the children safe, admittedly, we do not possess the superpower of having our eyes everywhere: Therefore, it is equally important to **show the youngsters how they can look out for themselves** and use the internet safely without supervision. The first step in achieving this goal is to **talk to kids honestly about the risks** that the possession of an online presence can contain - of course, using age-appropriate language. The intention behind this conversation is, therefore, **not to scare them but instead, to teach them that they have the power to protect themselves** by knowing how to recognize suspicious situations. With this skill acquired, children can continue enjoying their favorite online activities and exploring their independence while simultaneously keeping the learned safety measures in the back of their minds.


Given a child's natural innocence, they might not expect an ill-wisher on their favourite online platform. This article discusses the new digital threats kids are subjected to and what adults can do to keep them safe.

Children and Online Security: Protecting the Most Vulnerable


Perhaps no other emerging technological advancements have shaped our society as rapidly as the phenomenon of digitalization. With the possibility of reaching people from around the globe, it is evident that the cyber-world also functions as a globalized melting pot of businesses: Practicing e-commerce allows companies to **heavily expand their customer base, thus going from a local organization to a worldwide supplier**.

A common misconception about digitalization and cloud storage services is that the saved information is just floating around in the cyber-world, independently of physical borders. In reality, however, **the storage, security, and managing of your data is the responsibility of so-called data centers**, housing businesses’ data at nearly 8000 worldwide locations.

Unfortunately, having your crucial data stored at a specific location alone does not automatically equal guaranteed protection: Due to such a large number of data centers, it is no surprise that not all of them are equally capable of fulfilling your organization-specific data-management needs. Therefore, when choosing a region of residency, you must make sure your location of choice **provides an optimal web environment based on your business's requirements and circumstances** and has the potential to **reach your entire audience**. This article will explain the role of data residency and centers in greater detail and list the factors you might want to consider when choosing a center region.

## All about data regionality and centers

AAs the name suggests, data residency describes **in which country or region an organization's data is stored and processed**. With the help of infrastructure providers offering various data regions, organizations using Software as a Service (SaaS) or other cloud deployment services can **store their data in multiple locations**, thus benefiting their teams with **seamless collaboration and their global users with high performance in any country**. Once you have chosen a region (for example, Switzerland), **all your data traffic is sent to a dedicated data center** to ensure it is managed in the selected location.

Since the ability to select data regionality has not been a deciding factor when choosing a service provider for many organizations, numerous contracts are signed for a pre-determined term. Unfortunately, this decision is often made unknowingly of the fact that the selected data regionality can have a significant impact on the fate of businesses: As the lifeblood of the modern global economy, data must be **handled by the right hands to avoid potential breaches, legal and data protection issues, or their complete loss**.

But what is precisely the problem with keeping the default regionality if universally trusted? Absolutely nothing, provided you have reviewed the region and found it fits your organization's needs and circumstances. However, **when it comes to data processing, there is no "one size fits all"**; different businesses tend to have their main customer base, offices, and headquarters at distinct locations. Accordingly, should the default data region be in Australia, whereas the majority of your platform's users are located in the US, they might struggle with high latency, making the quality of service suffer in the process.

**To sum it up, the benefits of choosing the fitting data residency include:**

- Improving the performance and flexibility of your cloud-deployed application/site wherever your customers are located
- Compliance with ever more stringent global and regional data protection regulations
- Seamless collaboration with employees working abroad and enhanced workforce mobility
- Better availability and disaster recovery options
- Facilitated access to public cloud operators

## Choosing the right data region for your company

Now that it has been elaborated upon why choosing the right data region is crucial, it is worth discussing what factors should be considered when making the decision in question. In addition to location and security, the compliance and availabilty of a future technology partner should be carefully evaluated.

### 1. Location

One of the most significant elements to consider when picking a data region is the physical location. Since the geographical position of a data center directly impacts **several other vital factors in the colocation process**, it is worth carefully looking into the attributes of the available regionalities. If your service provider offers a variety of possibilities covering several continents, the key is to **look at traffic patterns on your network to determine high-demand areas** that could benefit from more coverage. For example, if most of your customers or users reside in western Europe, choosing that data region would ensure low latency for your primary audience when using your platform. This proximity to your platform's users, alias the most common locations from which it is accessed, can be retrieved from various analytical tools, such as Google Analytics.

Another location-related attribute you might want to consider is your **business's residence(es)**; should your IT team need to examine the center or perform maintenance or updates in person, it is advised that it is located within an easily reachable distance.
Obviously this depends on your business's delivery model and the increasingly rare occasions, e.g. in highly regulated or sensitive industries, where businesses operate their own infrastructure.  
Furthermore, **your staff will benefit from low latency** if their data is stored and processed close to their office.

### 2. Security

Another crucial factor when choosing data residency is the **strength of the center's security system**. For an institution responsible for handling all your company's data and apps, a **breach might prove disastrous**. This fact is especially noteworthy since data centers are still a prime target for cybercriminals. For example, in 2019, six of [CyrusOne's](https://www.zdnet.com/article/ransomware-attack-hits-major-us-data-center-provider/) managed service clients, primarily located in their New York data center, have **suffered availability concerns due to a ransomware program encrypting specific devices** in their network. Therefore, it is strongly advised that the centers of choice use the latest security features and protection software.

Furthermore, besides using high-profile Software and technology to safeguard your assets, data centers should have **robust overall security**. Adequate protective equipment of both virtual and physical nature will not only keep your data safe from cybercriminals but also real-life ones.

### 3. Availability

Within the field of data centers, **availability is measured by the host's uptime**: The percentage of time your platform is up and running, alias functional. According to [Hostingadvice](<https://www.hostingadvice.com/how-to/uptime-guarantees/#:~:text=It's%20generally%20understood%20that%2099.9,and%20up)%20is%20the%20ideal.>), **99.9% uptime is a hosting industry standard**, whereas five nines or better (99.999% and up) is the ideal.
The required redundancy to guarantee the availability of a single location is typically achieved by running three physically separated data centers within the same region.

In the case of a **multi-region** application, such as ZITADEL, your data is **automatically protected against a region-failure**, regardless of the specific residency you have chosen. Accordingly, should your region of choice suffer from complications, traffic will be redirected to other locations (if permitted by the user's data location preference). This degree of redundancy is however not available within single region and single availability zone applications.

### 4. Compliance

Data compliance refers to the process of adhering to numerous requirements and standards to **ensure the integrity and availability of regulated data and sensitive data**, thus protecting them from unauthorized use. There are a plethora of industry-specific and location-specific standards governing data security and privacy; one of the most well-known ones is the European Union's General Data Protection Regulation (GDPR), which **specifies how businesses should handle the personal data of any of their customers** who reside in the European Union. Accordingly, every organization with customers in the European Union is subject to GDPR, with severe consequences of non-compliance that can put your company's long-term viability in peril.
Moreover, not only the location of the data center, but also the residency of the infrastructure provider needs to be considered for data compliance.

### 5. Cost

The **cost for storage and compute can vary greatly between different regions** and countries.
Some regions for cloud storage might be up to 75% more costly than other regions due to various factors that drive the cost to operate and maintain the required level of service and security within that that region.
Balancing the previous mentioned factors with the cost of operating in a specific region is a key challenge for companies.

## New: Data redirection based on your customers' locations

At ZITADEL, we firmly believe that **a fitting data residence should be an asset and not a liability**. The SaaS (public cloud service) solution of our identity and access management platform pledges provides the highest possible protection of our user's data; this includes supplying housing options that are true to our security and performance standards.

As of Version 2, ZITADEL will start by offering **three data regionality options** to choose from:

- Switzerland
- Global
- GDPR-compliant regions

These options, however, include more than what meets the eye. To facilitate our customers' decision in choosing the right data center, our "Global" and "GDPR-compliant" options **automatically select three housing regions based on the locality of end-users**. In the case of the former option, this can include any country that fulfills ZITADEL's privacy requirements, while the latter works in a near-identical fashion, with the region pool only including [GDPR-compliant regions](https://reciprocity.com/resources/what-countries-are-covered-by-gdpr/#:~:text=The%20GDPR%20covers%20all%20the,Slovenia%2C%20Spain%2C%20and%20Sweden.).

Not only does the automatic redirection of your data save you a tremendous amount of time and effort by not having to research the residence of your customers and the attributes of various regions, but it also **ensures that your data is housed by centers that fulfill all the location, security, availability, scalability, and compliance requirements** of your organization: With the help of ZITADEL's highly distributed and **redundant system** spanning across **multiple regions** (multi-regional), as well as the use of serverless containers, we can guarantee **fast and easy scaling** to accommodate even the highest burst traffic with a short scaling time.


This article explains the role of data residency and centers in greater detail and list the factors you might want to consider when choosing a center region.

The Ultimate Guide to Choosing the Right Data Residency


Even if you have not heard of magic links, the chances are that you have already encountered them when signing up for third-party applications or websites. Simple yet effective, this **passwordless method** is convenient for end-users to confirm their identity and easy for developers to implement: Instead of having to enter a password, **a simple click is all it takes to log you in**.

Given its foolproof infrastructure and widespread use, one might think it would be unnecessary to change a winning team. Scratching beneath the surface, however, it soon becomes evident that **this method also has limitations**. While **we strongly recommend implementing password-free authentication** for every organization, as a relatively old passwordless method among ever-changing digital innovations, **magic links might no longer be the most secure alternative** for this purpose.

With this article, we aim to determine whether magic links are still viable as an authentication method or if you are better off using newer passwordless alternatives.

![](/blog/2022-06-22-magic-links-01.gif)

## What are magic links? – The Origins

"Magic Links" describe a **passwordless authentication method** that allows users to log in by **clicking a one-time link mailed or messaged to them rather than using their password**. This link is automatically sent to the provided email address upon toggling a login request on the platform. This simple but innovative process of users authenticating themselves by merely clicking a button may seem magical to some, thus the name.

Though no official record of the first use of this method seems to exist, research suggests that their **concept dates to [the early 2010s](https://lea.verou.me/2010/08/automatic-login-via-notification-emails/).** In the following years, as the problem with passwords started to arise slowly, various platforms started implementing two-factor authentication: In addition to entering a password, **2FA provides a secondary layer of security** by requiring the user to verify their identity via a second (passwordless) factor. One of the most used secondary factors at the time was a code sent via SMS or email. [In 2014](https://hacks.mozilla.org/2014/10/passwordless-authentication-secure-simple-and-fast-to-deploy/) however, a revolutionary new method started gaining traction that promises the same **high-end security features like 2FA,** **but by only relying on a single factor: Passwordless**. Since biometric characteristics were not yet as widespread as they are now (partially due to the older smartphone models), the most straightforward and low-tech solution proved to be the implementation of one-time links – or, as we call them today, magic links. Thus, in the mid-2010s, various platforms started to experiment with passwordless, one of the most notable examples being [Medium](https://blog.medium.com/signing-in-to-medium-by-email-aacc21134fcd), which sparked a debate regarding the legitimacy of this newly discovered login method.

## How do they work?

Contrary to what the name implies, magic links are only seemingly magical – in reality, they **operate using code, tokens and hash functions**. Akin to any other login process, it starts with the user visiting the respective platform or application with the desire to access it through their profile. The platform requests the user's email address upon navigating to the login page. Immediately **following the email submission, a token is generated and the magic link is formed**, which is automatically sent to the address in question. By clicking on the link, the user enables the application to **receive the query at its endpoint**, and thus the authentication process is completed.

## The advantages

Considering their widespread use, it is no surprise that **magic links have significant advantages for developers and end-users alike**. While the strengths of passwordless over password usage have already been discussed in greater detail, this list will merely focus on the pros of magic links over alternative passwordless methods.

- **Easy and affordable implementation**: Due to magic links' near-identical functionality to password resets, implementing them is merely a matter of making a few slight modifications in code. Thus, you do not have to worry about extra costs either.
- **Not device-dependent**: Unlike biometrics, which generally require devices capable of scanning the users' physical characteristics (f.e. fingerprint or face), or hardware tokens that must be plugged into a specific port, sign-ups via magic links have no such resource demands. They are therefore viable on any device with an internet connection.
- **Familiarity**: Since this technology has been used for password resets for a long time, end-users are likely already familiar with the functionality of magic links. This familiarity makes for an easy and transparent sign-up and login process.

## The disadvantages

While they have many advantages, **magic links are also not without their shortcomings compared to other passwordless options**.

- **Email Security**: If you frequently use magic links to log in, it is vital to also keep an eye on the security system surrounding your email account: Should someone gain access to another user's inbox, they simultaneously receive the keys to logging into profiles that run on magic links. Therefore, a single cyber-attack on your email could lead to unwanted activity on many of your utilized virtual services.
- **Email Provider**: Apart from the measures you take to protect your email account from unwanted access, the reliability of your used service is also worth evaluating. Since logins via magic links are heavily reliant on the user receiving the link, it is essential that the provider actually manages to deliver the awaited email.
- **Less convenient than other alternatives:** Apart from security, magic links also fall short compared to other passwordless methods in terms of login convenience. While the process is faster than MFA, magic links still require the user to leave the login screen instead of alternatives like biometrics or physical tokens.

## In conclusion

To answer the notorious question this article has posed regarding the viability of magic links; the answer is unfortunately not black-and-white. While magic links might still be considered a **safer authentication method than using plain passwords**, they ultimately seem to pose **more security risks than other passwordless options**.

Most of this method's disadvantages correlate to the fact that magic links **rely on a third-party service to handle a significant part of the authentication process**. Accordingly, even if the developer has made no mistakes in implementing a magic link-based login system, complications could still arise on the email provider's end. Additionally, while authentication processes via biometrics or physical tokens are dependent on specific device resources, they still have the **advantage of being either non-replicable or more challenging for other people to access**.

To sum it up: If you have a device capable of **authentication via a biometric factor or a physical token**, you might want to gravitate towards those options for maximum login convenience and account security. Alternatively, magic links are **still a relatively safe option for a familiar and facile login process**. In that case, however, it is strongly advised to protect your email account via highly secure authentication factors, to avoid unwanted activity on a multitude of your utilized virtual services.

Join the [GitHub Discussion](https://github.com/zitadel/zitadel/discussions/2075) if you are interested about the state of magic links in ZITADEL. Today ZITADEL supports Passwordless with FIDO2/WebAuthN and support of the upcoming Passkeys, this should give your users a secure and convenient alternative to classic magic links. You can send an email with a link to pair and onboard a FIDO2 compatible device or request a QR code to pair and onboard a FIDO2 compatible device.


Are magic links are still viable as an authentication method or are you better off using newer passwordless alternatives?

Magic Links – Are they Actually Outdated?


In 2010, only two years after Facebook's social login launch, 250 million users and two million third-party websites started using this new login alternative. With the introduction of many contemporary social identities over the years, it is no surprise that more and more platforms are continuously expanding their supply of available authentication options. The popularity of the social-login method is evident, given its convenient and user-friendly nature: It saves its users valuable time by not requiring the completion of a registration form and also spares them the effort of remembering yet another password.

As an authentication platform with the goal of the best possible user experience, ZITADEL strives to eliminate login inconveniences by **heavily expanding the number of its Identity Providers**: Very soon, every user will be assured a comfortable login via their preferred social identity. Whereas, thus far, ZITADEL has exclusively supported OIDC-compliant providers, it will soon remove this restriction to provide a **broader range of options, such as Apple ID, Microsoft Live, Github, Gitlab, and Microsoft Tenants (AzureAD).**

Besides the obvious advantage of increased login convenience, social logins were also proven superior in **enhancing business growth**. To adequately explain this unexpected correlation, it is essential to know how social logins work and how they benefit end-users and companies alike.

## How do social logins work?

Though there are many different providers for social logins (such as Facebook, Google, or Twitter), they all provide authentication in a near-identical fashion.

For them to work, the user must follow these simple steps:

- Upon entering the application or website, the user can **choose his preferred social network provider** (for example, Facebook).
- The website or app sends a **login request to the selected provider** directly, or ZITADEL relais this request to the chosen identity provider.
- Once the social provider confirms the user's identity, the user will **get access to the application**, and the registration process is completed. The selected method can now be used to log in at any time.

![](/blog/2022-06-15-social-logins-01.png)

## The benefits of social logins 

Implementing social logins can heavily enhance the user experience of an application. Some of the most notable **benefits for end-users** include:

- **Easy sign-up and sign-in:** Logins via Apple ID, Microsoft Live, or other identity providers are simple and only involve clicking a few buttons. This method is more convenient for the user than filling out a long registration form and manually logging in.
- **Less password reliant:** We all must remember an overwhelming number of passwords. Using a social login means users don't have to create and keep track of even more credentials. Thus, failed login attempts will be heavily reduced, and users will be less hesitant to sign up.
- **Raise trust:** A social login on your page provides a recognizable and uniform login method. Users will feel more comfortable sharing their data with unknown pages via identity providers they already trust.
- **Better mobile experience:** Dealing with passwords and usernames on your smartphone can be frustrating. Social logins help to make the mobile experience more enjoyable.

Due to its many perks, it is no surprise that countless end-users prefer to confirm their identity via a social login option: According to a study by ["loginradius,"](https://www.loginradius.com/blog/identity/social-login-infographic/) 70.69% of people aged 18-25 prefer social login over the traditional registration form. Accordingly, this simplified login method **can significantly enhance business growth by helping companies increase the number of customers creating accounts, thus** expanding their potential customer base. Not only are Social Logins effective in gaining new users, but also in retaining the existing ones: As claimed by ["Janrain" and "Blue."](https://paperform.co/ebook/Industry-Research-Value-of-Social-Login-2013.pdf), **65% of consumers are more likely to return to a website that automatically welcomes them through social login**.

Apart from higher conversion rates, **social logins further help your company by:**

- **Reducing stress on Support Teams:** The support team will spend less time dealing with security alerts or password requests from failed login attempts by switching to passwordless with social login.
- **Increasing login verification:** Social Logins add a layer of verification to login attempts by requiring confirmation from the chosen identity provider. Accordingly, it is more resilient to spam or harmful logins.
- **Reducing bounce rates:** Customers are more likely to abandon a site if they must fill out the traditional long registration form. The bounce rate can be reduced by making social login a possibility.
- **Simplifying Checkout:** For e-commerce applications, the simplicity of social logins can heavily increase the checkout experience. Thus, enabling them can lead to fewer abandoned carts and more purchases.

## Social logins via ZITADEL

Since every user has a preference for social networks, it is crucial for authentication solutions, such as ZITADEL, to provide a **broad selection of social identity providers**. By introducing a heavily expanded selection of social login templates, ZITADEL allows your application's users to sign in or up with just a few clicks, using their preferred identity.

It is advised to integrate your applications with an identity management platform like ZITADEL, which **can broker to many different identity providers out-of-the-box** instead of integrating providers individually in your apps. When using a central identity broker, you don't need to worry about maintaining your code across different technology stacks, as well as you get the added benefit of a central audit log and user repository.

ZITADEL will support **seven identity providers** (Google, Apple ID, Microsoft Live, Github, Gitlab, and AzureAD) that users can **individually configure and enable**. To maximize the previously mentioned benefits of social logins, it is advised to set up more than just one sign-up option on your platform.

These formerly mentioned social login methods are included in ZITADEL's basic plan and are therefore **entirely free for all users**.

Furthermore, the software doesn't require you to fully integrate every login provider separately: As an **[identity broker](https://zitadel.com/features#brokering)**, ZITADEL acts as a **trusted intermediary service** c**onnecting your projects with different identity providers** so that you only have to link the external identity providers to it. This feature is especially beneficial since embedding numerous Identity Providers directly into your apps is complex to maintain, time-consuming to set up, and hinders single-sign-on of users.

## The Takeaway

Social logins provide benefits to both your organization and your users. It boosts conversions, reduces the stress on your support teams, and simplifies the checkout for e-commerce brands. By expanding the number of supported identity providers, ZITADEL will ensure that all your users can effortlessly sign up for your platform with their preferred social identity.

We would love to hear your input on [which social logins](https://github.com/zitadel/zitadel/issues/2998) we should integrate first.

Should you have questions regarding social logins or any related (or unrelated) topics, please contact us anytime on our ZITADEL Discord Server. Alternatively, you can reach us on our Twitter, Linkedin, Github pages, or our website.

Don't forget to give us a star over on GitHub if you like the project. Thank you for the support.


Besides their obvious advantage of increased login convenience, social logins were also proven superior in enhancing business growth. To explain this correlation, it is essential to know how social logins work and how they benefit end-users and companies alike.

Social Logins: The Unexpected Drivers of Business Growth


<div className="my-4">
  <YouTube videoId={"eEhQ24EEjuc"} containerClassName={"youtube-container"} />
</div>

## We did it! 🎉

We are thrilled to announce the successful closing of our seed funding round led by <a href="https://nexusvp.com/" target="_blank">Nexus Venture Partners</a>!

This is our first time raising money, and we are stoked to have a fantastic partner on board for the next part of our journey. The newly gained funding and expertise in open source product-led solutions will help us bring a much desired open source alternative to Auth0 to the market.

Big thanks to Nexus VP for the faith and trust in [our team](/team) and product.

We want to sincerely say thank you to all the **supporters**, **early adoperts**, and **valued customers** from the whole ZITADEL team!

![](/blog/2022-06-08-fundraising-nexus-01.jpg)

## Press Release

**ZITADEL secures $2.5M to enhance its developer-first, open-source identity management platform**

**St. Gallen, Switzerland - Jun 1, 2022 -** ZITADEL, innovator of a transformative identity management platform, announces $2.5M in seed funding led by Nexus Venture Partners. The funding will help ZITADEL provide developers with a much-needed open-source alternative for their identity management needs and evolve its solution, scale sales growth, and nurture the open-source community. The current market landscape consists of established but closed-source players, including Auth0, Okta, Firebase, AWS Cognito, and others.

ZITADEL’s founding vision was based on the creation of a streamlined, cloud-native identity management platform to speed time-to-market for software projects. Focused on the simplicity of integration, ready-to-use self-service features, a customizable and secure login with first-class support for passwordless authentication, and an API-first strategy, ZITADEL’s unique turnkey platform offers developers unprecedented flexibility.
Developers often spend countless hours creating, configuring, and operating complex authentication and authorization systems. ZITADEL, which is built mainly in the Go programming language, solves these problems with easy-to-use integrations in multiple languages and frameworks. This flexibility enables developers to utilize prebuilt features provided by ZITADEL to dramatically improve their productivity. In addition, ZITADEL’s capabilities address existing open-source projects which were not built for a cloud-native and serverless environment.

The ZITADEL team is working towards further enriching the solution’s enterprise-readiness. New capabilities include multi-tenancy, unlimited audit trails, improved ability to self-host, and support for serverless deployments, plus the potential to extend ZITADEL’s breadth with custom code created in WebAssembly. Combined with its cloud-native architecture, ZITADEL’s self-hosting capabilities allow privacy-focused customers to own and control their data by running a dedicated version. ZITADEL’s flexible model, with its span of smart efficiency enhancements, is already the go-to solution for numerous marquee enterprise customers.  
The generous free tier of ZITADEL’s cloud-hosted offering allows anybody to create a ZITADEL instance in under five minutes—without a credit card. In its ongoing commitment to deliver GDPR support to its customers, ZITADEL Cloud also provides the capability to define the country or geopolitical region in which to store their data.

“Amidst today's complex software projects, ZITADEL provides a turnkey solution that allows developers to get started easily with a secure login, user management, multi-factor authentication, social logins, authorization management, and great APIs. With ZITADEL, we provide an important component to improve the overall security of a project while reducing your time-to-market,” said ZITADEL Co-Founder and CEO, Florian Forster.
“We’re delighted to break new ground partnering with Florian and the ZITADEL team, our first-ever investment in a Swiss company. We believe the future of digital identities is passwordless. ZITADEL takes a developer-first, open-source approach to solving identity management. Its simple and easy-to-integrate building blocks help developers build secure authentication into their applications without requiring deep in-house expertise and resource commitment.” said Abhishek Sharma, Managing Director at Nexus Venture Partners. “ZITADEL is the latest addition to the Nexus family of over a dozen marquee commercial open-source companies,” added Sharma.

### About ZITADEL

ZITADEL is the modern open\* alternative for Auth0, Firebase Auth, and AWS Cognito, as well as Keycloak, built for the container and serverless era. It provides customers a wide range of out-of-the-box features, including secure login, self-service, OpenID Connect, OAuth2.x, SAML2, branding, Passwordless with FIDO2, OTP, U2F, and an unlimited audit trail to improve the life of developers and developers. With its legal incorporation in Switzerland, ZITADEL is in the unique position of providing its cloud services even to customers with the strictest GDPR requirements. For more information visit [https://zitadel.com](https://zitadel.com), follow <a href="https://twitter.com/zitadel" target="_blank">@zitadel on Twitter</a>, or star the repository <a href="https://github.com/zitadel/zitadel" target="_blank">on GitHub</a>.

### About Nexus Venture Partners

Nexus Venture Partners is an early-stage venture capital firm partnering with extraordinary entrepreneurs to help build product-first software companies. With $2 billion under management, Nexus operates as one team across the U.S. and India. The Nexus portfolio includes Apollo.io, Aryaka, Clover Health, Delhivery, Druva, FingerprintJS, Hasura, H2O.ai, Infra Market, Kaltura, MinIO, Observe.ai, Postman, Pubmatic, Quizizz, Rancher, Rapido, Sibros, TileDB, Turtlemint, Unacademy, WhitehatJr, and Zepto. For more information, visit <a href="https://nexusvp.com/" target="_blank">nexusvp.com</a> or follow <a href="https://twitter.com/NexusVP" target="_blank">@nexusvp</a> on Twitter.

Contact:  
Florian Forster  
florian@zitadel.com  
+41 43 215 27 44

## Press Coverage

- <a
    href="https://venturebeat.com/2022/06/07/zitadel-targets-developers-with-open-source-identity-management-platform/"
    target="_blank"
  >
    VentureBeat - June 7, 2022: Zitadel targets developers with open-source
    identity management platform
  </a>
- <a
    href="https://www.startupticker.ch/en/news/american-vc-invests-2-5m-in-swiss-cybersecurity-startup"
    target="_blank"
  >
    startupticker.ch - June 9, 2022: American VC invests $2.5M in Swiss
    cybersecurity startup
  </a>
- <a
    href="https://finance.yahoo.com/news/zitadel-secures-2-5m-enhance-094800684.html"
    target="_blank"
  >
    yahoo!finance - June 10, 2022: ZITADEL Secures $2.5M to Enhance its
    Developer-First, Open-Source Identity Management Platform
  </a>


ZITADEL, innovator of a transformative identity management platform, announces $2.5M in seed funding led by Nexus Venture Partners. The funding will help ZITADEL provide developers with a much-needed open-source alternative for their identity management needs and evolve its solution, scale sales growth, and nurture the open-source community.

ZITADEL secures $2.5M to enhance its developer-first, open-source identity management platform


IMO = In My Opinion is a blog format where a author reflects his own opinion

As the release of ZITADEL v2 comes closer, I was working on getting the DNSSEC setups ready for our new domains (besides zitadel.com there are more) and I did wonder how the DNSSEC adoption turns out today?

## DNSSEC reputation

I know that DNSSEC has an arguable reputation and [this Stack Exchange article](https://security.stackexchange.com/questions/21121/if-dnssec-is-so-useful-why-is-its-deployment-non-existent-for-top-domains#:~:text=%40JasperWallace%2C%20Google%20is%20implementing%20things,not%20being%20fast%2Fcheap%20enough.) sums it up nicely. Although I agree with a lot of the criticism, I also think that one point is over exaggerated. This being the risk of a government entity taking control over the keymaterial of a domain at the registrar level. “Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.”, cited from [this article](https://sockpuppet.org/blog/2015/01/15/against-dnssec/). While this holds true, it does not reflect the fact that even if the keys were managed in a different way that the control of the domain ultimately still resides with the Libyan government's registry. If we follow down this route of argumentation, the single risk we currently all take is the ICANNs control over the whole system. How ICANN counteracts this concern with public and transparent processes can be read in [this entertaining article](https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/) from cloudflare .

Leaving all this aside makes me still think that a second trust anchor to the TLS PKIs is not a bad thing to consider. By separating the keymaterial from TLS and DNS (let's not talk about DANE for now) from each other, brings the additional value of making it difficult (maybe more time consuming) for an attacker to compromise two separated organizations. The “price” to pay for this is reasonable and it provides some small security improvements.

With the additional rise of DNS over HTTP (DoH) and DNS over TLS (DoT), the security of DNS based attacks should improve over time.

## How we deploy DNSSEC

For quite a while we were running DNSSEC on our domains hosted with Cloudflare. But with the recent changes in our architecture we wanted to reduce the number of companies that process our traffic, this to reduce risks associated with GDPR. With that said we settled for Google's DNS (Cloud DNS) and registrar (Cloud Domains) because we already run many of our services with Google. If you are interested in what we are using from whom checkout [our trust page](/trust).

As a side note, running the DNS server with the same provider as the registrar and TLS CA conflicts with my statement above, where I argued that separating those parties might add to the security. But we think reducing the number of sub-processors and companies involved is worth this trade-off.

## Who else uses DNSSEC

Out of curiosity I wanted to quickly brush over some of the big providers out there and see if they deploy DNSSEC. Let's say the results are confusing, because there does not seem to be a clear pattern of who deploys DNSSEC.

### No DNSSEC deployed

- [Microsoft Login](https://dnssec-analyzer.verisignlabs.com/microsoftonline.com)
- [Microsoft](https://dnssec-analyzer.verisignlabs.com/microsoft.com)
- [Google](https://dnssec-analyzer.verisignlabs.com/google.com)
- [Auth0](https://dnssec-analyzer.verisignlabs.com/auth0.com)
- [Okta](https://dnssec-analyzer.verisignlabs.com/okta.com)

### DNSSEC deployed

- [Akamai](https://dnssec-analyzer.verisignlabs.com/akamai.com)
- [Cloudflare](https://dnssec-analyzer.verisignlabs.com/cloudflare.com)
- [Login.gov](https://dnssec-analyzer.verisignlabs.com/login.gov)
- [Swiss Government](https://dnssec-analyzer.verisignlabs.com/admin.ch)

## Discussion

It is interesting to see who did deploy DNSSEC and who didn't. I think some of the tested sites hold off on deploying DNSSEC because they fear a potential user impact on a large audience. Notwithstanding, I think for security oriented services like a login provider it does not exactly feel like a great way to not enable DNSSEC. We think each element we can use to protect our customers is worth looking into. To be honest DNSSEC is definitely not the silver bullet for DNS security but still it is a minor improvement.


As the release of ZITADEL v2 comes closer, I was working on getting the DNSSEC setups ready for our new domains and I did wonder how the DNSSEC adoption turns out today?

Blog.