In this article, you'll learn how to secure your full stack Java application with OIDC. Here, you'll create two simple Spring apps

How to secure your Java application with OpenID Connect


[Next.js](https://nextjs.org) is a modern JavaScript website framework created and maintained by [Vercel](https://vercel.com). It helps developers create feature rich full-stack applications, which can be deployed to different types of hosting providers, including Vercel, [Netlify](https://www.netlify.com/), and [Amazon Web Services (AWS)](https://aws.amazon.com/).

Using Next.js lets you focus on getting your product in place instead of setting up your development infrastructure. It comes with an out-of-the-box development toolkit and provides you with a development server to easily run code modifications in the browser while you edit the codebase.

Next.js focuses on code optimization and performance optimization for a better user experience (UX) and developer experience (DX) and includes advanced features like code splitting and [Hot Module Replacement (HMR)](https://webpack.js.org/concepts/hot-module-replacement/).

In this tutorial, you'll learn how to set up a Next.js project using JavaScript. You'll also learn how to integrate that with [ZITADEL](https://github.com/zitadel/zitadel), an open source identity management platform and security layer for your web application.

## What Is Next.js

Next.js is a hybrid web framework that lets you build statically generated pages and hydrate them with client-side JavaScript components built with [React](https://reactjs.org).In a nutshell, it takes a static Document Object Model (DOM) from the HTML and injects JavaScript code to be linked with the nodes inside the DOM. Once the code is loaded, it mounts the DOM element and creates framework-specific listeners. At the end of hydration, your code will act the same way SPA does in the first place.

Statically generated pages are still reactive according to the Next.js documentation, and the framework hydrates your application on the client side to give it full interactivity in addition to the static HTML. Hydration is valuable when you want to enable your pages to load faster, and improve user experience. This is advised when your application has a lot of users such as an e-commerce website or a marketplace application. With Hydration, search engines can index better your content because your content can be rendered before the page is loaded and this is very important for SEO.

Next.js also has a large open source community with a rapid release cycle backed by Vercel as well as a wide ecosystem of a variety of plug-ins built for [Node.js](https://nodejs.org/) and React, where both are used to deliver a highly performant Next.js experience.

Next.js does even more by providing smooth client-side navigation using JavaScript routing, so the result quickly loads in users' browsers. At the same time, static content gives you the best performance when it comes to indexing your website in search engines like Google.

This framework can be used for all kinds of projects and applications, including customer-facing marketing websites, landing pages, software-as-a-service (SaaS) tools, a back-office dashboard to aggregate and show internal metrics, or a content management system (CMS).

The majority of these systems and applications built by developers interact with the user and let them perform certain actions within the application after they've been authenticated and authorized. That's where [OAuth](https://en.wikipedia.org/wiki/OAuth) solutions like ZITADEL come in.

## Prerequisites

Before you begin this tutorial, you need to be comfortable designing both backend and frontend JavaScript applications. You also need to know the basic concepts behind React and its syntax subset called [JSX](https://reactjs.org/docs/introducing-jsx.html).

You should also have the most recent version of Node.js installed on your workstation, as all the open source packages in this tutorial are designed for a Node.js runtime environment. (At the time of writing, the current version of Node.js is 18.7.0.)

In addition, make sure Next.js, the SSG/SSR framework that connects all the libraries together, is installed. It should be installed automatically in the net section using `npx create-next-app@latest`. If you want to install Next.js separately, you can use `npm install -g next`.

It's also helpful to have a basic understanding of authentication and authorization concepts, ideally in the context of [OAuth](https://oauth.net). This knowledge will help you to navigate the authentication flow executed by ZITADEL.

## How to Build a Simple Next.js Application with ZITADEL

If you'd like to follow along, all the code for this tutorial can be found on this [GitHub repo](https://github.com/eugenehp/zitadel-next-app-js).

### Setting Up a Next.js Project

To begin this tutorial, you need to focus on setting up the Next.js boilerplate using the official JavaScript template. In this tutorial, you will use [npm](https://www.npmjs.com), but you can also use other package managers like [Yarn](https://yarnpkg.com) or [PnPM](https://pnpm.io).

Start by creating the application using `create-next-app`:

```shell
npx create-next-app@latest
```

If you want to build your application with `typescript` you can add `--ts`, like the following:

```shell
npx create-next-app@latest –ts
```

For the purpose of this tutorial you will be doing the project based on `javascript`, however you can follow along and build it with `typescript` but you will need to have enough knowledge with both languages.

![Add the name of your Next.js app](/blog/2022-10-22-fullstack-nextjs-01.png)

You'll be prompted to enter the name of the project. In this case, it's `zitadel-next-app-js`.

Once installed, you should see the following:

![`create-next-app` finished its work](/blog/2022-10-22-fullstack-nextjs-02.png)

After installing Next.js, you need to add the [NextAuth.js](https://next-auth.js.org/) library using the following code:

```shell
npm install --save next-auth
```

Now, it's time to run the app in development mode:

```shell
npm run dev
```

Once you run it, you should see the following:

![Output of `npm run dev`](/blog/2022-10-22-fullstack-nextjs-03.png)

To make sure that it works in the browser, navigate to [http://localhost:3000/](http://localhost:3000/):

![Next.js application running](/blog/2022-10-22-fullstack-nextjs-04.png)

### Setting Up ZITADEL

In order to use ZITADEL credential keys in the next section, you need to set up an account (if you don't already have one). To do so, head to [https://zitadel.com](https://zitadel.com/signin) and create a new account by following these steps:

Start by filling out the free trial form:

![Sign-up form on the ZITADEL Customer Portal](/blog/2022-10-22-fullstack-nextjs-05.png)

Now you can see that a ZITADEL organization has been created:

![ZITADEL organization created](/blog/2022-10-22-fullstack-nextjs-06.png)

Activate your user account by navigating to your email and clicking on the link in the email from ZITADEL:

![Activate user account](/blog/2022-10-22-fullstack-nextjs-07.png)

Now your account has officially been activated:

![User activated](/blog/2022-10-22-fullstack-nextjs-08.png)

> **Please note:** You can skip the multifactor setup for now, but you should activate it before going to production:

![Skip multifactor setup for now](/blog/2022-10-22-fullstack-nextjs-09.png)

Your view of the ZITADEL dashboard (also referred to as the customer portal) should look like this:

![The view inside the ZITADEL dashboard](/blog/2022-10-22-fullstack-nextjs-10.png)



Now it's time to set up your ZITADEL instance. To create a new instance, click on **+ New**:

![Creating a new instance called `zitadel-instance`](/blog/2022-10-22-fullstack-nextjs-11.png)

Select **Continue** then **Confirm** the creation of a new instance:

![Confirming new instance](/blog/2022-10-22-fullstack-nextjs-12.png)

In a few seconds, your ZITADEL instance will be created:

![New instance has been created](/blog/2022-10-22-fullstack-nextjs-13.png)

Now you'll receive another email from ZITADEL titled **Initialize User**. Open the email and select **Finish Initialization**. You should receive a prompt to create a new password for your ZITADEL instance. Create it, and then click **Next**. 

Follow the prompts to login with your new credentials. Then select **skip** to skip creating multi-factor authentication. 

Now you should be logged in to the instance UI console:

![ZITADEL UI Console](/blog/2022-10-22-fullstack-nextjs-14.png)

> **Please note:** The credentials you created in the first part of this setup differ from the credentials you just created. The first credentials are for the *customer portal* and the second are for the *ZITADEL instance*. When working with different environments you can create ZITADEL instances for each environment (*ie* one instance for development and another one for production environments). 

After you've created your ZITADEL instance, you need to create a ZITADEL project. Projects in ZITADEL represent a container for applications and other artifacts. You can think of each project as a separate OIDC environment.

In the instance UI console, click on the **Projects** tab. Then select **Create New Project** to set up a new OIDC provider.

Give your project a name (nextjs-zitadel-project):

![Name your ZITADEL project](/blog/2022-10-22-fullstack-nextjs-15.png)

Then click **Continue**. ZITADEL will create your project and redirect you to the project settings:

![ZITADEL project settings](/blog/2022-10-22-fullstack-nextjs-16.png)

Click on **+ New** under **APPLICATIONS** and name your application (web-nextjs), then click **Continue**:

![New application](/blog/2022-10-22-fullstack-nextjs-17.png)

Select **PKCE**, then **Continue** and add `http://localhost:3000/api/auth/callback/zitadel` as a redirect URL to your app.

Finally select **Continue** and then **Create**.

> Take note of your client ID as you will need it in the next step. 

Make sure you grab the instance's domain name from the URL of the instance (you can get it from your browser, or from the customer portal under instances); it should have the following format: `https:/[your-domain]-[random-string].zitadel.cloud`. You will need this information to point your code to this domain in order to enable user authentication.

### Creating Environment Variables

To create an environmental variable, you need to create an env file in the root directory and add it to `.gitignore` so it won't be committed to your Git repository (according to the [Twelve-Factor App](https://12factor.net) methodology).

Your env file should look like this:

```text
NEXTAUTH_URL=http://localhost:3000
ZITADEL_CLIENT_ID=[yourClientId]
ZITADEL_ISSUER=https:/[your-domain]-[random-string].zitadel.cloud
```

Here, `NEXTAUTH_URL` is the URL where the user will be redirected after authentication by ZITADEL. `ZITADEL_CLIENT_ID` is the client ID you can get from ZITADEL's instance's interface (for example, structured like this `175094091363713281@nextjs-zitadel-project`). `ZITADEL_ISSUER` is a URL structured like this: `https://zitadel-instance-w2iqk1.zitadel.cloud`.

### Implementing Authentication Flow Using NextAuth.js and ZITADEL

With ZITADEL's authentication you can use the Proof Key for Code Exchange (PKCE), which is the most recommended authentication mechanism. PKCE is a security mechanism that is a part of the OAuth 2.x protocol for public clients and outlines a secure way of exchanging authorization codes between public clients. If you want to read more about PKCE and its importance, check out how the [Dropbox](https://www.dropbox.com/) engineering implemented a [secure exchange in accordance with OAuth flow](https://dropbox.tech/developers/pkce--what-and-why-).

ZITADEL is a fully compliant OIDC/PKCE solution that implements the entire flow using its infrastructure. On the Next.js side, both frontend and backend legs of the OIDC/PKCE flow are completed using the `next-auth` library.

To implement your authentication flow, in your root directory, go to `pages/api`, create an `auth` directory, and then create a file named `pages/api/auth/[...nextauth].js` with the following configuration of the `next-auth` [custom provider](https://next-auth.js.org/configuration/providers/oauth#using-a-custom-provider):

> ** Please note:** The `[...nextauth].js` in `/pages/api/auth` is an actual API endpoint that will catch all requests of the `next-auth` library.

```javascript
import NextAuth from "next-auth";

const profile = async (profile) => ({
  id: profile.sub,
  name: profile.name,
  firstName: profile.given_name,
  lastName: profile.family_name,
  email: profile.email,
  loginName: profile.preferred_username,
  image: profile.picture,
})

const wellKnown = process.env.ZITADEL_ISSUER
const clientId = process.env.ZITADEL_CLIENT_ID

export const ZITADEL = {
  id: "zitadel",
  name: "zitadel",
  type: "oauth",
  version: "2",
  wellKnown,
  authorization: {
    params: {
      scope: "openid email profile",
    },
  },
  idToken: true,
  checks: ["pkce", "state"],
  client: {
    token_endpoint_auth_method: "none",
  },
  profile,
  clientId
};

export default NextAuth({
  providers: [ZITADEL],
});
```

Now, Next.js will listen on `http://localhost:3000/api/auth/callback/<provider-name>`, which, in this case, is `http://localhost:3000/api/auth/callback/zitadel`. This is a critical step since the frontend of the Next.js framework will redirect to this callback after talking to ZITADEL's instance (that you created previously).

### Implementing OpenID Connect Flow on the Client Side

To implement OIDC on the client side, go to **pages** > **pages/index.js** and then edit your source code:

![Find the `pages` folder and select the `index.js` file](/blog/2022-10-22-fullstack-nextjs-18.png)

Then add the following content to your `index.js` page:

```javascript
import { signIn, signOut, useSession } from "next-auth/react"

const callbackUrl = 'http://localhost:3000/profile'

export default function Page() {
  const { data: session } = useSession();

 return <div>
  {!session && <>
    Not signed in <br />
    <button onClick={() => signIn('zitadel', { callbackUrl })}>
      Sign in
    </button>
  </>}
  {session && <>
    Signed in as {session.user.email} <br />
    <button onClick={() => signOut()}>Sign out</button>
  </>}
 </div>
}
```

To make `useSession()` work, you need to enhance `pages/_app.js` with the `SessionProvider`. This will act as a [React context provider](https://reactjs.org/docs/context.html) for the `useSession` hook:

```javascript
import { SessionProvider } from "next-auth/react";

function App({ Component, pageProps }) {
return (
  <SessionProvider session={pageProps.session}>
    <Component {...pageProps} />
  </SessionProvider>
);
}

export default App;
```

To finish, you need to create `pages/profile.js` with the content for the `http://localhost:3000/profile` page. On the **end-user** page, you'll be able to see if they've successfully logged in using ZITADEL's instance:

```javascript
import Link from "next/link";
import styles from "../styles/Home.module.css";

export default function Profile() {
  return (
    <div className={styles.container}>
      <h1>Login successful</h1>
      <Link href="/">
        <button>Back to Home</button>
      </Link>
    </div>
  );
}
```

At this point, you've installed `next` and `next-auth`, and you've created an `api` route called `auth/[...nextauth].js`. Then you've created a `profile` page that requires authentication. After that, you enhanced `_app.js` to inject `SessionProvider` into all Next.js pages, including `profile.js` and `index.js` pages. Inside the main page, `index.js`, you added conditional buttons for `Sign In` and `Sign out`.

Now, go to [http://localhost:3000/](http://localhost:3000/) then click on **Sign in**:

![Sign in](/blog/2022-10-22-fullstack-nextjs-19.png)

You'll be redirected to [https://zitadel-instance-w2iqk1.zitadel.cloud](https://zitadel-instance-w2iqk1.zitadel.cloud) and can login using your ZITADEL account.

You should now be signed in and redirected to [http://localhost:3000/profile](http://localhost:3000/profile) with **Login successful**:

![Login successful] (https://i.imgur.com/CVy1D5j.png)

Select **Back to Home**, then **Sign out**.

Following is a model of how all the pieces work together:

![Next.js ZITADEL architecture courtesy of Eugene Hauptmann](/blog/2022-10-22-fullstack-nextjs-20.png)

## Conclusion

In this tutorial, you learned how to set up a Next.js project and integrate it into ZITADEL identity management. You used the [OIDC](https://openid.net/connect/) flow as part of [PKCE](https://oauth.net/2/pkce/) using standard [RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636) implementation via the open source library `next-auth` inside a Next.js full stack project.

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


*This article was contributed by [Eugene Hauptmann](https://portal.draft.dev/writers/recXRh25IXq6i0RoU).*

*Note: In the meantime we published a [nextauth provider](https://next-auth.js.org/providers/zitadel) that makes integration with your NextJS application even easier.*


In this tutorial, you'll learn how to set up a Next.js project using JavaScript. You'll also learn how to integrate that with ZITADEL, an open source identity management platform and security layer for your web application.

Full Stack ZITADEL Integration with Next.js


Tokens are used to represent and transmit security information between parties, and they silently power a large part of the authentication and authorization that happens on the internet. In web services, the two most popular kinds of tokens are JSON Web Tokens (JWTs) and opaque tokens.

A JWT is a JSON string that contains all the claims and information it represents and is certified by a signature from the issuer. By default, it’s unencrypted, but it can be encrypted via the [JSON Web Encryption (JWE)](https://www.rfc-editor.org/rfc/rfc7516) standard.

On the other hand, an opaque token's format is chosen by the issuer of the token. Usually, it's a string of numbers and/or characters that identifies some information in the database of the issuer. This is in contrast to JWTs where the holder of the token can't inspect it without contacting the issuer (*ie* the contents are opaque).

In this article, you'll learn why you need JWT and opaque tokens, what the differences are between the two, and in which case you should select one or the other.

## Why You Need JWTs and Opaque Tokens

In contrast to simpler methods for managing identification and access, JWTs and opaque tokens offer a few advantages, including the ability to share your identity or authorization to a third party. These tokens can be used to enable you to log in with your Google account to third-party websites and enable third parties to access private information, like your Gmail contacts.

They also offer you fine-grained access control. Providing a username and password is an all-or-nothing proposal, so you probably don't want to share that information with a third party. In the [OAuth 2.0](https://oauth.net/2/) protocol, tokens enable delegating a certain scope of actions to a third party, which means that they will only be able to do things that you've explicitly consented to.

While JWTs and opaque tokens have a lot in common, there are some notable differences that should be considered.

## Differences between JWTs and Opaque Tokens

The main difference between JWTs and opaque tokens is that an unencrypted JWT can be interpreted by anybody that holds the token, whereas opaque tokens cannot.

An unencrypted JWT consists of three parts: a header, a payload, and a signature. The header contains the name of the token type and the signing algorithm used for the signature. The payload, which is the contents of the token, is encoded but not encrypted, so anybody can read it. The signature makes sure that the payload is not tampered with. There are [examples of encoded and decoded JWTs] available that you can experiment with to learn more.

A JWT that's encrypted adds a few more layers that deal with the encryption information like the key used. You can find more information about the [JSON Web Encryption (JWE) standard here](https://www.rfc-editor.org/rfc/rfc7516).

In addition, a JWT is meant to be stateless and self-contained—it has all the information the server needs except the signing keys, so the server doesn't need to store this information server-side. This means that users can get a token from your authorization server and use it in another without those servers needing to consult a central service.

However, this doesn't always play out perfectly. For example, a self-contained token that is issued is not easy to revoke, but there are a few ways to work around this. For example, you can add an [`exp`](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4) claim which signifies an expiration date for the token. Or you can use the [`jti`](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7) claim to assign a valid identifier. Using the identifiers, you can create blacklists to block certain token identifiers.

Opaque tokens cannot be read by people that hold them since they are undecodable strings. A client cannot read the contents of the token without interacting with the authorization server by querying an [introspection endpoint](https://www.oauth.com/oauth2-servers/token-introspection-endpoint/) or checking the claims of the token with the userinfo endpoint.

## When to Use Opaque Tokens Instead of JWTs

If you classify tokens by their purpose (and not format), you end up with two main types of security tokens: ID tokens, which are introduced by [OpenID Connect](https://openid.net/connect/), and access tokens, which are introduced by [OAuth 2.0](https://oauth.net/2/).

ID tokens are tokens that a server issues to prove that the user is authenticated. You can use them to log into third-party services with another service that acts as an identity provider, like Google. The service will issue you an ID token (*ie* a token confirming your identity) that you can use with a third-party service. The [OpenID Connect](https://openid.net/connect/) protocol requires you to use JWTs for ID tokens.

Access tokens can grant permission for a third party to act on your behalf in some kind of service. In this case, the service will issue the third party an access token (*ie* a token that enables it to take certain actions).

OAuth 2.0 doesn’t prescribe a specific format for access tokens, so you can use opaque tokens, JWT, or any other format that satisfies the [necessary properties](https://oauth.net/2/access-tokens/). This means that, technically, you can use JWTs for providing access tokens; however, JWTs have certain downsides that become much more prominent when working with access tokens.

Following are three situations when you would want to use opaque tokens instead of JWTs:

### When You're Transmitting Sensitive Information

By default, JWT is encoded but not encrypted. This means that anyone that gets ahold of a token can read the contents of that token. This can be harmful when the attacker uses the contents of the token to gain information such as the user's role or even personally identifiable information.

You can encrypt the token using the JSON Web Encryption (JWE) standard so that it can only be read by the intended recipient. But this comes with its own challenges in cryptographic key distribution and management.

All in all, securing JWTs is somewhat complicated, so using them for sensitive data adds unnecessary complexity and risk. Opaque tokens are not readable by default, so if you're transmitting sensitive information, they're usually the better option.

### When You Want to Revoke Tokens

JWTs are supposed to be self-contained. Once you issue one, you have no possibility to edit the contents of the token since it rests with the client. This means that every token that you issue is prone to become outdated. For this reason, these tokens are usually created with an expiration time of a few minutes.

In contrast, opaque tokens are stored on the server. So you can change their contents at will. If a user is banned or deleted, or if any other action is taken that would invalidate their token, you can instantly revoke the token that is residing in your storage. There is no window to use an invalid token.

For this reason, JWT tokens are a bad choice for storing long-lasting authorization and session data. Because of the necessity to include an expiration date with your tokens, you can't really issue them for too long. And if you want to end a session, you can't really make the token invalid.

It's possible to issue unique identifiers to tokens and use allowlists, denylists, or centralized database tables to manage the access that issued JWT tokens have, but this defeats the purpose of having a stateless, self-contained token to some degree.

### When You Care about Payload Size

A token needs to be attached to every request that the client makes to the server. If the payload size is small, this is no issue. But a larger token can gobble up more than its fair share of bandwidth.

In contrast, an opaque token can store much more information since the data resides in a server . The client only needs to send the string that you have issued over the wire. This string, in turn, enables your server to look up the token in its database or authorization service.

### Can Using JWTs be Advantageous?

Although the format of JWTs have quite a few downsides, there are some situations where the self-sufficient nature of JWTs shine.

For example, if your system is highly distributed, querying the authorization server for the token details of opaque tokens may create additional internal traffic to the server, increase overall latency, and create a bottleneck for the system.

If your use case is simple, you’re not transmitting sensitive information, and you're not concerned about revoking tokens, JWTs are the superior choice.

## Conclusion

JWTs are stateless, self-contained tokens that are encoded but not encrypted. For this reason, JWTs should be used to create small tokens that don't contain sensitive information and don't need to be revoked.

In contrast, opaque tokens are strings that point to data on the server. By design, they cannot be read by their holders. Therefore, this method should be used to create tokens that contain sensitive information. In addition, since the tokens are stored on the server, they can carry more data than JWTs, and you can easily revoke them if necessary.

By now, you should have a better understanding of when and how to use JWTs and opaque tokens. If you want more information about authentication and authorization, OAuth 2.0 has an [official page](https://oauth.net/2/) with the industry standard authorization protocol as well as links to more resources on this topic.

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

*This article was contributed by [Gints Dreimanis](https://portal.draft.dev/writers/recJq3C8hXEphbtcB).*


In this article, you'll learn why you need JWT and opaque tokens, what the differences are between the two, and in which case you should select one or the other.

JWT vs. Opaque Tokens


If you're a tech company, [identity and access management (IAM)](https://en.wikipedia.org/wiki/Identity_management) should be at the very foundation of your cybersecurity strategy. Safeguarding credentials and authenticating users can help you guard against many forms of application security breaches. A strong and reliable authentication provider can help you keep out both internal and external threats to your digital assets.

Most small-to-medium companies struggle to find the right authentication service provider. A full-fledged IAM solution may prove too costly for many companies to adopt. This is why several [open source tools](https://solutionsreview.com/identity-management/the-10-best-free-and-open-source-identity-management-tools/#:~:text=The%2010%20Best%20Free%20and%20Open%20Source%20Identity%20Management%20Tools) have been developed. Some of these free tools, like [Keycloak](https://www.keycloak.org/) ,[Ory](https://www.ory.sh/), and [ZITADEL](https://zitadel.com/opensource) offer you the power to outsource all your authentication tasks and user identity management, and achieve scale with minimal operational costs.

In this article, you'll learn about open source authentication providers, their common use cases, and what your organization stands to gain from adopting an open source authentication solution.

## What Is an Open Source Authentication Provider

As the name suggests, an open source authentication provider is simply an authentication service provider that is open source for developers and companies to use. Authentication lives at the core of the IAM system services, and some of these IAM system providers offer their services in the open source.

More recently, there has been an industry shift toward centralized authentication solutions and APIs, which is driven by the market demand for fast and seamless logins across several systems, as well as the desire to create robust security architecture for data.

Just like cloud infrastructure providers now provide their platform as a service, third-party authentication providers provide [authentication as a service (AaaS)](https://www.onespan.com/topics/authentication-as-a-service#:~:text=Authentication%20as%20a%20Service%20is%20a%20modern%20way%20to%20approach,that%20can%20be%20rapidly%20deployed.). Whether you're in finance, sales, healthcare, or any other sector, you need a secure authentication system that can protect your digital assets and systems. Open source authentication providers are essential for the digital ecosystem for many reasons:

* **Safety and stability:** Using an authentication service has the inherent advantage of reducing the security risk to your system. It helps you detect unlawful accesses and breaches, ensuring your organization complies with regulatory standards. Adopting a well-maintained open source authentication tool ensures that your security architecture is built on a stable and available IAM solution, which allows backward compatibility. It's important to note that your preferred IAM solution should guarantee 100 percent availability all the time.
* **Vendor lock-in and Escrow**: Using an open source authentication solution ensures that your organization can avoid vendor lock-in with commercial providers. Since open source software is usually developed with an open standard, your team can easily switch between vendors for your authentication services without having to redesign your architecture to integrate with a new provider. Open source authentication software gives you direct access to the technology that would, at best, be accessible under an escrow agreement with a commercial vendor.
* **Code Quality:** Open source code is usually on par with the highest standards in the industry. Tools developed in the open source have hundreds, or even thousands, of contributors from all over the world. This ensures developers from different sectors raise issues and keep the codes to the highest quality possible with constant improvements.
* **Abundant support:** One major challenge companies and developers face when integrating proprietary tools is compatibility and support with other developer tools and workflows already in use by the company. Even though open source projects are usually sponsored by a variety of affiliated companies, the software tools are built from the ground up without bias for integration with specific tools. Because of this, open source software will most likely support integration with the most common tools developers use.
* **Possibility to contribute:** What if you want a specific feature or integration support? [Open source is code written by developers, for developers](https://www.freecodecamp.org/news/what-is-great-about-developing-open-source-and-what-is-not/#:~:text=Open%20source%20code%20is%20written%20by%20developers%20and%20for%20developers.). You can easily code your preferred feature, or even contract others to build them, and propose the change to the core team. In this way, you can have a say in the road map the product development follows.

## Why You Need an Open Source Authentication Provider

If you want to be able to focus on developing your application logic, you should consider using a turn-key authentication service. The ease with which you can evaluate what particular open source authentication provider will suit your needs and technology stack at zero upfront cost is one major reason open source authentication providers are gaining popularity.

Choosing between commercial (closed source) authentication and open source authentication providers can confound even the best engineers if you fail to properly highlight your requirements and the specific offerings of each provider in consideration. Many of these “closed” source and proprietary authentication providers hardly provide sufficient information about their protocols. As such, you will find it difficult to get detailed reviews or documentation on them before subscribing to the service.

Following are a few benefits of choosing an open source authentication provider for your application:

### Build Trust into the Security-Critical Service

You should consider adopting an open source application for your authentication needs mainly because of the trust and security built into them. Open source communities generally have a shared interest in upholding the security of their product. Developers and users promptly find and report security flaws to the core team or creators, who in turn fix the problem right away.

An open source service provider can be trusted not to misuse or abuse their access to your users' data intentionally, unlike the way many commercial software platforms misuse code because they don't have a trusted avenue of verifying their codes. Essentially, the trust and security of open source technologies are widely seen as the [responsibility of the community developers and the other stakeholders](https://snyk.io/series/open-source-security/#:~:text=85%25%20felt%20developers%20were%20responsible%20for%20open%20source%20security). Although fostering openness and operational transparency of open source applications also help build trust.

Furthermore, the concept of distributed trust shows how trust is inherently built into open source applications. This follows Aristotle's theory of the [wisdom of the crowd](https://opensource.com/article/21/1/open-source-distributed-trust#:~:text=wisdom%20of%20the%20crowd%C2%A0theory%20posited%20by%20Aristotle%2C%20where%20the%20assumption%20is%20that%20the%20opinions%20of%20many%20typically%20show%20more%20wisdom%20than%20the%20opinion%20of%20one%20or%20a%20few.), which assumes that the opinion of many carries more wisdom than that of the few. The concept carries relevance in open source communities in that once you join a community for a project, you assume responsibility that allows you to participate in the project development, and the more involved you are, the more trust you have in the community and its product.

### Builds on Open Standards

According to an [IBM article discussing open standards](https://www.ibm.com/blogs/cloud-computing/2019/04/02/open-standards-vs-open-source-explanation/#:~:text=An%20open%20standard%20is%20a,both%20themselves%20and%20to%20customers.), "an open standard is a standard that is freely available for adoption, implementation and updates." Standards are set for businesses operating in the same industry so as to provide value for customers and stakeholders alike. SQL, PDF, and HTML are all popular examples of open standards developers interact with daily.

Many open source authentication providers tend to build their software with open industry standards. For authentication, examples of open standards include, [OpenID Connect](https://en.wikipedia.org/wiki/OpenID), [Security Assertion Markup Language (SAML)](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language), [FIDO2](https://fidoalliance.org/fido2/), and [JSON Web Tokens](https://en.wikipedia.org/wiki/JSON_Web_Token). This means your business can avoid vendor lock-in, a phenomenon that is likely to occur with commercial authentication providers.

For instance, let's assume your organization secures the license to use a PDF editor and viewer from a popular vendor. For years, your organization has used the PDF service to generate millions of valuable PDF documents. Your business will not have any challenges switching from one vendor to another since the PDF is an *open standard*. A similar example with authentication providers occurs when large commercial providers build proprietary solutions that are not compliant with the open standard for authentication. This makes it difficult for you to switch over to other providers in the open source since you may need to rebuild some parts of your system to integrate with the new provider.

This example can be cascaded to authentication standards, and it illustrates the advantages of choosing an open source authentication service.

### Fix Bugs Quickly

As mentioned earlier, when open source products get critical bugs, they are easily detected by the active users and developer community. In fact, some projects undergo [intensive and targeted security audits by the stakeholders](https://zitadel.com/blog/pentest-results-h1-2021) to ensure they are responsible and maintain a high-security standard.

Even more fascinating is the speed with which these community-supported projects fix bugs. However, you need to note that there are also many open source projects with convoluted and exasperating bug reporting and resolution processes. This should not discourage you from following the guidelines and advice provided by the community for responsible disclosure of critical issues. A responsible open source project will ensure the issues are acknowledged and resolved within a reasonable timeframe. Ultimately, you (the user and maintainer) and every other stakeholder are responsible for the processes, maintenance, and security of the software.

### Cost

Open source software shines bright when it comes down to cost. In many cases, open source authentication providers charge nothing. The catch here is that you have to run the authentication software application on your own in-house infrastructure, which could add an extra layer of cost implicitly.

It's important to note that while you can run the software on your own infrastructure, open source providers usually bear the responsibility of maintenance and security. The extent of these additional operational responsibilities afforded to you may depend on the tier of license you procure. [Dual licensing](https://www.mend.io/resources/blog/dual-licensing-for-open-source-components/) of open source software makes this possible.

## Conclusion

In this article, you learned about open source authentication providers and why choosing an open source authentication provider is beneficial. Open source is not restricted to providing you with free codes and resources to build your application. It also means that you can be an active contributor to the security, stability, and maintenance of the product.

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

*This article was contributed by [Idowu Odesanmi](https://portal.draft.dev/writers/recr2TiHgJUuws1iP).*

In this article, you'll learn about open source authentication providers, their common use cases, and what your organization stands to gain from adopting an open source authentication solution.

Why Choose an Open Source Authentication Provider


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.

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!


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.

All posts/ #engineering