| title |
|---|
B2C |
import Column from '../../../src/components/column';
Users in general come from different domains. You may have customers, employees, or even customers from other parties (B2B). This groups of users usually don't share the same intentions and use applications differently. When planning your applications, investing time in reserching your apps architecture is vital for later feature upgrades and enhancements as those changes come in with heftier pricepoints if you have to make bigger changes.
This guide introduces you to the grouping and structuring of ZITADEL projects which forms the base for all projects. This can be used as a quickstart to the B2B scenario, which is merely focused on planning considerations if you are having projects with multiple organizations (Multitenancy).
The journey of this guide starts with creating an Organization, the outermost layer of ZITADEL, as it is, its vessel for projects, roles, applications and users. Creation can be done from ZITADEL Console. You can choose your current account for the organization owner or create a new one.
Depending on your Software Development Life Cycle (SDLC) you will have to create multiple organizations to keep your data from different environments seperate.
| Environment | Organization Name | Description |
|---|---|---|
| Development | acme-dev | The development environment and organization |
| Testing | acme-test | An environment for testing and production preview |
| Production | acme-prod | The production environment and organization |
Right after org creation you'll be greeted which the domain section of your organization. ZITADEL automatically creates a custom domain of the form [orgname].zitadel.ch, but you can set your own by saving a verification file on the specified location.
We recommend that you create your domains early as they create a sense of confidence and trust for your application.
You can read more about how ZITADEL handles usernames here.
Independent to the fact if you are migrating an existing dataset of users into ZITADEL or if your starting a project from scratch, you should define how users get signed up into your application. ZITADEL supports signup with OIDC Identity providers as well as JWT Identity Providers. On signup, ZITADEL imports user information to the own profile. ZITADEL gives you a basic storage of the user and manages phone and email addresses, but also gives you the option to store your own application data such as preferences or external identifiers to the metadata of a user.
If you are migrating an existing project and you already have an external identity store you can consider bulkimporting your user datasets. Read our Management API definitions for more info. If the users email is not verified or no password is set, a initialization mail will be send.
:::info Requests to the management API are rate limited. Read our Ratelimit Policy for more info. :::
The process of verifying a users identity is called User Authentication and is required in order for your users to access applications. User Authentication can be performed in multiple ways. Default method in ZITADEL is username and password. ZITADEL allows you to configure Multifactor Authentication and Passwordless in order to enhance security for your users. All methods including Identity Providers and Passwordless Authentication are starting from FREE Tier. To setup your personal login policy, go to your organizations detail in Console.
When planning your application consider the following questions about User Authentication:
- What are the methods to authenticate your users?
- Where will your users enter their credentials?
- Do you offer password authentication?
- What do you do to keep your users credentials safe?
- Do you offer Multifactor Authentication?
- Do you offer Login via Identity Provider?
- Which languages do you have to provide?
When looking at this questions, you may have to admit that building an Identity Management System is much more complex and complicated than you thought initially and implementing if yourself may be too much work. Particularly because you should focus on your own applications business.
ZITADEL offers a secure by default approach and comes with a Hosted Login which is a fixed endpoint for your users to authenticate. It's safe and secure and comes with Multifactor, Federated Login and Passwordless. OIDC (OpenID Connect) opens the doors Single Sign On (SSO). Especially if you have more than one application, you may want a central and familiar authentication experience. With SSO, ZITADEL provides a seamless experience across all your apps.
Branding and customization is a very important part of your application. With ZITADEL you can modify colors, logos, icons as well as configure your typography styles, such that you can provide a consitent design thoughout your applications. In addition to visual modifications, you can edit notification texts for your users. ZITADEL gives you handlebar similar templating for variables. Of course you can define texts for any language. We'd appreciate if you could contribute to our repo with translations of your language. Read on how to contribute here.
Note that your console design changes to your design too
As our Hosted Login is a seperate authentication screen, you have to determine how you are directing your users from your applications. ZITADELs Applications live under ZITADELs Projects. You may add multiple Applications for your different apps (Native, Web, User Agent, or API). When setting up you applications consider reading our guide about Authentication Flows.
By having authenticated a user you need to ensure users and services have access to your application and APIs. This process is called Access Control and comprises User Authentication, Authorization and Policy Enforcement. Take the following considerations:
- Does your application call your own APIs?
- Does your application need to call third-party APIs?
- Do you offer an API for third-party applications?
The data required to check if a user has access to a certain API is stored within a user grant. This information typically is stored within roles or custom claims and can be accessed with an access or OIDC id token.
...
...