Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

Read the blog

Sign up

Login

Pricing

Jobs

Blog


[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


## Summary

Florian gives his personal opinion about serverless container architecture. In this talk he draws from the experience - and pain - moving ZITADEL away from Kubernetes to a serverless container architecture on Google CloudRun. This talk was recorded as part of the Open Source @ Siemens 2022 Conference in Zug, Switzerland.

<br />
<div className="my-4">
  <YouTubeExtended
    videoId={"O2L8kK924Lg"}
    containerClassName={"youtube-container"}
    stopsTitle="Outline of the Talk"
    stopList={[
      { name: "Why I am talking about this", time: "1:41" },
      { name: "Serverless, a classification (attempt)", time: "5:16" },
      { name: "Some of the 'serverless' offerings", time: "8:18" },
      { name: "Challenges", time: "10:40" },
      { name: "Unique IDs", time: "16:52" },
      { name: "Cold Start Times", time: "21:23" },
      { name: "Networking (extended)", time: "24:31" },
      { name: "Conclusion", time: "27:11" },
      { name: "Q&A: Randomness - Did you run out of entropy?", time: "30:27" },
      { name: "Q&A: What were the savings in the end?", time: "32:58" },
      { name: "Q&A: How does development and testing work?", time: "34:08" },
      { name: "Q&A: Did you try something like using AWS Fargate in combination with EKS", time: "36:32" },
      { name: "Q&A: How do you handle scaling VCP connectors", time: "38:08" },
      { name: "Q&A: How do you do testing with serverless?", time: "40:42" },
    ]}
  ></YouTubeExtended>
</div>

[You can download the slides of this talk here.](https://opensource.siemens.com/events/2022/slides/Florian_Forster_What_is_the_fuzz_around_serverless_containers.pdf) of the talk.

## Open Source @ Siemens

The annual event series by Siemens for all topics around open source software.

- [opensource.siemens.io - Event 2022](https://opensource.siemens.io/events/2022/)
- [Recordings of the 2022 event](https://www.youtube.com/playlist?list=PLw7lLwXw4H51OC1UzTYByzQlMzwRAT0Bx)


Our talk at Open Source @ Siemens event on May 17, 2022. What is the fuzz around serverless (containers)? By Florian Forster

What is the fuzz around serverless (containers)?


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

The words "free Wi-Fi" displayed in public spaces are always welcome additions to the place's core function, regardless of whether it's a restaurant, coffee shop or train station. Even though surfing away free of charge in exchange for just entering a short password or your e-mail address might seem convenient, **this simple accessibility also makes public Wi-Fi networks an ideal target for cybercriminals**. Although there have undoubtedly been reports of ill-wishers leveraging the appeal of free internet, given the fact that millions of people still use public networks, it's a **valid question to ask how likely it is to become a victim**.

This article examines whether public Wi-Fi is as dangerous as it is increasingly portrayed.

![](/blog/2022-09-05-public-wifi-01-01.png)

## The Dangers of Public Wi-Fi

Before we can reasonably determine how much of a threat public Wi-Fi poses, we must first consider the attacks that have been commonly reported in this context. The following paragraph lists **the most common cybercrimes committed by attackers exploiting public networks**.

 

### Snooping

As the name suggests, snooping describes the phenomenon of **a person eavesdropping on your online activity via a public network**. Evidently, snoops these days have appropriated sneakier tactics than simply catching a glimpse of your screen from the other side of the café: Attackers on the network **use special software on their own devices to monitor your private browsing** while using public Wi-Fi.

While letting a snoop know you were reading up on the latest gossip on Taylor Swift might not seem like a huge deal, a genuine issue arises as soon as you **enter any login credentials to a page requesting you to sign in**. By doing so, the attacker doing the snooping can **get a hold of your passwords** and use them to access a multitude of your virtual identities, potentially leading to [Identity Theft](https://zitadel.com/blog/smishing#:~:text=2.%20Identity%20Theft,to%20other%20criminals.). 

### Man-in-the-middle Attacks

The possibility of a Man-in-the-Middle Attack happening is another systematic risk associated with utilizing public Wi-Fi. This term describes the phenomenon of a **third party**, also known as a man-in-the-middle, **intercepting the communication between two systems**.

Picture this scenario as an example: You are sitting in the airport waiting room, patiently waiting for the boarding you begin. While scrolling through Zalando, you find a pair of sneakers that catch your attention and are ready to make a purchase. You sign in and fill out the delivery and payment information as usual. However, little do you know that **a hacker has secretly positioned themselves between you and the online store**, sneakily taking notes of the data only Zalando was meant to receive. Simply as that, not only has the **man-in-the-middle learned about your login credentials**, but also your **address and credit card information**. 

### Evil Twin Attacks

As with man-in-the-middle attacks, "evil twin" attacks occur when **malicious parties create fake access points with names that sound safe or familiar** in the hopes that you would connect to them without batting an eye. For example, the hacker might name their created network “Burger King Free Wifi” to **trick their victims into thinking they are connected to a seemingly trusted entity’s access point**. Unlike the genuine counterpart, however, this “evil twin” is usually designed to **monitor and collect users’ data**, such as their login and banking information.

### Malware and Viruses

One of the most well-known risks generally associated with accessing the internet is the **potential for malware to be downloaded without your knowledge and consent**. Sadly, this vulnerability persists while utilizing public Wi-Fi, much more so than when using a private network.

But how does using a free network result in the installation of a virus? Unfortunately, there are multiple typical methods hackers use to infect your device. In some cases, hackers **exploit vulnerabilities in an operating system or software** within the local network by writing codes specifically targeting these shortcomings. Alternatively, cunning attackers can hack the connection point itself, resulting in a **pop-up window suggesting an update to a well-known software** during the connection process (a.k.a Trojan Virus). Whichever method the criminal chooses, the victim will ultimately suffer the same repercussions: **sensitive data theft, file deletion, and occasionally even device incapacitation**.

### How likely are such attacks?

Although public Wi-Fi networks certainly carry some frightening risks with a lot on the line, it is evident that such attacks aren't guaranteed occurrence. So how likely is it really that one will fall victim to a malicious network?

According to a study by [Kaspersky Security Network](https://securelist.com/research-on-unsecured-wi-fi-networks-across-the-world/76733/), a **quarter of the world's Wi-Fi networks lack encryption or password protection**. This means that any individual near an access point **can easily intercept and store all user traffic and then examine it** for data of interest, making these networks the **easiest target for hackers**.

The remaining three-quarters of the analyzed networks use encryption based on the Wi-Fi Protected Access (WPA) protocol family, which is currently labeled the most secure. However, as we have repeatedly witnessed, nothing in the digital age is ever wholly safe:  As per recent research by [Gao et al.](https://www-users.cse.umn.edu/~fengqian/paper/wifisec_mobicom21.pdf), **standard practices for enhancing Wi-Fi security are not that effective** when confronting today’s sophisticated, mature cybercrime market. According to the study, the majority (55%) of the detected attacks on public networks remain ad injections, which **interestingly were more common on better protected Access Points (AP)**. Furthermore, even if the encryption keys guarding the network seem reliable, there is no assurance that a determined attacker will still not manage to find their way into the system.

To sum it up, while it is unlikely that every public Wi-Fi you will ever connect to will harvest your information, **an attack on the network can happen anywhere and anytime**. So, does this mean you should never use a public network again? Not necessarily. However, it is advised to **follow some simple safety guidelines** to ensure that the criminal does not have the last laugh in the case of an attack.

### Minimizing the Chance of an Attack

If you would like to drastically minimize the likelihood of being hacked while using public Wi-Fi, we recommend taking the following few precautions for your safety.

![](/blog/2022-09-05-public-wifi-02.png)

### Make sure you are on an SSL-certified Website

Another simple practice that can help minimize attacks is ensuring the websites you visit (especially on public WiFi) are SSL-certified. Typically, a **URL beginning with "HTTPS://" and a lock symbol to the left of it will indicate this certification**. While the visible difference between an HTTP and an HTTPS domain is just a single added letter, this slight change has a huge impact when it comes to the safety of a site: In contrast to HTTP, **HTTPS protects your communication by encrypting it between browser and server and utilizing TLS to validate the other end of the transaction**.

While the exclusive usage of sites with properly enforced HTTPS is undoubtedly a step in the right direction, it is worth noting that its protection measure is **not free from exploitable vulnerabilities**. For example, you could still find pictures or scripts from websites not secured by HTTPS, even if you visit an SSL-certified site.

### Use a VPN

Generally, the best course of action when utilizing a public network is to avoid logging onto any platform that stores sensitive information. If you must, however, it is strongly **advised to use a virtual private network (VPN)** to encrypt the traffic, regardless of the type of device you are using.

Virtual Private Network (VPN) software provides **privacy by encrypting all your incoming and outgoing traffic, no matter where you are located and which network you use**. This protection is achieved by the VPN hiding your internet protocol (IP) address from the public. Accordingly, with the help of additional encryption of all data traffic, a VPN router is an optimal way to **prevent third parties from unwantedly accessing private information** shared via a public network.

### Enable MFA or Passwordless Authentication

Even if a hacker manages to obtain your login credentials, **having [Multi-Factor-Authentication (MFA)](https://zitadel.com/features#multifactor) activated on your profile should thwart their attempt to access your account**. By requiring one or more additional login factors (for example, biometrics or a code sent via text message), MFA makes it harder to access a profile with a password only. As a result, you will immediately get notified if someone has attempted to log into one of your virtual identities.

An **even safer alternative to MFA would be enabling [Passwordless Authentication](https://zitadel.com/blog/passwordless)** on any platform that offers this option. Although both methods undoubtedly surpass traditional password-based logins in terms of security, **passwordless systems are even less susceptible to phishing and cyber-attacks** due to their complete waiver of passwords. 

### Further Protection Measures

While using technological safety precautions created to assure the highest level of device security is crucial, we shouldn't undervalue the effectiveness of seemingly obvious but strong alternative solutions. Here are some other measures you can take to protect yourself from the risks of public Wi-Fi:

* **Avoid using networks that are not password-protected** – Even though Wi-Fi codes are generally easy to obtain, unprotected networks are generally an easier target for hackers.
* **When not in use, turn off your WiFi** – Keep your WiFi connection off unless you are actively on your device using the internet.  
* **Refrain from using sites that require you to log in** – Especially ones storing sensitive information, such as your credit card information.
* **Complete renunciation** – While it might sound cliché, it truly is the only method guaranteeing 100% safety from the risks of public networks.  



## In conclusion

While you might not fall over every time you go rollerblading, it is always helpful to wear protection-gear just in case. The same logic is applicable to using public Wi-Fi: **Protection measures such as using VPNs, MFA or passwordless and exclusively visiting SLL-certified websites are designed to minimize the chance of cyberattacks** while using public networks. Considering the evolving techniques of today’s mature cybercrime market, it is better to be safe than sorry.

Although public Wi-Fi networks certainly carry some frightening risks with a lot on the line, it is evident that such attacks aren't guaranteed occurrence. So how likely is it really that one will fall victim to a malicious network?

Security Threats of Public Wi-Fi - Is It Just Fearmongering?


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

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

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

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

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

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

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


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

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


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

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

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

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

## What Is OIDC

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

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

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

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

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

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

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


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

### Overview of the OIDC Protocol

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

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

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

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

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

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

## Why OIDC

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

### Single Sign-On

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

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

### Ubiquitous Technology Access

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

### Centralized Credentials Store

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

## How to Customize User Login with OIDC

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

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

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

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

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

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

## Conclusion

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

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

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

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

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

Use OIDC Authorize Request to Customize User Login


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

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

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

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

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

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

You wanted PostgreSQL? We got you covered.

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

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

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

## What is Zero Trust?

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

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

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

## A passing trend or worth the hype?

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

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

## Enabling Zero Trust with Identity Aware Proxies 

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

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

## Zero Trust and ZITADEL

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

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

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

Why Zero Trust is Important

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

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

## What is multitenancy?

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

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

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

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

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

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

## The Benefits

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

### Shared resources and bases - Easier implementation

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

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

### Freehand maintenance

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

### Lower prices

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

### Higher scalability and easy customization

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

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

### Support for B2B

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

## In Conclusion

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

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

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

Everything you need to know about Multitenancy


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

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

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

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

## What is ZITADEL?

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

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

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

## What’s new?

### New Virtual Instances

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

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

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

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

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

New features that should facilitate development:

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

### Pricing Update

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

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

### What’s next for ZITADEL?

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

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

**Features coming soon to ZITADEL:**

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


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

Introducing ZITADEL Version 2.0!


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

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

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

## New digital threats kids are subjected to 

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

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

### Phishing

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

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

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

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

### Identity Theft

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

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

### Registration and Access Requests

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

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

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

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

### Enable Passwordless or MFA

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

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

### Checking the operating system

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

### Use a VPN

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

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

### Enable Adblocker and Content Blocker

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

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

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

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

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

## Knowledge is power

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


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

Blog.