mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-19 14:12:52 +00:00
d8ea041c56
## Todos for release - [x] Configure Env in docs project on vercel - [x] Configure Root Path in the docs project on vercel - [ ] Remove old CSP https://github.com/zitadel/website/pull/1592 ## What we did This pull request migrates the project documentation from the old `docs/` directory to the new `apps/docs/` directory, introduces a new documentation system built with Next.js and Fumadocs, and updates all relevant references, configuration files, and documentation to reflect this change. It also adds new configuration and ignore files for the new documentation app, updates CI and linting to exclude the new docs from certain checks, and revises the contributing guidelines accordingly. **Documentation System Migration and New Docs App** * Migrated all documentation from `docs/` to `apps/docs/`, and updated all references in `README.md`, `CONTRIBUTING.md`, and other files to point to the new location. [[1]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L585-L640) [[2]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L660-R607) [[3]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L740-R687) [[4]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L2-R3) [[5]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L30-R30) * Added a new Next.js/Fumadocs-based documentation app under `apps/docs/`, including core app files, layouts, routing, search API, and a comprehensive `README.md` with development and contribution instructions. [[1]](diffhunk://#diff-5a1b07344a2c1b4d3f37b23ff1388b62cd9f57dea3c1cd23d8a0412b7602b132R1-R74) [[2]](diffhunk://#diff-462b9ad1eabbb7d1c29bb9c36e4931eb180fd7190900e6d2babf8f4d66ad1c28R1-R39) [[3]](diffhunk://#diff-e16ae25660ded787b10ac35dea96d5ecaacf895dae0afc8a9bd4382dc79a8c87R1-R7) [apps/docs/app/[[...slug]]/layout.tsxR1-R81](diffhunk://#diff-59e08acde4e805b7aeccef1dcf98f1d71dfc550777e6b9402085cee0e9fa4e0aR1-R81), [apps/docs/app/[[...slug]]/page.tsxR1-R79](diffhunk://#diff-e5df3f80d0fa01e12d63d81f29c57a9d14e846c78fd3beabb2ef768e38fd9580R1-R79), [[4]](diffhunk://#diff-389b34918e040cacaa87cd7201ffa462cc2b0b716736f537e3d3c660ac69353bR1-R7) [[5]](diffhunk://#diff-d3b03416d1c457b19f1c27b26f2db741412df841b875c26ccadc36e4522247f4R1-R29) [[6]](diffhunk://#diff-c8fb8339570a5305809be7c618e14705fd86390dc278e6ce8ba224a7bc8b0c3cR1-R25) **Configuration and Tooling Updates** * Updated `.github/workflows/codeql.yml`, `.golangci.yaml`, and `.github/dependabot.yml` to properly handle the new docs app: excluded `apps/docs` from certain checks, added npm dependency updates for the docs app, and excluded generated content. [[1]](diffhunk://#diff-12783128521e452af0cfac94b99b8d250413c516ec71fe6d97dbea666ff7ba27L8-R14) [[2]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R5-R6) [[3]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R126-R129) [[4]](diffhunk://#diff-dd4fbda47e51f1e35defb9275a9cd9c212ecde0b870cba89ddaaae65c5f3cd28R89-R106) * Updated `.devcontainer/devcontainer.json` to use the latest Go 1.25.3 version for consistency. **Licensing and Miscellaneous** * Added `apps/docs/` to the list of licensed directories in `LICENSING.md`. These changes ensure the documentation is now maintained in a modern, scalable system and all project tooling is updated to support the new structure. --------- Co-authored-by: Federico Coppede <[email protected]>
82 lines
4.0 KiB
Plaintext
82 lines
4.0 KiB
Plaintext
---
|
|
title: ZITADEL Users
|
|
sidebar_label: Users
|
|
---
|
|
|
|
## Types of users
|
|
|
|
ZITADEL supports authentication and authorization for different user types.
|
|
We can mainly differentiate between Human Users and Machine Users.
|
|
We typically call human users simply "Users" and machine users "Service Users".
|
|
|
|
### Human users
|
|
|
|
Human users typically logon with an interactive login.
|
|
This means that an application redirects a user to a website ("login page") where the user can provide the credentials.
|
|
ZITADEL handles the authentication and provides the application with a token that verifies the authentication process.
|
|
|
|
Read more on how to [login users with ZITADEL](/guides/integrate/login/login-users).
|
|
|
|
### Service users
|
|
|
|
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 human and machine users is the type of credentials that can be used for authentication: Human users typically logon via an login prompt, but Machine users require a non-interactive logon process.
|
|
|
|
Learn how to [use service users](/guides/integrate/service-users/authenticate-service-users) with ZITADEL.
|
|
|
|
### Managers
|
|
|
|
Any user, human or service user, can be given a [Manager](/concepts/structure/managers) role.
|
|
A user with an administrator role is not only an end-user of ZITADEL but can also manage certain aspects of ZITADEL itself.
|
|
|
|
### 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").
|
|
Federated user [accounts are linked](../features/account-linking) to internal users to be able to assign roles and keep an audit trail.
|
|
|
|
### External users
|
|
|
|
In a multi-tenancy architecture, you might use [organizations](./organizations) to separate user groups.
|
|
By using [external user grants](../features/external-user-grant) an organization is able to invite users from another organization.
|
|
These invited users are called external users.
|
|
|
|
## Considerations
|
|
|
|
### Uniqueness of users
|
|
|
|
Users can only exist within one [organization](/guides/manage/console/organizations-overview).
|
|
It is currently not possible to move users between organizations.
|
|
|
|
User accounts are uniquely identified by their `id` or `loginname` in combination of the `organization domain` (eg, `[email protected]`).
|
|
You can use the same email address for different user accounts.
|
|
|
|
### How to structure user pools
|
|
|
|
Consider this general recommendation as a starting point:
|
|
|
|
- Create one organization ("default organization") for your own company
|
|
- Configure projects and applications in the default organization
|
|
- Structure users in organizations based on common domains that are self-managed (eg, company)
|
|
- Grant your projects to the organizations, allow Managers to give granted roles to their users
|
|
|
|
You might want to adjust this general setup based on your [scenario](/guides/solution-scenarios).
|
|
|
|
One important consideration in the setup is that you can only have a domain once for an organization. If you have multiple teams working with the same email address, you might need to add them to one single organization that has the domain verified for the teams' domain.
|
|
|
|
For a CIAM / B2C setup, you might want to store all users in one organization and allow that organization to use a specific set of social logins.
|
|
In a multitenancy / B2B scenario, you might have thousands of smaller teams.
|
|
|
|
#### Hierarchy
|
|
|
|
There is no concept of hierarchies and inheritance based on users or organizations.
|
|
This is why we recommend to structure users along the smallest unit of groups.
|
|
You can use organization metadata or your own business logic to describe a hierarchy of organizations or user groups.
|
|
|
|
## References
|
|
|
|
- [Manage users in the Management Console](../../guides/manage/console/users-overview)
|
|
- [ZITADEL APIs: Users](/reference/api/user)
|
|
- [User onboarding and registration](/guides/integrate/onboarding)
|