Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog


Delegated access management lets you offer increased flexibility over the services you provide. 
In this self-service model, your clients can grant rights to their users independently of your interaction, benefiting them and you.

Allowing business customers to handle role management themselves lets them work faster with less of your support. They don't need you to approve individual users on their behalf.

However, granting access is complex, and delegating it needs to be done safely. There are all kinds of pitfalls to worry about if you attempt to do it yourself. Bringing in external expertise is one way to ensure you get it right. In this guide, you'll learn how to simplify delegated access management and self-service.

## Why You Need Delegated Access Management and Self-Service

Delegating access management and providing self-service to your clients can help you in several situations. For example, often, you need highly granular role management, with permissions granted for specific projects and specific types of action. If you're working with staff in another organization, you can't easily manage this yourself.

If that organization has to go through your company every time it wants to change someone’s role or the data they have access to, it will take them time and slow their onboarding procedures, ultimately making working with you less attractive.

Delegating access management also helps mitigate insider threats. Farming out permissions may seem like a security risk, but you're really reducing the number of people that deal with any particular set of permissions. In addition, you're giving control to those that use them.

By reducing the amount of communication and the number of people involved, there's less chance for someone to leak information or act maliciously. And as your client base increases, so does the amount of admin involved in communication. The more you can automate or pass off to your clients, the better.

## How to Simplify Delegated Access Management and Self-Service with ZITADEL

There are several things to think about, when implementing delegated access management and providing self-service capabilities to your users, including roles and permissions, delegated role management, and service consolidation. 

ZITADEL allows you to do all of this and more, handling most of the heavy lifting for you. It makes delegated access management and self service simple. Its APIs integrate with your business processes letting you automate your clients services.

Let's take a more in-depth look at how it can help you:

### Roles and Permissions

There are many types of permission users need. In addition to viewing files or other resources, users may be allowed to create or edit documents or delete files. Furthermore, some users are allowed to grant these permissions to others. Any of these permissions can be limited to specific resource sets. 

To reduce complexity, permissions are often grouped into roles. Roles are a means of managing user access rights and usually come with a default set of permissions. Instead of figuring out exactly which permissions to give an individual, you can grant them a role instead. Your apps then associate permissions with roles, rather than individuals.
Authorizations state which users have which roles and are often referred to as user grants.



Though users are typically human, they can also include machine agents, known as service users. For example, if you use a service to sync databases, the service might access databases on another domain by logging in as a service user.

