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


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?

IMO - DNSSEC


Whether it is your social media profile, your favorite streaming service, or your work email, the usage of passwords is the most common way people access their virtual identities. However, in recent years, a **new alternative has been seeing traction in the web**: passwordless authentication. Although this method would have seemed like a supernatural concept a decade or two ago, today, it is commonly praised as **the future of authentication**: According to the technology research firm [Gartner](https://www.gartner.com/smarterwithgartner/embrace-a-passwordless-approach-to-improve-security), 60% of large and global enterprises and **90% of midsize enterprises will implement passwordless methods** in more than 50% of use cases by the end of 2022.

To grant an insight into the newly found popularity of passwordless, this article will explain its concept, describe its reason for existence and elaborate upon its advantages over regular passwords.

![](/blog/2022-05-25-passwordless-01.png)

## What is passwordless?

The term passwordless refers to authentication methods that **confirm a user's identity without entering a password**. Instead of relying soley on a knowledge factor, passwordless utilizes alternate authentication methods, ensuring a more convenient and secure way to access your virtual identities.

The most popular passwordless authentication methods include:

- **Possession factors**: An object, such as USB Devices (FIDO2-compliant keys), physical tokens, or your smartphone
- **Biometrics**: Physical traits (f.e. Fingerprint scanning or Face-ID) or other characteristics, such as voice recognition
- **Magic links**: A link sent to the entered email address
- **One-Time-Passwords**: A code sent via text message or an authentication app
- **Software Tokens**: A virtual possession factor granted by an authentication software

Which of these methods a platform implements, depends on their individual preferences: To ensure their users the possibility to authenticate themselves via their preferred factor, many applications **utilize multiple passwordless options**. Platforms akin to ZITADEL, which work with sensitive data, generally implement open standards such as FIDO2 that allow users to use at least one of the listed methods.

Not to be confused with passwordless is **[Multi-Factor Authentication (MFA)](https://zitadel.com/features#multifactor)**. While the latter commonly utilizes a **passwordless factor in addition to the regular username-password login** method, it is ultimately not the same as the complete omission of passwords as done by the passwordless approach. For example, an MFA-based system might request you to enter your password and then use Face-ID as a secondary authentication factor, whereas a passwordless-based system would solely rely on Face-ID to confirm your identity. Although both of these methods undoubtedly surpass traditional password-based logins in terms of security, **passwordless systems are less susceptible to phishing and cyber-attacks** due to their complete waiver of passwords. Moreover, **passwordless is less time-consuming and memory-reliant nature** generally makes for a more convenient user experience.

![](/blog/2022-05-25-passwordless-02.gif)

With this said, the existence of the passwordless authentication alternative might pose the obvious question: Why should it be used? To answer this question, it is worth looking into the issue it means to eliminate: the **increasing problems with passwords**.

## The problems with passwords

One of the most apparent reasons for the popularity of the passwordless alternative is the **increasing dissatisfaction with the traditional username-password login method**. 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.

Even when used in combination with Multi-Factor-Authentication, **passwords are more prone to phishing attacks**. This phenomenon occurs largely due to the fact that people tend to set a simple word or pattern as their passwords, since they are supposed to be easily recallable. Evidently, a complex combination of multi-case characters, numbers and symbols is harder for hackers to guess, but unfortunately, they are also harder for users to remember.

To protect their data from potential risks, numerous companies order their employees to change their passwords periodically. While on paper this measure might sound like an optimal solution to the password-problem, in practice however, it **increases the chance of the user losing track of them**. Moreover, people tend to use the same password for multiple virtual identities; accordingly, if a hacker should get a hold of your password, it would **grant them access to each profile that uses the same login credentials**.

Whether you buy into the passwordless journey or not, **always enable two-factor authentication** and use different passwords for each service. Use a password manager to ease the pain of multiple passwords and even creating and rotating new passwords.

## Benefits of passwordless

To **replace the previously mentioned risky password management practices**, a new alternative had to be developed that does not tie the authentication process to a singular phrase: Thus, the passwordless method came into existence. Standards such as FIDO2 entirely rely on **public-private key exchange between a user's device and the server** that authenticates the user, thus passwordless not only **eliminates the inconvenient practice of remembering complicated passwords** but also ensures **highly secure access** to all your virtual identities. Moreover, switching to passwordless is highly beneficial for the users of an application and its developers: Due to the high cost of managing and maintaining passwords, the alternative generally poses a **lower total cost of ownership (TCO)**. While the implementation of passwordless might seem expensive at first glance, its price does not even come close to the **fines and losses incurred due to a cyber-attack**.

The most significant benefits of using passwordless authentication instead of passwords:

- **Security**: Highly reduced risk of cyber-attacks
- **UX**: Higher customer satisfaction due to its convenience
- **Cheaper TCO**: No need to invest in maintaining passwords
- **More Sign-ups**: Not having to create a new password makes the registration process smoother, thus increasing customer satisfaction and sign-up rates

## Why should a PIN be more secure than a password?

When using passwordless, users are generally prompted for a gesture such as FaceID, Fingerprint, or even just a PIN. At first glance, it might seem illogical how this method should be more secure than multi-factor authentication. The vital difference is that **this gesture only unlocks a software or hardware-based “vault”** where the keys are stored for authenticating. The personal credentials, such as biometrics or the PIN, itself were **not shared across the network or even across devices**.

Drawback of this method is that each device has to be enrolled individually in the service. For most users, this is confusing and creates additional friction in onboarding and managing users. However, [according to the FIDO alliance](https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/), this issue will be solved with **multi-device credentials, known as “passkeys”**, within the current year.

## ZITADEL and passwordless

As an identity and access management platform, ZITADEL holds the security of its customers and their end-users to the highest value: Accordingly, to **replace security threats with highly modern login convenience**, the inclusion of passwordless methods is indispensable. ZITADEL offers a wide variety of **passwordless authentication options via FIDO2** for logging into its console itself and for the login form of the customer's application: They can use their **fingerprint, security key, or any other [WebAuthN compatible](https://webauthn.guide/) authentication method to log in**. Regardless of which approach the user chooses, ZITADEL's passwordless authentication **protects them effectively against data breaches**, thus eliminating a significant attack vector.


To grant an insight into the newly found popularity of passwordless, this article will explain its concept, describe its reason for existence and elaborate upon its advantages over regular passwords.

Why You should Switch to Passwordless Authentication


In the 21st century, a significant share of our conversations is held virtually, via text messages. Not only does this fact apply to interpersonal conversations between acquaintances or friends, but also service-related negotiations such as parcel deliveries, newsletter subscriptions, or even payment requests. Due to the normalization of these sorts of messages, people tend to be less hesitant when clicking on links that come from a seemingly trusted sender. A serious problem arises, however, when the attached URL redirects you to a malicious site. In this article, I will discuss the phenomenon of smishing and how to protect yourself from falling victim to it.

## What is smishing?

The word “smishing” is derived from a combination of “SMS” and “phishing”. “Phishing” describes the phenomenon of being deceived into giving sensitive information to a disguised cybercriminal and “SMS” indicates that the deception is carried out via text messaging. Smishing is therefore essentially a newer breed of the infamous spam emails, however, due to the perceived intimacy of a personal text message, SMS scams have a higher chance of going unnoticed.

To further take advantage of your confidence in text message safety, attackers tend to assume the identity of well-known companies people are used to receiving legitimate messages from, such as DHL, Netflix, or Apple. Smishing text messages usually depict a situation 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. The ultimate “goal” of smishing is to trick unsuspecting people into giving away their personal or financial information. In many cases, simply 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 your phone.

![](/blog/2022-05-11-smishing-01.png)

## The most common threats of smishing texts

Based on what we already know about this phenomenon, smishing is more than a simple prank-SMS. What some people do not realize, however, is how severe the risk of clicking a simple URL can be. Most commonly, the attacker will exploit the acquired data for one or more of the following purposes:

### 1. Stolen money

The most obvious reason a criminal would want to access your online information is to defraud you out of money: The attached link is therefore often used to intercept a one-time passcode (OTP) most banks use for step-up authentication. Alternatively, they might simply send their unsuspecting victims a warning about an unpaid bill in favor of a fake recipient. Sadly, many attackers found success in this “business”: [The median of the loss reported by complainants was $800.](https://www.aarp.org/money/scams-fraud/info-2020/smishing.html)

### 2. Identity Theft

Theft does not exclusively happen to tangible objects; it can also happen to a person’s entire identity. Some scammers use the accessed data to claim the identity of their victim, for various diverging causes apart from stealing money, such as filing phony health insurance claims, committing tax fraud, or even reselling your data to other criminals.

### 3. Installed Viruses

Another threat smishing poses is the installment of unsolicited malware. The message might encourage you to download a seemingly trusted app, which could be used to collect sensitive data from your phone, such as credit card details stored in other apps. Additionally, a phone infected with malware or viruses can become completely unusable.

### Pegasus: A real life smishing example

To showcase just how dangerous the consequences of smishing can be, we are taking a look at the real-life example of the “pegasus incident”. Pegasus is a spyware that can be installed on any kind of smartphone device, intending to harvest its data from apps. While the software was intended to be used to investigate potential terrorists and criminals, multiple cases of its misuse to surveil anti-regime activists, journalists, and political leaders have been reported.

As software capable of zero-click exploit, Pegasus requires no user interaction to operate: As an example, the spyware could be covertly installed on the phone of a [technology lead at Polygon](https://citizenlab.ca/2022/04/catalangate-extensive-mercenary-spyware-operation-against-catalans-using-pegasus-candiru/), by taking advantage of a previously unknown security vulnerability in Apple’s iMessage. The Pegasus infection link was disguised as a boarding pass link for a Swiss International Air Lines flight the victim had purchased. As a result of a simple click on the URL, the spyware was granted unlimited access to every information stored on the iPhone.

![](/blog/2022-05-11-smishing-02.png)

While this incident of a fraudulent boarding pass link would likely fly under the radar for many, luckily, more **amateurish smishing attempts targeted at civilians are easier to identify**. In the next chapter, we discuss some common signs of a potential smishing attempt.

## Signs that you are getting “Smished”

To protect yourself from smishing, it is essential to be able to recognize the threat coming your way. Luckily, there are some signs to look out for, when receiving a suspicious text message. If the text is guilty of at least one of these common signs of smishing, that is a warning signal that you need to take measures to protect yourself:

- The message is asking you to click on an URL with a domain that does not correspond to the company name. Furthermore, shortened URLs (f.e. starting with bit.ly, cutt.ly, and shorturl.at) are generally not trustworthy in the context of 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 of the sender and that of 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 have their company names displayed instead of their numbers.

![](/blog/2022-05-11-smishing-03.png)

## How can you protect yourself?

Whether you already received an illegitimate message or not, smishing can happen to everyone. However, there are plenty of measures you can take to protect your data; if you have received a suspicious message, keep these simple tips in mind to avoid falling prey to text message fraud:

- Do not open the attached link
- Replying or calling them is counterproductive – Doing so confirms that your number is in use, making you a potential target for more attacks
- Never share any of your data (passwords, address, etc.) via text
- Limit sharing your phone number on social media to decrease the number of potential scammers getting their hands on it
- Block the number and/or report the scammer to your country’s Trade or Communications Commission or the police
- When in doubt, ask the service to confirm the delivery of the message in question. However, make sure to do so via the contact information you can find on their official website; do not call the number that sent the message.
- Enable [Multifactor Authentication](/features#multifactor) to prevent unwanted logins to your account.


What if a text message you received is not what it seems?  This article discusses the phenomenon of smishing and how to protect yourself from falling victim to it.

Smishing - How to Recognize Dangerous Text Messages


One of the most common tasks when developing a software is establishing an authentication and identity management system. Whether that system only consists of a sign-up form and a login page or a more complex infrastructure, **the number one priority should always be a** **seamless functionality**: Errors in the implementation can have **catastrophic consequences**. To assure that your software is secure and working as intended, your **identity management system should be implemented and managed by experts** with in-depth knowledge on the topic.

Companies on the lookout for an authentication server have the possibility to **buy functionality from third-party identity and access management (IAM) solutions**, such as ZITADEL. Most of these vendors consist of highly qualified IT-experts who are universally entrusted to **guarantee a safe and error-free IAM system** for software products. Despite a large supply of these purchasable solutions, some firms still choose to build their own authentication server in hopes of saving money or due to distrust in pre-built applications. While a **self-developed solution** might work for some, there are various **potentially unknown drawbacks** that companies should consider before settling for this method. In this article, I will discuss the risks and disadvantages of building your own authentication server.

## Common shortcomings of self-built Authentication Servers

### 1. Security Issues

The most significant risk of building your own authentication server lies in its generally **higher probability of security issues**. Since keeping your users’ data safe is among the greatest responsibilities of a platform and the primary task of an IAM server, it is essential to make sure an adequately established security system is a given. One of the most obvious advantages IAM vendors have over DIY developers is the possession of a **dedicated team with IT and engineering expertise**. The members of these teams can utilize their knowledge to create the **best possible security system** based on their diverse experiences. Additionally, IAM vendors commonly offer **advanced security features**, such as support for multi-factor authentication (MFA) and security keys. Another security aspect where third-party IAM solutions prevail is **error prevention**: They can **prevent attacks more easily due to their large user base**, whereas a custom-made solution does not possess enough data to recognize suspicious patterns.

### 2. Not as cheap as you think

Contrary to popular belief, you will likely find that **building your own authentication server is not cheaper in the long run**. While you initially save some money by not having to purchase the solution itself, it will quickly be **compensated by the cost of development, maintenance, troubleshooting, upgrades, and the resources** themselves that are needed for these procedures. It is also worth noting, that since your main product is likely in an unrelated field to the IAM itself, the inevitable **shift in your working context would entail additional costs**. When considering a handcrafted solution, it is therefore beneficial to evaluate if the needed investments over the lifetime of your product are ultimately less than the amount you would have to pay for the one-time fee of the purchasable alternative.

### 3. Complex and Time-consuming

When creating anything from scratch, you should probably reckon with a lengthy production process. The same principle applies to developing a server; given that authentication solutions **require lots of API programming and complex security features**, fully building one might take at least a year as a full-time job. Since the server will handle sensitive data, the development of an adequately functioning security system also involves **constant testing and optimizing**, which should not be neglected to save time. The need for handcrafted features also extends to the product phases beyond the initial development: Keeping your application functional and up to date requires you to **additionally establish a maintenance system** that will serve this purpose. Purchasing an already established IAM solution would therefore likely **save you several years of time, and money spent on essential resources**.

## What you can do instead

In conclusion, even if you are an experienced programmer or your company possesses a dedicated IT-team, you will likely find that **your time and effort will be better spent developing and optimizing your main product**. Afterall, facilitating the job of software developers by not having to worry about building a dedicated authentication server on top of programming every other aspect of their application is the primary reason third-party IAM solutions exist. **Buying functionally is therefore our clear recommendation if you strive for maximized security and wish to save time and money**.

Should you be worried about being restricted by the ready-to-use features of a third-party IAM platform, **ZITADEL customers** have the possibility to choose a **self-hosted deployment option**. While this method still requires more resources compared to the software as a service alternative, it allows you to have full control over your authentication system without having to create a whole server from scratch.

## The Takeaway

If you wish to receive a pre-established IAM solution instead of having to handcraft it yourself, **ZITADEL ensures** **the best possible authentication server** with its flexible pricing options, diverse deployment options, generous range of features, guaranteed high security and unlimited identities for all instances.

Should you have questions regarding authentication servers or any other related (or unrelated) topics, 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).

If you like the project, don't forget to [give us a star over on GitHub](https://github.com/zitadel/zitadel/stargazers). Thanks for the support.


Despite a large supply of purchasable solutions, some firms choose to build their own authentication server. While this solution might work for some, there are various potentially unknown drawbacks that you should consider before settling for this method.

The Truth About Building Your Own Authentication Server


## Definition of serverless

When people talk about serverless it is oftentimes not clear what they mean exactly. So let&apos;s begin with shining a light on what we think of when we talk about serverless.

For us, serverless is the possibility to run ZITADEL without the need to manage the underlying computing, networking and storage.

From our perspective there are two options we would classify as serverless: Firstly, function as a service (FaaS) offerings and secondly container as a service (CaaS) or you can call the latter serverless containers. Some serverless containers are run on top of managed Kubernetes offerings with the help of Knative.

## Why we think serverless is a thing

Since our early days we committed ourselves to containers and Kubernetes to run and deploy ZITADEL. Be it with customers or our public cloud offering. In the last few months three points, which needed to be addressed, did come to our attention because we asked ourselves how we could reduce our operation expenses while still being able to scale.

### Easier global scaling

As mentioned earlier, we run ZITADEL distributed across the globe to give our customers the best latency available. But with the rising need for new points of presence, we experienced that the management (updating, scaling, …) of multiple Kubernetes clusters gets quite annoying. Not even taking into account that we also needed to deploy our observability toolings and ZITADEL at scale as well.

### Easier deployment for developers

Many of our users did ask us, if it is possible to run ZITADEL without Kubernetes, especially for small deployments or developers who want to run ZITADEL locally.
We totally understand that it is not feasible for many people to operate Kubernetes. Even with platforms like Ranchers k3s and kubeadm, alongside the hyperscalers offerings from Google&apos;s GKE over Amazon&apos;s EKS to Microsoft's AKS.

### Kubernetes compatibility

While we want to provide alternatives to Kubernetes usage we still want our customers to have the option of running ZITADEL on their existing clusters.

With those three points in mind we set off to create a solution that can improve the way somebody can run and scale ZITADEL to new heights.

## How we are (working on) harnessing serverless

Although we are not yet running our production with a serverless service, we have been testing one for many months with our internal environments. We chose to thoroughly test Google's serverless containers offering which is compatible with Knative which is called “Google Cloud Run”. This, because it allowed us to address all of the three goals which triggered this journey.

**Scaling**: We can deploy ZITADEL across the globe (> 26 Regions) with a few lines of Terraform within mere minutes

**Deployment**: We can run a dedicated ZITADEL with little fixed cost with “Google Cloud Run” and “CockroachDB Cloud serverless” offering

**Compatibility**: While being fully serverless, ZITADEL still stays completely compatible with Kubernetes

Customers that wish to self-host ZITADEL can either choose to leverage the Google Cloud Run setup, as we use it in our cloud service, or use any of the alternatives, namely running on any CNCF-compliant Kubernetes or even as binary.

## The challenges

To make ZITADEL run great on serverless offerings we needed to address some challenges.

**Scheduled Tasks:** Some of the processes of an IAM happen on a scheduled basis and we need a way to address this without relying on an external system. So as of today we recommend keeping at least one instance of ZITADEL running. With Cloud Run this can be easily solved by setting the “minimal instance” property to something like > 0.

**Async Tasks:** When ZITADEL is invoked some of the requests are run asynchronously. To cater for this it makes sense to tell the serverless platform to allow CPU usage after a request finished. With Cloud Run you can enable “always-on” CPU allocation. This allows ZITADEL to finish certain tasks. For example writing traces, calculating read models and so on.

## The gains

**Observability:** Although not serverless specific, the integration of Cloud Run in Google's observability stack is impressive. For example out of the box opentracing works and provides the traces from the load balancer towards ZITADEL.

**Scaling:** Cloud Run allows you to scale horizontally (more containers) and/or vertical (more CPU/Memory) in combination with the cloud load balancer it even allows to create multiple deployments in parallel to even further scale either inside or across multiple regions.

**Worldwide:** As already mentioned with a few lines of Terraform it is possible to run ZITADEL across multiple regions with ease. All of this without the need to manage the deployment target.

**Testing:** Cloud Run already allows A/B testing where a percentage of requests are steered towards a newer version. While this is useful we use this feature in conjunction with the load balancers capabilities to route certain domains to a specific release.

**Cost:** Even though ZITADEL is configured to be always running with at least one container, Cloud Run makes for a cost effective solution. This is because the initial cost of running a new datacenter is relatively low (less than $60 per region).

## What will improve with ZITADEL v2

As you might be aware, [we are currently working on a major update of ZITADEL](/blog/six-ways-zitadel-will-improve-2022). Some of that work is specifically geared towards improving ZITADEL for serverless containers as well as the option to run it locally without any containers as self-contained binary.

With the release of v2 we will add support for the following features:

- Serverless Deployment to Google Cloud Run
- Support for [CockroachDB serverless](https://www.cockroachlabs.com/get-started-cockroachdb/) DB

To improve the life of developers who want to run a local ZITADEL we also release the following improvements

- Self-Contained Binary so that ZITADEL works without running in a container
- Additional CPU Architectures (ARM64)
- Additional OS support (MacOS, Windows)

## When is v2 due to release

The initial release of v2 is just around the corner and is aimed towards the end of April - early May.

If you are interested in participating in our early adopter program and the new pricing, [please send us a message](/contact).

## What&apos;s next

We will soon publish the new pricing and some more blogs and information about the v2 of ZITADEL on our website that we will also link in this section. So stay tuned.

If you want to catch us live you will find us at the following events in the near future:

- [Swiss Cyber Security Days](https://swisscybersecuritydays.ch/), April 6./7. 2022, Fribourg, Switzerland
- [Deutscher Startup Pokal](https://www.eventbrite.de/e/deutscher-startup-pokal-digitales-2-halbfinale-security-tickets-164279774227), April 7. 2022, Online
- [Cloud Native Computing Switzerland](https://www.meetup.com/Cloud-Native-Computing-Switzerland/events/279925165/), May 12 2022, Zurich, Switzerland

Of course if you want to get in touch, feel free to [contact us](/contact) or join [our chat](/chat).


With the rise of serverless and our need to scale, we wanted to explore the possibilities and values that modern serverless platform provides.

A serverless future

With the **introduction of the authentication standard SAML 2.0** coming soon to ZITADEL, you will be granted the possibility to choose between the **two most trusted identity protocols**: The previously implemented “OpenID Connect (OIDC)” and the new addition “Security Access Markup Language (SAML)”.

To help you determine which protocol is best suited for your use case, this article carefully explains the similarities and key differences between the two standards and what they each have to offer.

## Similarities

Both SAML and OIDC provide a **means of authentication**: They are responsible for **securely transmitting user information** between the system that is doing the authentication (the Identity Provider) and the service or application the user is attempting to access. Both standards offer centralized authentication, also called **single sign-on (SSO)**, which allows the user to **access multiple applications using a single login credential** (username, password, token etc.). This process helps users to spare the time they would spend registering to multiple apps one-at-a-time, by maintaining a centralized database. A notable example of a SSO solution is Google: Using a single account, it is possible to access a wide variety of applications, such as _Gmail_, _Youtube_ and _Google Drive_.

## Differences

After having inspected what the two standards have in common, it is important to examine the characteristics that set them apart. While the key goal of SAML 2.0 and OIDC is identical, the **approach used to authenticate users differs in method and technology**.

Given the notable age difference between the protocols, the younger standard (OIDC) was developed with scalability and a simpler implementation in mind, to meet the expectations of today’s users, whereas SAML had more time to effectively establish a wider range of security features. To help us illustrate the main dissimilarities between the two standards more clearly, we have created the **following table that provides an overview of these differences**:

<table>
 <tr>
 <th>&nbsp;</th>
 <th>SAML2.0</th>
 <th>OIDC</th>
 </tr>
 <tr>
 <td>
 Security
 </td>
 <td>
 More trusted due to its exceptionally high security level, however even
 the basic security-features need to be implemented individually.
 </td>
 <td>
 A newer protocol, which is actively being improved based on new threat
 vectors. Easier to adhere to 'best practice' code flows.
 </td>
 </tr>
 <tr>
 <td>
 Implementation
 </td>
 <td>
 Generally complex to implement and maintain; not recommended for mobile
 applications.
 </td>
 <td>
 Very simple to implement and commonly used for mobile applications and
 single-page apps.
 </td>
 </tr>
 <tr>
 <td>
 Message format
 </td>
 <td>
 Sends heavy-weight XML messages for authentication via SOAP, a protocol
 layer on HTTP.
 </td>
 <td>
 Passes light-weight JSON Web Tokens (JWT) or opaque tokens via RESTful API
 communication to exchange authentication information.
 </td>
 </tr>
 <tr>
 <td>
 User consent
 </td>
 <td>
 Consent flow requires hard-coding and is therefore not a built-in part of
 the protocol.
 </td>
 <td>
 Offers a built-in layer of authorization (consent flow) that asks a user
 to consent to what the service provider might access.
 </td>
 </tr>
 <tr>
 <td>
 Authentication process / Connectivity
 </td>
 <td>
 To provide authentication, IdP and the relying party must be configured to
 know each other
 </td>
 <td>
 IdP and the relying party don’t have to identify each other; faster and
 more resource-friendly
 </td>
 </tr>
 <tr>
 <td>&nbsp;</td>
 <td>&nbsp;</td>
 <td>&nbsp;</td>
 </tr>
 <tr>
 <td>
 Biggest Strengths
 </td>
 <td>
 Can offer the highest possible security, as there is a lot of customizable
 functionality, but only as long as the implementation covers certain
 security threads.
 </td>
 <td>
 User-friendliness, interoperable with SPA and mobile applications, ongoing
 maintenance of the standard.
 </td>
 </tr>
 <tr>
 <td>
 Biggest Weaknesses
 </td>
 <td>
 Lengthy and complex implementation and maintenance of each feature
 one-by-one: higher risk of errors and malfunction.
 </td>
 <td>
 Offers less features than SAML (f.e. dynamic specification of proxy IdPs
 is not fully supported).
 </td>
 </tr>
 <tr>
 <td>
 Commonly used by:
 </td>
 <td>
 Enterprise- and government-scale activities working with sensitive data.
 </td>
 <td>
 Businesses highly prioritizing performance-friendliness and an additional
 implementation in mobile-applications.
 </td>
 </tr>
</table>

## Which tool is best for you?

In conclusion, **none of the two standards can be classified as the objectively better option**: Ultimately, both will serve their main purpose of authentication in a safe and secure manner and are therefore **equally well suited for traditional Web Applications**. However, they do have their own respective advantages and disadvantages, which usually makes one of them the more practical choice depending on the specific usage context. To make a calculated choice on whether you should implement SAML or OIDC, it is essential to **evaluate the core values, preferences, and the target audience of your organization**. Accordingly, the final decision is only yours to make.

Given the previously mentioned differences between the standards, we can however give you some **recommendations on the use cases** for SAML and OIDC respectively:

- OIDC is probably the better choice if you do not want to invest in learning XML, or you need to work with Mobile- or SPA-type Applications or REST APIs. Also for green-field projects OIDC is typically the better pick between the two.
- If your application already has tools and libraries supporting SAML, then it is advised to continue with. SAML is also recommended if your business deals with sensitive data and requires the highest possible security.
- Should you be completely torn between the two standards, our general recommendation is to go with OIDC; due to its user-friendliness and easy implementation you will likely find it easier to pick up and maintain.

If you would like to enjoy the benefits of both standards to their fullest, you also have the possibility to adopt a **hybrid usage**: Since the two protocols serve the same purpose, but you’re not restricted to use the same protocol for all your applications, the best-used protocol can change for each of your organization’s applications.

In ZITADEL you can have both OIDC and SAML 2.0 applications within one project, sharing the same roles and user authentications. With token exchange between the two protocols, it will be **possible to use both seamlessly for federated authentication across different client types**.

## How to proceed

Should you have questions regarding SAML and OIDC or any other related (or unrelated) topics, 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](/contact).

Did you know that ZITADEL is OpenID Connect certified? [Read more](/blog/openid-connect-certification).

**SAML 2.0 will be available on ZITADEL starting at the end of March 2022.** Visit [zitadel.com/roadmap](https://zitadel.com/roadmap) for more information.

To help you determine which protocol is best suited for your use case, this article carefully explains the similarities and key differences between the two standards and what they each have to offer.

SAML vs OIDC: Which Protocol is Best for Your Organization?


Access tokens, as the name suggests, are an essential part of Identity and Access Management (IAM) Services: They are used to grant access to client resources. Since they contain such sensitive data, access tokens must be kept confidential in transit and in storage; the respective application should therefore ensure that the token is not accessible to other apps on the same device.

Access tokens come in different formats, all of which have their respective uses. So far, ZITADEL has allowed **JSON Web Token (JWT) Profile** for authentication of Service Accounts. This month, we are expanding the possibilities of our platform by introducing **Personal Access Tokens (PAT)** that can be enabled along with an existing JWT profile.

In this Article, I will explain **why we have chosen to introduce PAT** in addition to JWT, **which audience this change will benefit** and **how PAT can be implemented** into the ZITADEL console.

As a first step, it is essential to know what JWT and PAT have to offer.

## JSON Web Tokens (JWT) and their application

JSON Web Token (JWT), is a compact and **self-contained** open standard used to **share security information between a client and a server** in a structured format (JSON). It is commonly used as an access token (for authorization and securing APIs) by specific protocols such as OAuth 2.0.

The use of access tokens is that they must be passed upon every request of an application to access routes, services, or resources (f.e. APIs) to confirm the user's authorization. Some solutions **might not support JWT Profile for Machine-to-Machine (M2M) communication**, although it is the preferred method to authenticate Service Accounts in terms of security.

## Personal Access Tokens (PAT) and why they are needed

Personal Access Tokens are **opaque tokens**, i.e. no information can be extracted from the token itself, that enable granular access to a specific resource. This procedure is generally useful for interrogation with 3rd-party systems that use the respective platform to store records, and don't want to proxy all the protected resources via their system. In the case of ZITADEL, PATs were implemented to **provide an alternative method of authentication for Service Accounts**.

Although not as secure as JWT Profile, PATs are helpful for service users that have **trouble integrating their Service Accounts with the preferred method**. If this type of problem arises, it is advised to enable PAT along with JWT Profile. The token will grant access to all rights assigned to the user (within ZITADEL itself (manager roles) or in other projects by user grants). You should always limit the lifespan of a PAT and refresh regularly (e.g. every 30 days) to minimize security risks.

## How to set up PATs on the ZITADEL console

Should you be interested in using Personal Access Tokens, it is vital to know how it is done. In this chapter, we show you a step-by-step tutorial on how to enable PATs on the [ZITADEL Console](https://console.zitadel.ch/).

Upon signing into the ZITADEL Console, navigate to the Menu on the left of your screen. On the top left, **select the organization** you wish to assign the token to (here: Test2). Next, click on the menu item **“Service Benutzer / Service User”**.

![](/blog/2022-03-03-new-personal-access-token-01.png)

Clicking the “Service Benutzer / Service User” menu item should lead you to the page pictured below. To create a new Access Token, scroll down to the option called **“Access Tokens”** and click on the button **“+Neu / +New”**.

![](/blog/2022-03-03-new-personal-access-token-02.png)

A small new window should pop up on your screen, asking you to **define a custom expiration for the token** you are about to generate. If you wish for your PAT to **only be valid through a specific timespan**, enter the desired expiration date into the input field or select it using the calendar icon on the right, then click the button **“Hinzufügen / Add”**.

![](/blog/2022-03-03-new-personal-access-token-03.png)

Whether you chose to enter an expiration date or not, upon pressing the **“Hinzufügen / Add”** button, another small window should be revealed. The message in red will **warn you to copy the long token code, for you will not be able to access this code again**. To do so, **click on the clipboard icon** next to it. Once the code is copied, you can close the small window by pressing the **“Schliessen / Close”** button.

![](/blog/2022-03-03-new-personal-access-token-04.png)

Following the previously listed steps should result in the creation of a Personal Access Token for your desired organization. Finally, the copied token code can be embedded **as a bearer token in the authorization header** into the ZITADEL application via a third-party service.

See our [documentation](https://zitadel.com/docs/) for more details.

![](/blog/2022-03-03-new-personal-access-token-05.png)

## In Conclusion

If you are a service user and have trouble with integrating your accounts with JWT Profile, consider enabling a Personal Access Token along with JWT Profile.

Should you have questions regarding PATs, JWTs or any other related (or unrelated) topics, 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).


In this article, we will explain why we have chosen to introduce PAT in addition to JWT, which audience this change will benefit and how PAT can be implemented into the ZITADEL console.

New Personal Access Tokens (PAT): A game changer for Service Users

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

At this year's Worldwide Developers Conference (WWDC) 2021 Apple did announce something that really got me thinking about what the future for Risk Based Authentication (RIBA) holds.

In short Apple did announce a feature called “iCloud Private Relay”. What it basically does is to hide the user's origin from the services the user calls. This in a way that Apple and the egress provider should not be able to track the user. Whether that’s true or not is a thing we will see in the future. This design somewhat resembles what TOR does but with less privacy.

<img
 src="/blog/2021-07-07-imo-rba-is-broken-01.png"
 width="100%"
 alt="iCloud Private Relay"
/>

If a user enables this feature, your RIBA seriously will have a bad time. This is because, as you can see below, the user's IP Address will be more or less useless as a signal. As of writing this blog I was in Switzerland and the IP used to egress my traffic was in a region located in the US. If this also tends to change a lot and fast you can basically throw away IP addresses as data of your RIBA.

<img
 src="/blog/2021-07-07-imo-rba-is-broken-02.png"
 width="100%"
 alt="Settings Private Relay"
/>

```json
{
 "ip": "2a09:bac0:205::815:95a",
 "ip_decimal": 55878094235311776708809106431373805914,
 "country": "United States",
 "country_iso": "US",
 "country_eu": false,
 "latitude": 37.751,
 "longitude": -97.822,
 "time_zone": "America/Chicago",
 "asn": "AS13335",
 "asn_org": "CLOUDFLARENET",
 "user_agent": {
 "product": "curl",
 "version": "7.76.0",
 "raw_value": "curl/7.76.0"
 }
}
```

Some of you now might say: “Well we have cookies and browser fingerprinting”.
Yes but with Apple's recent announcement towards improving the privacy features of Safari things are getting harder as we speak. And this does not only apply to Apple but other browsers as well.

So what is the solution to all of this? 
To be frank with you, get rid of your RIBA process and start towards the passwordless journey. It both improves your security and the users' risk quite a lot. If you are interested I dearly recommend that you read my [IMO - Passkey in iCloud Keychain](/blog/imo-passkey-in-icloud-keychain/) as well.

So that’s it? Just throw RIBA away? 
Well there is a nuance to this, which I might encourage you to differ a little from that view. If we are talking about **re-authentication** and **session management**, I still recommend you to use signals you collect about the device and user, for example user-agent version, language, time, TLS version and cipher and so on to prevent things like “session cookie extraction” from the browser.

**But please stop relying on RIBA for the plain authentication of a user!**

## Resources

https://www.apple.com/newsroom/2021/06/apple-advances-its-privacy-leadership-with-ios-15-ipados-15-macos-monterey-and-watchos-8/

https://www.theverge.com/2021/6/10/22526881/apple-icloud-plus-privacy-subscription-services-revenue-wwdc-2021

https://www.heise.de/hintergrund/Die-Kruecke-fuer-Passwoerter-und-wie-sie-ausgenutzt-wird-4970547.html

Apple's “iCloud Private Relay” breaks risk based authentication (RIBA). You should get rid of your RIBA process and start towards the passwordless journey.

IMO - Risk Based Authentication is broken


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

With the recent announcement of Apple at their annual Worldwide Developers Conference (WWDC) 2021, our perception of how secure authentication should work will gradually shift towards a passwordless future.

The new(est) innovation from Apple to get rid of passwords and second factors is called “Passkeys in iCloud Keychain”. It basically works with the WebAuthN API by utilizing the FIDO2 specification (CTAP2) to create a private / public key pair for each login system. This is normally identified by its domain name of the server challenging your device for authentication. For this to work across devices it is necessary to synchronize the private key in some way.

[Edit: The video has been removed from youtube. You can watch it on developer.apple.com](https://developer.apple.com/videos/play/wwdc2021/10106/)

But wait … synchronizing a private key across your devices with a cloud solution does not sound exactly … sane!  
Well, ok. Let's argue for a minute what the “normal” user does anyway. Many users today rely on password managers to synchronize their passwords and sometimes even their second factors. By doing so, they already expose their secrets to some provider, for example Google, Apple, Microsoft, 1Password, and so on. Even if those providers claim that the secrets are encrypted, it is not a penny better from a security perspective than the synchronization of a private key with the same process. In the end, all private keys, passwords and OTP seed secrets are all **secrets** which allow access to your resources.

But then again, some of you might argue: “I totally control the sync process with a software I run on my own!”  
Well that does not really change the statement above because you end up using a device from one of those vendors anyway and most of them are closed source, so you have absolutely no guarantees that they don’t steal your credentials on the OS level anyway (some exceptions apply - looking at you Linux and to some degree Android).  
To make things worse on an OS or even browser level. Something, like a malicious browser extension or trojan horse, could steal things like access_token or cookies, which broadens the threat model a lot towards OS and browsers.

Oh and to make things worse… Out of band processes like OTP, SMS-TAN and email codes don’t help this effort. If you gain access to either the user's device, OS, or browser, then your whole security model is broken anyway. This is because a lot of today's users just use one device in which they login and also store, receive or generate their second factor.

Ah and yes don't even get me started about those pesky banking authentication apps!

So with this in mind is it still a bad thing to sync the private key?

Well, in my opinion, even with all the downsides like synchronization of private keys (secrets in general) we still gain an **improved user experience** and **phishing resistance**, which I find important these days **without any additional risk** (remember you have them anyway). Also, we reduce the attack surface by **preventing credential reuse** by the user.

So if you ask me: The tradeoff made here by Apple does outweigh the risk. And if you think this risk is too high for you, then just do not use iCloud Passkeys (and password managers in general) and stick to hardware keys.  
If you really care about security you would end up with mTLS (mutual TLS) anyway because this is the only way to mutually authenticate connections and mitigate Man-in-the-middle risk more or less completely (which FIDO2 does not). But this is a topic for another time.

If you want to test iCloud Passkeys today you are best off to use iOS 15, iPadOS 15 or macOS Monterey. Optimally you have multiple devices to see whether the keys get synced across your devices with iCloud Keychain.

As of today more and more systems and services offer the use of passwordless authentication methods. For example your Microsoft Login can be used in this way. Popular Open Source IAM Solutions like Keycloak also give you the option to use passwordless. Our IAM as a Service project ZITADEL does also provide support for the password authentication future.

But remember: Passkeys in iCloud Keychain are **not production ready yet** (technology preview) and are intended for testing only. So for your own sake, please register a fallback hardware key like the ones from our friends at SoloKeys or YubiKey. We recommend you to register multiple keys anyway.


Apple spearheads the push to a passwordless future. But is their proposal to sync your private keys with their iCloud a good idea?

All posts/ #security