andwati/zitadel
1
0
Fork 0
mirror of https://github.com/andwati/zitadel.git synced 2026-11-08 07:05:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: fixed some typos, formatting, grammar (#11540)

Browse Source 
# Which Problems Are Solved

- Typos
- Punctuation
- Markdown table formatting
- ...

(A bunch of issues my editor gave)

# How the Problems Are Solved


# Additional Changes


# Additional Context
This commit is contained in:
Wim Van Laer
2026-02-13 07:45:17 +01:00
committed by GitHub
parent b0609aa861
commit 9b064d8b74
127 changed files with 764 additions and 760 deletions
Download Patch File Download Diff File Expand all files Collapse all files
apps/docs/content/concepts/architecture/software.mdx
+7 -7
View File
@@ -17,7 +17,7 @@ This All in One (AiO) approach makes operating Zitadel simple.
## The Architecture
Zitadels software architecture is built around multiple components at different levels.
Zitadel's software architecture is built around multiple components at different levels.
This chapter should give you an idea of the components as well as the different layers.
![](../../../public/img/zitadel_software_architecture.png)
@@ -63,7 +63,7 @@ The Command Side has some unique requirements, these include:
The command handler receives all operations who alter a resource managed by Zitadel.
For example if a user changes their name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
The command handler is then responsible of creating the necessary commands.
The command handler is then responsible for creating the necessary commands.
After creating the commands the command hand them down to the command validation.
##### Command Validation
@@ -76,7 +76,7 @@ These events now are being handed down to the storage layer for storage.
#### Events
Zitadel handles events in two ways.
Events that should be processed in near real time are processed by a in memory pub sub system.
Events that should be processed in near real time are processed by an in memory pub sub system.
Some events can be handled asynchronously using the spooler.
##### Pub Sub
@@ -103,7 +103,7 @@ Spoolers are especially necessary where someone can query datasets instead of si
#### Projections
Projections are responsible of normalizing data for the query side or for analytical purpose.
Projections are responsible for normalizing data for the query side or for analytical purpose.
They generally work by being invoked either through a scheduled spooler or the pub sub subscription.
When they receive events they will create their normalized object and then store this into the query view and its storage layer.
@@ -122,10 +122,10 @@ It has some unique requirements, which include:
##### Query Handler
The query handler receives all read relevant operations. These can either be query or simple `getById` calls.
The query handler receives all read relevant operations. These can either be queries or simple `getById` calls.
When receiving a query it will proceed by passing this to the repository which will call the database and return the dataset.
If a request calls for a specific id the call will, most of the times, be revalidated against the Event Store.
This is achieved by triggering the projection to make sure that the last sequence of a id is loaded into the query view.
If a request calls for a specific id the call will, most of the time, be revalidated against the Event Store.
This is achieved by triggering the projection to make sure that the last sequence of an id is loaded into the query view.
> The query side has the option to dynamically check the Event Store for newer events on a certain id to make sure for consistent responses without delay.
apps/docs/content/concepts/eventstore/implementation.mdx
+38 -38
View File
@@ -9,36 +9,36 @@ The goal is to give you a rough overview, so you know where which data is stored
## Event
The single source of truth of ZITADEL are the events that are stored in the eventstore.
From these events all different kind of resources e.g Users, Projects, Applications, etc. can be computed.
From these events all different kind of resources e.g. Users, Projects, Applications, etc. can be computed.
An event has the following data:
| Attribute | Description | Example |
| --- | --- | --- |
| id | unique identifier of the event, this is generated by the database | b6402a60-e4655-4cc0-904b-f5c6760c4406 |
| aggregate_type | the type of the aggregate, an aggregate can be compared to a resource or an object. One aggregate contains multiple event types | user |
| aggregate_id | The unique identifier of an aggregate, this is generated by ZITADEL and is a sonyflake id | 168096909691353697 |
| aggregate_version | The aggregate version shows in which version of the aggregate the event was created. This is needed to be able to compute correct objects | v1 |
| event_type | The type of the event | user.human.added |
| event_sequence | The event sequence is a sequence number that is incremented by one for each event on the instance. For technical reasons, a number can be omitted in some cases. This is needed so that the sequence of the events can be ensured. | 1234 |
| previous_aggregate_sequence| This number is the sequence of the event last created on this specific aggregate. E.g. Last user with specific aggregate_id | 1233|
| previous_aggregate_type_sequence | This number is the sequence of the event last created on this aggregate. E.g Last User | 1230 |
| creation_date| timestamp when the event was created | 2022-07-05 13:57:56.358774+00 |
| editor_user| The editor user contains mostly an unique identifier of a user. And tells who did the request that led to this event. Sometimes this can also be a name of a system within ZITADEL. | 165460784409638965, NOTIFICATION, LOGIN |
| editor_service | The service defines which API was called when the event got created. If the event was created from the system itself this is empty. | Admin-API |
| resource_owner | The resource owner defines to which organization/resource_owner the event belongs. This is an id generated by ZITADEL as sonyflake id | 168051083313153168 |
| instance_id | ZITADEL is capable of containing multiple ZITADEL instances withing the system. This id is the unique identifier of the Instance and is generated by ZITADEL as sonyflake id. | 165460784409737865 |
| Attribute | Description | Example |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|
| id | unique identifier of the event, this is generated by the database | b6402a60-e4655-4cc0-904b-f5c6760c4406 |
| aggregate_type | the type of the aggregate, an aggregate can be compared to a resource or an object. One aggregate contains multiple event types | user |
| aggregate_id | The unique identifier of an aggregate, this is generated by ZITADEL and is a sonyflake id | 168096909691353697 |
| aggregate_version | The aggregate version shows in which version of the aggregate the event was created. This is needed to be able to compute correct objects | v1 |
| event_type | The type of the event | user.human.added |
| event_sequence | The event sequence is a sequence number that is incremented by one for each event on the instance. For technical reasons, a number can be omitted in some cases. This is needed so that the sequence of the events can be ensured. | 1234 |
| previous_aggregate_sequence | This number is the sequence of the event last created on this specific aggregate. E.g. Last user with specific aggregate_id | 1233 |
| previous_aggregate_type_sequence | This number is the sequence of the event last created on this aggregate. E.g Last User | 1230 |
| creation_date | timestamp when the event was created | 2022-07-05 13:57:56.358774+00 |
| editor_user | The editor user contains mostly an unique identifier of a user. And tells who did the request that led to this event. Sometimes this can also be a name of a system within ZITADEL. | 165460784409638965, NOTIFICATION, LOGIN |
| editor_service | The service defines which API was called when the event got created. If the event was created from the system itself this is empty. | Admin-API |
| resource_owner | The resource owner defines to which organization/resource_owner the event belongs. This is an id generated by ZITADEL as sonyflake id | 168051083313153168 |
| instance_id | ZITADEL is capable of containing multiple ZITADEL instances withing the system. This id is the unique identifier of the Instance and is generated by ZITADEL as sonyflake id. | 165460784409737865 |
## Schemas
| Schema | Description | Examples |
| --- | --- | --- |
| System | The system contains everything that is needed outside the ZITADEL instances. | assets, encryption_key |
| Eventstore | Eventstore is the base of ZITADEL and is the single source of truth. All the events stored in the eventstore can be used to generate different projections. | events, instance sequences, system wide unique constraints
| Projections| The projections contain all the computed objects which are used for reading requests. | users, projects, etc|
| Auth | This contains projections which are used for the auth api. All projections in this schema should be moved to Projections soon | users, auth_request, etc. |
| Adminapi | This contains projections which are used for the admin api. All projections in this schema should be moved to Projections soon | styling|
| Notification | This contains projections which are used for sending notification. All projections in this schema should be moved to Projections soon | styling|
| Schema | Description | Examples |
|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------|
| System | The system contains everything that is needed outside the ZITADEL instances. | assets, encryption_key |
| Eventstore | Eventstore is the base of ZITADEL and is the single source of truth. All the events stored in the eventstore can be used to generate different projections. | events, instance sequences, system wide unique constraints |
| Projections | The projections contain all the computed objects which are used for reading requests. | users, projects, etc |
| Auth | This contains projections which are used for the auth api. All projections in this schema should be moved to Projections soon | users, auth_request, etc. |
| Adminapi | This contains projections which are used for the admin api. All projections in this schema should be moved to Projections soon | styling |
| Notification | This contains projections which are used for sending notification. All projections in this schema should be moved to Projections soon | styling |
## Projections
@@ -64,13 +64,13 @@ You can find the current sequence in the following tables:
The current sequence is stored for each ZITADEL instance and table.
| Attribute | Description | Examples |
| --- | --- | --- |
| projection_name | The name of the projection for which the sequence is valid. | projection.users |
| aggregate_type | The aggregate type where the sequence was from | user |
| current_sequence | The sequence that was last processed | 1234 |
| instance_id | The instance to which the event belongs | 165460784409737834 |
| timestamp | Timestamp when the table was updated | 2022-07-05 13:57:59.454798+00 |
| Attribute | Description | Examples |
|------------------|-------------------------------------------------------------|-------------------------------|
| projection_name | The name of the projection for which the sequence is valid. | projection.users |
| aggregate_type | The aggregate type where the sequence was from | user |
| current_sequence | The sequence that was last processed | 1234 |
| instance_id | The instance to which the event belongs | 165460784409737834 |
| timestamp | Timestamp when the table was updated | 2022-07-05 13:57:59.454798+00 |
### Failed Events
@@ -85,10 +85,10 @@ You can find the failed_events in the following tables:
- auth.failed_events
- adminapi.failed_events
| Attribute | Description | Examples |
| --- | --- | --- |
| projection_name | The name of the projection for which the failed event should have been processed. | projection.users |
| failed_sequence | The sequence of the event that failed | 1234 |
| failure_count | The number of times the event was attempted to be processed. If the number is lower than the max. attempts the event could be processed, but not on the first attempt | 5 |
| error | The error message that occurred when the event could not be processed | User not found |
| instance_id | The instance to which the event belongs | 165460784409737834 |
| Attribute | Description | Examples |
|-----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------|
| projection_name | The name of the projection for which the failed event should have been processed. | projection.users |
| failed_sequence | The sequence of the event that failed | 1234 |
| failure_count | The number of times the event was attempted to be processed. If the number is lower than the max. attempts the event could be processed, but not on the first attempt | 5 |
| error | The error message that occurred when the event could not be processed | User not found |
| instance_id | The instance to which the event belongs | 165460784409737834 |
apps/docs/content/concepts/features/audit-trail.mdx
+6 -6
View File
@@ -3,16 +3,16 @@ title: ZITADEL's In-built Audit Trail
sidebar_label: Audit Trail
---
ZITADEL provides you with an built-in audit trail to track all changes and events over an unlimited period of time.
Most other solutions replace a historic record and track changes in a separate log when information is updated.
ZITADEL only ever appends data in an [Eventstore](/concepts/eventstore/overview), keeping all historic record.
ZITADEL provides you with a built-in audit trail to track all changes and events over an unlimited period of time.
Most other solutions replace a historical record and track changes in a separate log when information is updated.
ZITADEL only ever appends data in an [Eventstore](/concepts/eventstore/overview), keeping all historical record.
The audit trail itself is identical to the state, since ZITADEL calculates the state from all the past changes.
![](../../../public/img/concepts/audit-trail/audit-log-events.png)
This form of audit log has several benefits over storing classic audit logs.
You can view past data in-context of the whole system at a single point in time.
Reviewing a past state of the application can be important when tracing an incident that happened months back. Moreover the eventstore provides a truly complete and clean audit log.
Reviewing a past state of the application can be important when tracing an incident that happened months back. Moreover, the eventstore provides a truly complete and clean audit log.
<Callout title="Future Plans">
There will be three major areas for future development on the audit data
@@ -28,7 +28,7 @@ There will be three major areas for future development on the audit data
### Last changes of an object
You can check the last changes of most objects in the [Console](/guides/manage/console/console-overview).
In the following screenshot you can see an example of last changes on an [user](/guides/manage/console/users-overview).
In the following screenshot you can see an example of last changes on a [user](/guides/manage/console/users-overview).
The same view is available on several other objects such as organization or project.
![](../../../public/img/guides/console/myprofile.png)
@@ -42,7 +42,7 @@ Go to your default settings and then click on the Tab **Events** to open the Eve
### Event API
Since everything that is available in Management Console can also be called with our APIs, you can access all events and audit data trough our APIs:
Since everything that is available in Management Console can also be called with our APIs, you can access all events and audit data through our APIs:
- [Event API Guide](/guides/integrate/zitadel-apis/event-api)
- [API Documentation](/reference/api/admin)
apps/docs/content/concepts/features/identity-brokering.mdx
+5 -5
View File
@@ -3,7 +3,7 @@ title: Identity Brokering
sidebar_label: Identity Brokering
---
Link social logins and external identity providers with your identity management platform allowing users to login with their preferred identity provider.
Link social logins and external identity providers with your identity management platform allowing users to log in with their preferred identity provider.
Establish a trusted connection between your central identity provider (IdP) and third party identity providers.
@@ -26,7 +26,7 @@ A service provider that specializes in brokering access control between multiple
Federated identity management is an arrangement that is made between two or more such identity brokers across organizations.
For example, if Google is configured as an identity provider in your organization, the user will get the option to use his Google Account on the Login Screen of ZITADEL.
Because Google is registered as a trusted identity provider, the user will be able to login in with the Google account after the user is linked with an existing ZITADEL account (if the user is already registered) or a new one with the claims provided by Google.
Because Google is registered as a trusted identity provider, the user will be able to log in with the Google account after the user is linked with an existing ZITADEL account (if the user is already registered) or a new one with the claims provided by Google.
![](../../../public/img/concepts/features/identity-brokering.png)
@@ -41,9 +41,9 @@ The schema is a very simplified version, but shows the essential steps for ident
## Is single-sign-on (SSO) the same as identity brokering?
Sometimes single-sign-on (SSO) and login with third party identity providers is used interchangeably.
Typically SSO describes an authentication scheme that allows users to log in once at a central identity provider and access service providers (client applications) without to login again.
Typically, SSO describes an authentication scheme that allows users to log in once at a central identity provider and access service providers (client applications) without having to login again.
Identity brokering describes an authentication scheme where users can login with external identity providers that have a established trust with an identity provider which facilitates the authentication for the requested applications.
Identity brokering describes an authentication scheme where users can log in with external identity providers that have an established trust with an identity provider which facilitates the authentication for the requested applications.
The connection between the two lies in how SSO can be implemented as part of an identity brokering solution.
In such cases, the identity broker uses SSO to enable seamless access across multiple systems, handling the complexities of different authentication protocols and standards behind the scenes.
@@ -52,7 +52,7 @@ This allows users to log in once and gain access to multiple systems that the br
## Multitenancy and identity brokering
In a multi-tenancy application, you want to be able to configure an external identity provider per tenant.
For example some organizations might use their EntraID, some other want to login with their OKTA, or Google Workspace.
For example some organizations might use their EntraID, some other want to log in with their OKTA, or Google Workspace.
Using an identity provider with strong multitenancy capabilities such as ZITADEL, you can configure a different set of external identity providers per organization.
apps/docs/content/concepts/principles.mdx
+1 -1
View File
@@ -8,7 +8,7 @@ title: Principles
- Embrace stateless application design
- System of records is the event store
- Everything else needs to be able to be regenerated
- Try not so solve complex problems outside of the IAM Domain
- Try not to solve complex problems outside the IAM Domain
- Use a scalable storage for the event store and read models
- Try to be idempotent whenever possible
- Reduce necessity of external systems or dependencies as much as possible
apps/docs/content/concepts/structure/instance.mdx
+2 -2
View File
@@ -8,7 +8,7 @@ sidebar_label: Instances
An instance is the top node in ZITADEL's data hierarchy.
Within an instance all the default [settings](/concepts/structure/policies),
such as branding, login policy, password policy, etc. for the system can be configured.
One instance normally runs on one domain and represents one issuer (e.g login.customer.com).
One instance normally runs on one domain and represents one issuer (e.g. login.customer.com).
One instance can contain multiple [organizations](/guides/manage/console/organizations-overview),
which in turn can represent your own company (e.g. departments), your business customers or a consumer organization.
@@ -25,7 +25,7 @@ You will find more detailed explanations around the different concepts in the fo
ZITADEL has the concept of virtual instances.
When installing ZITADEL from scratch, one instance is always automatically created for you.
Nevertheless, you can add more virtual instances via the [system API](/reference/api/system).
This is useful if you have business customers, which in turn have their business customers with self service and Custom Domain demands.
This is useful if you have business customers, which in turn have their business customers with self-service and Custom Domain demands.
By providing a virtual ZITADEL instances, your customers have all the customization options available in ZITADEL.
Scaling ZITADEL instances virtually enables you to easily distribute your limited compute resources to all your customers.
apps/docs/content/concepts/structure/users.mdx
+3 -3
View File
@@ -19,9 +19,9 @@ Read more on how to [login users with ZITADEL](/guides/integrate/login/login-use
### Service users
Service users are for machine-to-machine communication and you would use those typically to access secure backend services.
Service users are for machine-to-machine communication, and you would use those typically to access secure backend services.
For example in ZITADEL you would require an authenticated Service User to access the Management API.
The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via an login prompt, but service accounts require a non-interactive logon process.
The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via a login prompt, but service accounts require a non-interactive logon process.
Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL.
@@ -33,7 +33,7 @@ A user with an administrator role is not only an end-user of ZITADEL but can als
### Federated users
Federated users are identities that are managed by a third-party identity provider.
Users can login via an external identity provider, using [identity brokering](../features/identity-brokering) ("Single-sign-on").
Users can log in via an external identity provider, using [identity brokering](../features/identity-brokering) ("Single-sign-on").
Federated user [accounts are linked](../features/account-linking) to internal users to be able to assign roles and keep an audit trail.
### External users