[ZITADEL](https://zitadel.com/docs/guides/manage/console/projects#grant-a-project) lets you grant selected roles to an organization. The organization can then create authorizations for its users independently, and this is referred to as self-service.

### Delegated Role Management

Delegating role management means you grant another group permission to assign or change roles. You don't need to grant all the permissions you have, but a limited selection allows you to create hierarchical relationships that don't require your involvement to administer.

A simple example of this role delegation would be in blogging software. Everyone has permission to view the blog. Editors get permission to make changes and grant rights to writers. Writers have permission to edit the documents they are assigned by the editors.

In this setup, there's no need to directly set people's individual permissions; you just assign them a role, and everything is taken care of by the software. Without roles, you’d have to select the specific actions available to each staff member.

However, if you're hosting blogging software for someone else, you need to provide them with permission to hand the roles to users. That could look something like the following:

<div className="dark:hidden">
  <img src="/blog/2022-11-24-delegated-access-management-and-self-service-01-light.png" alt="Image showing the relationship between the host company and blogging team, which gets delegated rights to grant users blog access courtesy of James Konik"></img>
</div>
<div className="hidden dark:block">
  <img src="/blog/2022-11-24-delegated-access-management-and-self-service-01-dark.png" alt="Image showing the relationship between the host company and blogging team, which gets delegated rights to grant users blog access courtesy of James Konik"></img>
</div>

Here, your client is granted rights to assign user roles and can create as many users as they like without having to go through you. You can grant whatever rights you want, granting more or less control depending on your use case.

### Managing Access Providers

There are many services providing authorization and authentication services. It can be hard to manage them all. With ZITADEL, you can enable and configure different services for each organization you work with.

With ZITADEL, you can implement [Auth0](https://auth0.com), [OmniAuth](/docs/guides/integrate/services/gitlab-self-hosted), and other kinds of access methods, such as [Keycloak](https://www.keycloak.org), [Azure Active Directory (Azure AD)](https://azure.microsoft.com/en-us/services/active-directory/), and Google through a single self-service platform.

You can enable single sign-on (SSO), too. SSO lets you access multiple services using a single login. ZITADEL lets you use protocols like [OpenID Connect](https://openid.net/connect/) to provide this functionality.

These options make ZITADEL an ideal way to bring your own identity (BYOI) capabilities to your customers. Combining service consolidation with delegate access management like ZITADEL ensures that your users have the flexibility they need when setting up their organization access rules.

Going through ZITADEL takes away the difficulty of managing multiple services, and the consistent interface means your users don't have to figure out all the different login types.

### Branding and Experience Customization

When dealing with [relationships between multiple organizations](/docs/guides/solution-scenarios/b2b), you need to decide how logins are handled. Do you use a default login screen or redirect users to one with a specific organization's branding?

With ZITADEL, you can configure these relationships on a case-by-case basis for different roles and companies. You can also easily create branding and add logos for each client. And of course, you can adjust it all without having to redevelop your site.

ZITADEL's [multi-tenancy support](/usecases) means you can sell your services to different companies and deliver the specific features they need. These can be tailored to their needs and perhaps support different service tiers that you offer.

As well as branding, different organizations can then use different rules, such as their password policies and multi-authentication requirements. It's easy to customize these using a centralized service provider.

### Benefits of Experience

Without experience in security, it's hard to keep up with the ever-changing technical and regulatory requirements. Given how risky mistakes are, it makes sense to bring in outside help.

Implementing delegated access management and self service is complex. When developing such services, it's easy to overlook this complexity. Many services implement authorization and authentication themselves, but as the scope widens to include delegated access management, this becomes an increasingly bad idea.

For nonspecialists, the chances of making a mistake are significant. The investment and maintenance requirements are also high and easy to underestimate.

By using an experienced service provider to handle these areas, you can focus on business logic and deliver a better product.

### Security Dangers

Small mistakes in authentication and authorization services can have dire consequences. Access control, identification, and authentication are all prominent in the [Open Web Application Security Project (OWASP)](https://owasp.org/www-project-top-ten/) top ten security risks. Hackers are getting ever more sophisticated, and a successful attack can be catastrophic for a business on the receiving end.

To try and prevent attacks as well as develop a secure system in the first place, you have to continually update it as new threats emerge.

You also have to deal with the evolution of your wider platform. Every time you add or change a feature, you risk undermining your existing security measures and opening up a vector of attack.

Using an external service to provide authentication and authorization means you have dedicated experts continually updating their platform to deal with the latest vulnerabilities.

Plugging into a mature system via an API lets you deliver an up-to-date, secure service without the need for continual development investment.

And there are even more issues to think about, including setting up security policies, limiting the impact of [DDoS attacks](https://www.geeksforgeeks.org/what-is-ddos-mitigation/), and configuring the various types of encryption needed to authenticate users. None of these are easy to do.

With authentication and authorization handled for you, your developers are free to focus on your core product. You can concentrate on providing features and evolving your own platform without the added overhead of providing auth to external organizations.

### Scaling

Scaling can create issues, as additional users and support for new platforms put your infrastructure under pressure. ZITADEL supports unlimited users and projects, meaning it won't become a bottleneck.

Simplifying your services through delegated access management means you can use specialized tools to handle authorization and authentication, and these dedicated services can be chosen with scaling in mind.

They also prevent your codebase from getting out of hand as the range of clients, roles, and permissions you handle grows. Carefully partitioning it into a separate service keeps yours leaner and easy to work with.

### Additional Features

Login policies are another way to give your clients control. These can be easily defined from ZITADEL's console. Login policies allow you to set authentication methods for your users and can be changed as your clients' needs evolve. They can do that without having to make code changes. You can also do this on an organizational level. For example, a SaaS provider can set different policies.

You can learn more about ZITADEL's feature set [on its website](/features).

## Conclusion

Access management is a complex topic. Managing permissions and granting access to the right people are enough of a challenge, but the changing security landscape and ever-increasing feature sets make it even harder to keep up.

Fortunately, there are alternatives to doing everything yourself. With the right support, you can provide your clients with self-service capability. In return, they get a wide range of features along with cutting-edge security. They also reduce their costs, letting them focus on what they do best.

[ZITADEL](/) 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 [James Konik](https://portal.draft.dev/writers/recYmhitHbB1gDQDA).*

Granting access is complex, and delegating it needs to be done safely. In this guide, you'll learn how to simplify delegated access management and self-service.

Simplify Delegated Access Management and Self-Service

When building a software program, the **technique of user authentication** is one of the crucial elements that developers must consider. Given the growing inclination of end users to validate their identity via an existing social account, it is unsurprising that an **increasing number of applications are incorporating the social login authentication** mechanism. However, since the preferred social network likely differs from user to user, and SSO provider likely differs from company to company, it is crucial for the app in question to **provide a broad selection of identity providers and authentication methods**. Unfortunately, doing so usually implies that the provider must individually integrate and manage every integration and contract, several times over.

Integrating multiple Identity Providers directly within your applications is **complex to maintain, time-consuming to set up, and hinders single sign-on of users** – In other words, **it does not scale**. Luckily, this problem can be easily solved with the help of an **Identity Broker**.

This article tackles the definition of an identity broker and what identity brokering looks like in practice.

## What does an Identity Broker do?

The term Identity Broker (IB) describes a web application that **facilitates authentication between service providers and their configured Identity Providers**.  By acting as a trusted intermediary service, an IB connects projects with different identity providers, so that **developers do not have to bother with integrating them individually** into their apps. With the help of its centralized way of managing identities, end-users have the option to create a new account by **using the identity data acquired from several identity sources** (such as Google, Facebook, Twitter, etc.). An IB may also allow you to link multiple external identity providers to one user account. Thus, the implementation of social logins, other alternate authentication methods and the configuration of individual login policies are made easier than ever.

It is common for organizations to integrate their applications with a **cloud-based identity management platform** (such as ZITADEL), which can broker to many different identity providers out of the box, usually based on protocols such as [SAML, OIDC](https://zitadel.com/blog/saml-vs-oidc) and OAuth. By relying on the identity provided by such pre-configured services, you have ensured a **robust trust anchor** for all your applications and devices.

## Identity Brokering in Practice

With the theory out of the way, it is useful to see how identity brokering functions in practice.

Identity Brokering is generally used in both **Business-to-Customer (B2C, CIAM) and Business-to-Business (B2B)** use cases. For B2C businesses it is vital for vendors to **offer different social identity providers, authentication methods and login policies** to best fit the needs of their end-users. Vendors of B2B software may need to provide enterprise SSO by allowing login with the customer’s identity provider (eg, Azure AD) and tailor security policies to fit their customer’s requirements. 

Alternatively, Identity Brokering can be used in **Government-to-Business (G2B) as well as Government-to-Citizen (G2C) cases**. The principle in these cases is the same as in the Business-to-X context, the **role of the business is simply replaced with a government institution/agency** (such as banks, legislatures, etc.). For instance, Australian users with a registered MyGovID may use this identity to access a range of government online services (such as student and health data portals), instead of having to rely on usernames and passwords.

Regardless of the use case, the process of identity brokering follows the same simple steps. As an example, let us imagine **an organization called “Gladix” that uses ZITADEL as a broker**:



![](/blog/2022-09-10-ib-01.png)

The application of Gladix has Google pre-configured as an identity provider. Accordingly, their end-users will get the **option to link their existing or new ZITADEL account with their Google account** by clicking on the “Google” symbol on ZITADEL’s login screen. Upon doing so, ZITADEL will **redirect the end-user to the login screen of Google** where they must authenticate themselves and then, if successful, they are directed back to the previous page. Following this authorization, the **end-user will be able to login into ZITADEL, and subsequently Gladix’s application, by using their Google identity**.

Integrating multiple Identity Providers directly within applications is complex to maintain, time-consuming to set up, and hinders single sign-on of users. Luckily, this problem can be easily solved with the help of an Identity Broker.

What is an Identity Broker? - Everything you need to know 

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

How to secure your Java application with OpenID Connect

If you have ever been uncertain whether a word is spelled correctly, a feature that automatically detects typos can be a lifesaver. Whereas a seemingly innocent spell-checking tool might not raise any red flags, **convenience and confidentiality are regrettably not always compatible online**.

This unpleasant side of spellchecking tools was exposed by a **recent incident involving Google Chrome and Microsoft Edge**. Both browsers’ enhanced spell-check features **send any data that is entered into form fields to Google and Microsoft**. Accordingly, the exposed information might include your **name, phone number, address and even your password**.

This article explains the privacy shortcomings of Chrome’s Enhanced Spellcheck and Edge’s MS Editor and what you can do to keep your data safe.

## The risks of these tools

You may already be familiar with Chrome and Edge's basic spell-checking tools, which are enabled by default and often go unnoticed by users. Luckily, **these built-in tools are nothing to worry about**. However, **both browsers offer "enhanced" spell-checking alternatives** that can identify misspelled words more accurately, thanks to the significantly higher amount of data they have at their disposal. While this statement about the tool’s higher accuracy may be true, it does beg the question of **where all this additional data comes from**. The answer is simple: from **everyone who has Enhanced Spellcheck, or MS Editor enabled**.

By enabling these features, **you simultaneously authorize the browsers to transmit the information you enter into form fields to their respective companies** (Google and Microsoft). Although this transmission of your data is a well-intended function of these tools, it still raises concerns about the fate of the forwarded information and how safe this practice is.

These worries were proven legitimate when [Otto Javascript Security (otto-js)](https://www.otto-js.com/news/article/chrome-and-edge-enhanced-spellcheck-features-expose-pii-even-your-passwords) recently exposed the concerning extent of information these spell-check functions extract from their users: The tools have the **potential to reveal personally identifiable information (PII)** from some of the most popular platforms and applications (such as Office 365, Google Cloud and Alibaba). Therefore, this phenomenon, often called **spelljacking**, **offers a severe security risk to your sacred data**, including your full name, date of birth, social security number, payment details, and passwords.

## How to protect your data

While a person exposing your data without your consent is frightening, **luckily, there are some measures you can take to protect yourself from spelljacking**.

### Disable Enhanced Spellcheck and MS Editor

While a specialized spellchecker is a handy tool for writing all kinds of texts, **given the security flaws discovered in Enhanced Spellcheck and MS Editor, it is** **recommended to use an alternative instead**, at least until the developers figure out a way to address these issues.

Thus, one of the most obvious ways to protect yourself from having your personal information sent to Microsoft and Google is to **disable the Enhanced Spellchecker**. Luckily, this is an effortless procedure that can be done via Chrome’s settings. Simply navigate to chrome://settings/syncSetup and uncheck the box labeled “Enhanced Spellcheck.”

![](/blog/2022-10-10-enhanced-spellcheck-01.gif)

**Uninstalling MS Editor on Microsoft Edge is equally simple**. By navigating to the [tool’s page on Edge-Add-Ons](https://microsoftedge.microsoft.com/addons/detail/microsofteditor-rechtsc/hokifickgkhplphjiodbggjmoafhignh), you can easily remove it by clicking on the blue button next to its name.

## Use passwordless login methods to protect your account

The most foolproof way of protecting your password is simply not having one. Accordingly, it is strongly advised to **confirm your identity via a passwordless method** (such as Biometrics, a physical token, or a One-time-password) whenever a platform allows you to do so. While this measure alone does not keep the enhanced spell-checking tools from transmitting all the other information you enter into form fields, at least your account remains safe from unwanted access.

Whereas a seemingly innocent spellchecker might not raise any red flags, convenience and confidentiality are regrettably not always compatible online. This article explains the privacy shortcomings of Chrome’s Enhanced Spellcheck and Edge’s MS Editor and what you can do to keep your data safe.

Your Spellchecker Might Have Leaked Your Passwords

*“In what city were you born? What was your first job? Where did you meet your spouse?”* Every person who has an online account to use services or apps **has inevitably had to come up with answers to security questions**.

![](/blog/2022-09-29-security-questions-01.gif)

In theory, they seem to be a great invention: Before you request a new password for your account, the platform must **confirm your identity by asking you to recall the answer to a confidential question you have configured upon registration**. There is, however, a significant hole in the logic of this security measure: Generally, the questions are **ridiculously shallow**.

Obviously, you know your mother’s maiden name - but so do your family members, friends, old teachers, ex-partners, and even the staff at your birth hospital. This ironic genericness of these supposedly confidential security questions prompts a reasonable thought: If a **random word or name used as a password already takes hackers less than a minute to guess**, what does that tell us about the safety of a **keyword that is not even random, but a direct answer to a simply searchable question**?

This article discusses the **shortcomings of security questions as a protection measure and what you can do to make them stronger**.  

## The risks of security questions

If you have ever heard of the **dangers of simple and reused passwords**, you might find that common security questions pose a threat for eerily similar reasons: Sometimes, **one lucky guess is all it takes for your data to fall into the wrong hands**. Upon gaining access to your account, the criminal is free to **exploit your sensitive information in any way they see fit**: Whether the attacker intends to commit identity theft, obtain your payment information, or hijack your account, any attack on your account could lead to devastating consequences.

In the following few paragraphs, we elaborate on the most important reasons why these questions are deemed unfit for protecting your data.

### Easy to guess

One of the most common criticisms security questions face is the false promise that they inquire about confidential information. In reality, they are nothing short of **vague and generic facts** that are even likely to be **identical amongst multiple users**.

According to research by Google, just a **single estimate could accurately predict an English-speaking user’s favorite** **food** with 20% accuracy. Similarly easy to deduce are the parents' middle names of Spanish-speaking users and the cities of birth of Korean users. Furthermore, the rates of accurate guesses **increase significantly for questions with only a few plausible answers**, such as “who is your favorite superhero” or “what is your favorite color?”.

At first glance, these probability rates might not seem too alarming, but remember that the previously mentioned statistics only apply to the success rate of a single guess. Accordingly, these numbers **exponentially increase with each additional guess** the platform allows. Ultimately, **most questions can be cracked in [10 attempts or less](https://www.engadget.com/2015-05-25-google-security-question-study.htmlhttps://www.engadget.com/2015-05-25-google-security-question-study.html)**.

### Easy to look up

It might surprise you how much information you can discover about someone by simply **scrolling through their social media profile**; their hometown, old elementary school, pet’s name – all of which are **coincidentally the subjects of the most common security questions**. While a seemingly obvious solution to this problem would be to keep our data private on social networks, unfortunately, inference attacks allow approximating sensitive information from a user’s friends.

Moreover, social media is not the only platform where your information may be accessible: As an example, [at least 30%](https://research.google.com/pubs/pub43783.html) of Texas citizens' mothers' maiden names may be inferred from **public birth and marriage records**.

### Social Engineering

Another common method attackers may use to get a hold of the answers to your security questions is to **simply ask you**. Of course, this manipulative exploitation technique, also known as social engineering, does not involve the criminal literally asking you to give them access to your sacred information: In reality, this process is often **so subtle, that you might not even notice the malicious intent behind the conversation**.

But how is this possible? Simply put, **humans are naturally inclined to trust people** they deem harmless, which is unfortunately a trait ill-wishers can easily use to their advantage. Accordingly, when engaging in casual banter with a nice person you matched with on a dating app, it might not seem out of the ordinary if they ask you where you are from. However, what you do not know is that this **small piece of information might have just been the key the hacker needed** to gain access to your networks and accounts.

Additionally, it is worth mentioning that the malicious method of social engineering is **not limited to the cyber-world** either; evidently, people might be even less vary of a seemingly harmless converation, when the second party is standing right in front of them. 

Whether the attack is carried out within the framework of a face-to-face interaction or online, the conclusion always remains the same: **The victim shares the needed information or exposes themselves to malware.** 

### Obtainable via a data breach

Sometimes, accessing the answer to your security question **does not require a tactical guess or lengthy research**; akin to passwords, phone numbers, and other personal information, security questions can get stolen within the framework of a data breach.

An attacker obtaining your security answers is especially a risky, since **thousands of platforms are known to recycle the same couple questions with little to no variety**. Thus, answering the same questions across multiple social identities may allow attackers to seamlessly access every account with an identical pre-configured query. 

## Making security questions safer

### Fake Answer

A seemingly obvious solution to the searchability issue is simply using a **made-up answer** to your selected security question, **which other people cannot verify**. Whether you want to type out the alphabet as your phone number or give your mother a fake name, **the level of obscurity is yours to pick**.

However, it is worth noting that **this method only works if you can actually remember the fake answer you came up with**. Given that [40%](https://www.securityweek.com/security-questions-dont-offer-much-protection-web-users-may-hope-research) of English-speaking U.S. users could not even recall their truthful question answers on demand, it is safe to assume that **remembering a made-up one would be even less convenient**.

Furthermore, made-up answers sometimes ironically end up being equally easy to guess since **many individuals** **attempt "harden" their responses in a predictable manner**. This phenomenon is primarily a result of individuals being forced to think of a random word on the fly, which usually ends up being **a common term they have frequently heard.** Thus, merely switching from "red" to "blue" as your favorite color will not be worthwhile.

### Honest Answer - With a twist

To reduce the probability of you forgetting a fake answer, you could instead just **add some little tweaks to a genuine one** – similar to what you would do with a weak password. For example, instead of your favorite food simply being “pizza,” it could be “Pizza123!”. While this answer is undoubtedly harder to crack, you must **still make an effort to remember the extra characters you added** to make this protection measure effective.

### Custom question

If the platform allows you to do so, **writing your own security question** can be a viable way to make your account more secure. Provided that the self-written query is less generic than the selectable ones, of course.

To make sure your custom security question fulfills its duty, it is **recommended for them to meet the following five [criteria](https://goodsecurityquestions.com/):**  

* Safe: cannot be guessed or researched
* Stable: does not change over time (f.e. your favorite song)
* Memorable: something you can easily recall
* Simple: is precise, easy, consistent
* Many: has many possible answers

### Ditching security questions completely

Whether you get your account hacked because your question was too simple or you cannot access your own account anymore because you forgot the made-up answer, using security questions is not exactly the pinnacle of user experience. Fortunately, **more and more platforms are starting to realize the flaws of this outdated protection mechanism**.  

While security questions are slowly becoming obsolete, **the concept of secure account recovery is still as crucial as ever**. Hence, more and more superior alternatives are emerging that can replace not only security questions but also knowledge factor-reliant authentication systems (f.e. passwords) altogether. To ensure more robust protection of your account, you might want to **consider using one of the following [passwordless](https://zitadel.com/blog/passwordless) options for authentication or account recovery** whenever they are available:

* **Possession factors:** An object, such as USB Devices (FIDO2-compliant keys), physical tokens, or your smartphone
* **Biometrics:** Physical traits (f.e. Fingerprint scanning or Face-ID) or other characteristics, such as voice recognition
* **One-Time-Passwords:** A code sent via text message or an authentication app

Discussing the shortcomings of security questions as a protection measure and what you can do to make them stronger.

Why Security Questions Are Useless And Unsafe


[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.

Blog.