diff --git a/apps/docs/content/apis/actions/introduction.mdx b/apps/docs/content/apis/actions/introduction.mdx deleted file mode 100644 index 974c1bb9c..000000000 --- a/apps/docs/content/apis/actions/introduction.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Actions ---- - -This page describes the options you have when writing ZITADEL actions scripts. - -## Language - -ZITADEL interprets the scripts as JavaScript. -Make sure your scripts are ECMAScript 5.1(+) compliant. -Go to the [goja GitHub page](https://github.com/dop251/goja) for detailed reference about the underlying library features and limitations. - -Stuck customizing ZITADEL actions? Find samples for setting OIDC claims, SAML attributes, extending JIT provisioning data, calling external APIs, and more in [this repository](https://github.com/zitadel/actions). - -Actions are a key feature to extend the functionality of ZITADEL and continuously improve the feature and expand the use cases. Check out our [roadmap](https://zitadel.com/roadmap) for more details. - -## Action - -The action object describes the logic defined by the user. Actions can be linked to multiple [triggers](#flows). - -The name of the action must correlate with the JavaScript function in the code section. This function will be called by ZITADEL. - -For reading and mutating state, the runtime executes the function that has the same name as the action. -The function receives the JavaScript objects `ctx` and `api`. - -The object `ctx` provides readable information as object properties and by callable functions. -The object `api` provides mutable properties and state mutating functions. - -The script of an action called **doSomething** should have a function called `doSomething` and look something like this: - -```js -function doSomething(ctx, api){ - // read from ctx and manipulate with api -} -``` - -## Flows - -Flows are the links between an [action](#action) and a specific point during a user interaction with ZITADEL. These specific point are called [Trigger Types](#trigger-types). - -## Trigger Types - -Trigger types define the point during execution of request. Each trigger defines which readable information (`ctx`) and mutual properties (`api`) are passed into the called function as well as which libraries are available for the function. Each trigger type is described in the [available flow types section](#available-flow-types) - -## Available Flow Types - -Currently ZITADEL provides the following flows: - -- [Internal Authentication](./internal-authentication) -- [External Authentication](./external-authentication) -- [Complement Token](./complement-token) -- [Complement SAML Response](./customize-samlresponse) - -## Available Modules inside Javascript - -- [HTTP module](./modules#http) to call API's -- [Logging module](./modules#log) logs information to stdout -- [UUID module](./modules#uuid) generates uuids diff --git a/apps/docs/content/concepts/features/account-linking.mdx b/apps/docs/content/concepts/features/account-linking.mdx index 11f52df30..3c0a30ea0 100644 --- a/apps/docs/content/concepts/features/account-linking.mdx +++ b/apps/docs/content/concepts/features/account-linking.mdx @@ -17,7 +17,7 @@ Each user in ZITADEL has one account for streamlined access management and a uni Account linking is controlled by your organization and identity provider configuration. -When external identity providers (such as social logins or enterprise SSO) are configured, a user account is created in ZITADEL, and the [external identity](../structure/users#federated-users) is linked to the ZITADEL account. +When external identity providers (such as social logins or enterprise SSO) are configured, a user account is created in ZITADEL, and the [external identity](/guides/manage/console/users-overview#federated-users) is linked to the ZITADEL account. > **Important:** If a user account in ZITADEL is already linked to an external identity and the user enters their username during login, ZITADEL will automatically redirect to the linked external identity provider for authentication. > There is **no choice** presented to the user between authenticating with local username/password and an external IDP once accounts are linked. diff --git a/apps/docs/content/concepts/features/audit-trail.mdx b/apps/docs/content/concepts/features/audit-trail.mdx index 0eccf621a..b68a2b9c8 100644 --- a/apps/docs/content/concepts/features/audit-trail.mdx +++ b/apps/docs/content/concepts/features/audit-trail.mdx @@ -35,7 +35,7 @@ The same view is available on several other objects such as organization or proj ### Event View -Administrators can see all events across an instance and filter them directly in [Console](/guides/manage/console/overview). +Administrators can see all events across an instance and filter them directly in [Console](/guides/manage/console/console-overview). Go to your default settings and then click on the Tab **Events** to open the Event Viewer or browse to $CUSTOM_DOMAIN/ui/console/events ![](../../../public/img/concepts/audit-trail/event-viewer.png) diff --git a/apps/docs/content/concepts/features/console.mdx b/apps/docs/content/concepts/features/console.mdx deleted file mode 100644 index 4d8ae0b1a..000000000 --- a/apps/docs/content/concepts/features/console.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "ZITADEL Management Console: Resource management and customization" -sidebar_label: Management Console ---- - -The ZITADEL management console is a web-based interface designed to facilitate the management and administration of ZITADEL resources and configurations. -It serves as a central hub where administrators can perform various tasks related to identity and access management within their organization's infrastructure. - -The management console is available by navigating to the [custom domain](/concepts/features/custom-domain) of your instance and appending the path `/ui/console`. -Administrators can [restrict end-users from accessing the management console](/guides/solution-scenarios/restrict-console). - -Here's an overview of what the management console enables users to do: - -1. **Default Settings:** [Administrators](/concepts/structure/administrators) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements. - -2. **Resource Management:** The management console allows for the creation, updating, and deletion of essential resources such as organizations, users, projects, and applications. Administrators can efficiently manage these entities to ensure proper access control and governance. - -3. **User Management:** Administrators can manage user accounts, including creating new user accounts, updating user profiles, resetting passwords, and deactivating or deleting user accounts as needed. - -4. **Access Control:** The management console provides tools for defining and managing access control policies. This includes assigning roles and permissions to users, configuring fine-grained access controls, and managing access to specific resources. - -5. **Audit Logging:** The management console offers access to [audit logs](/concepts/features/audit-trail) that track user activity and changes made to resources and system settings. Administrators can review these logs to monitor security-related events, track changes, and maintain compliance with regulatory requirements. - -6. **Customization and Branding:** The management console allows organizations to customize the branding and appearance of their ZITADEL instance. This includes uploading custom logos, selecting color schemes, and applying other visual customizations to align the interface with the organization's branding guidelines. - -7. **Administrator Assignment:** Administrators can assign ZITADEL [administrators](/concepts/structure/administrators) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control. - -Overall, the ZITADEL management console serves as a comprehensive tool for administrators to configure, manage, and monitor identity and access management within their organization, providing the necessary controls to ensure security, compliance, and efficient administration of resources. - -Notes: - -- Detailed guide on [using the management console](/guides/manage/console/console-overview) -- [Restrict access](/guides/solution-scenarios/restrict-console) to the management console diff --git a/apps/docs/content/concepts/features/index.mdx b/apps/docs/content/concepts/features/index.mdx index 07fc271d2..0d2df7f1d 100644 --- a/apps/docs/content/concepts/features/index.mdx +++ b/apps/docs/content/concepts/features/index.mdx @@ -10,5 +10,5 @@ title: Features - + diff --git a/apps/docs/content/concepts/structure/applications.mdx b/apps/docs/content/concepts/structure/applications.mdx deleted file mode 100644 index 07fcceba1..000000000 --- a/apps/docs/content/concepts/structure/applications.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Configure applications for your frontend and backend services and clients -sidebar_label: Applications ---- - -import AppType from "../../guides/manage/console/_application-types.mdx"; - -Applications are the entry point to your project. -[Users](./users) either login into one of your applications and interact with them directly or use one of your APIs. -All applications share the roles and authorizations of their [project](./projects). - -## Supported application types - -ZITADEL supports the following application types: - - - -## Security considerations - -Ensure the configuration of application settings is limited to authorized users only. - -You can configure applications in the [management console](/guides/manage/console/organizations-overview). -Read about our [administrators](/concepts/structure/administrators) and [granted projects](/concepts/structure/granted_projects) -concepts. - -## References - -- [Configure Applications in the Management Console](../../guides/manage/console/applications-overview) -- [ZITADEL API: Applications](/reference/api/application) diff --git a/apps/docs/content/concepts/structure/index.mdx b/apps/docs/content/concepts/structure/index.mdx index fdc603d2c..d59449977 100644 --- a/apps/docs/content/concepts/structure/index.mdx +++ b/apps/docs/content/concepts/structure/index.mdx @@ -4,10 +4,10 @@ title: Structure - - - - + + + + diff --git a/apps/docs/content/concepts/structure/organizations.mdx b/apps/docs/content/concepts/structure/organizations.mdx deleted file mode 100644 index 423bfc407..000000000 --- a/apps/docs/content/concepts/structure/organizations.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: ZITADEL Organizations -sidebar_label: Organizations ---- - -import OrgDescription from './_org_description.mdx'; - - - -More about how to configure your organization read our [organization guide](../../guides/manage/console/organizations-overview). diff --git a/apps/docs/content/concepts/structure/projects.mdx b/apps/docs/content/concepts/structure/projects.mdx deleted file mode 100644 index 9dec7a35c..000000000 --- a/apps/docs/content/concepts/structure/projects.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Projects -sidebar_label: Projects ---- - -import ProjectDescription from './\_project_description.mdx'; - - - -To learn how to set up a project read this management console guide [here](../../guides/manage/console/projects-overview). - -## Applications - -Applications define the different clients, that share the same roles. -At the moment we support OIDC and almost every OAuth2 client. We'll be expanding this with SAML shortly. -Go to [Applications](./applications) for more details. - -## Granted Organizations - -To enable another organization to use a project, the organization needs a grant to the project. -Only the selected roles will be available to the granted organization. - -If you are unsure on how to structure your organizations and projects, we recommend reading the guide on [solution architecture](/concepts/architecture/solution). - -The granted organization will be able to manage the authorizations of their users for the granted project by themselves in their organization. - -More about granted projects: [Granted Projects](./granted_projects) - -## Roles - -A role consists of different attributes. Only the key is relevant to the authorization and must therefore be unique. -The display name is only to provide a human-readable name if needed. -And the group should enable a better handling in ZITADEL management console, like give a user all the roles of a specific group. (Not implemented yet) - -All applications in a project share the roles. Read more about roles [here](../../guides/manage/console/roles) - -## Default Project - -When creating a new ZITADEL instance you will find an automatically created project on the first created organization. -This default project does represent the ZITADEL project and is used to secure the different apps shipped with ZITADEL. -This includes the ZITADEL Management Console and APIs. - -We do not recommend changing any settings or using this project for anything else, as this could influence the behavior of ZITADEL. - -The default name of the project is "ZITADEL", this might differ on self-hosted instances, when you change the default name. - -![](../../../public/img/guides/solution-scenarios/console-default-project.png) diff --git a/apps/docs/content/concepts/structure/users.mdx b/apps/docs/content/concepts/structure/users.mdx deleted file mode 100644 index 3caf707a3..000000000 --- a/apps/docs/content/concepts/structure/users.mdx +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: ZITADEL Users -sidebar_label: Users ---- - -## Types of users - -ZITADEL supports authentication and authorization for different user types. -We can mainly differentiate between Users and Service Accounts. -Users are accounts operated/used by a human, while service accounts are those operated/used by an application/third-party software. - -### Users - -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 accounts - -Service accounts 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 Account 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 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. - -### Administrators - -Any user or service account can be assigned an [Administrator](/concepts/structure/administrators) 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 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 - -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, `road.runner@acme.zitadel.local`). -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 Administrators 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) diff --git a/apps/docs/content/guides/manage/console/actions.mdx b/apps/docs/content/guides/manage/console/actions.mdx deleted file mode 100644 index c392be446..000000000 --- a/apps/docs/content/guides/manage/console/actions.mdx +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: ZITADEL Actions -sidebar_label: Actions ---- - -An Identity and Management system is a very interactive place. ZITADEL has built in functionality to react to its events. This functionality is called **Actions** and can be accessed from your organizations top navigation. - -Actions menu - -Actions allow you to define scripts which are then run on certain triggers. -To add an action, click at the **new** button and provide a script and a name. -You can specify a timeout and whether the action is allowed to fail too. - -Create Action - -To run those scripts, a flow with a trigger has to be created. -This could for example be an **External Authentication** Flow, with a **Post Authentication** trigger. - -Flow - -Now whenever a user gets authenticated externally with an IDP, an action is triggered after the authentication itself. -If you want to know more where actions can be useful, take a look at the feature [here](/concepts/features/actions) or directly jump to an example of a custom behavior [here](/guides/manage/customize/behavior). diff --git a/apps/docs/content/guides/manage/console/applications.mdx b/apps/docs/content/guides/manage/console/applications.mdx deleted file mode 100644 index 83afa7a9f..000000000 --- a/apps/docs/content/guides/manage/console/applications.mdx +++ /dev/null @@ -1,200 +0,0 @@ ---- -title: ZITADEL Applications -sidebar_label: Applications ---- - -import ThemedImage from "@/components/docusaurus/themed-image"; -import AuthType from "../../integrate/application/_auth-type.mdx"; -import ReviewConfig from "../../integrate/application/_review-config.mdx"; -import AppType from "./_application-types.mdx"; - -## What is an application? - -Applications are the entry point to your project. -Users either login into one of your applications and interact with them directly or use one of your APIs. -All applications share the roles and authorizations of their project. - -To access your applications, navigate to your project and select your application. - -Granted project - -## Create application - -To add an application to your project, click on the add button and select your application type. - -Add application - -## Application Types - -At the moment ZITADEL offers five application types: - - - -The first three options (Web, Native and User Agent) require user interaction, the fourth option (API) has no direct user-interaction. -Depending on the app type, there are small differences in the possible settings. - -To get a good understanding about user profiles and recommended flows, read the following [guide](../../integrate/login/oidc/oauth-recommended-flows#different-client-profiles). - -### Web - -Web applications are **server side rendered** applications users interact with. For example if you develop an application using Thymeleaf in Java or Razor in .NET or want to enable SSO in Gitlab. - -Typical **React or Angular** apps **are not** a Web applications in this case. -A **NextJS** on the contrary would be because it allows you to implement server side code. - -Following authentication types can be used: - - - -### Native - -Native Applications installed on a thin client. For example on a smartphone or computer. This can for example be Android and iOS Applications. - -These applications uses the Key file generated by ZITADEL to authenticate. - - - -### User Agent - -User Agent Applications that are executed in a web browser, for example single page applications executed in the browser developed with JavaScript frameworks like [Angular](../../../examples/login/angular) or [React](../../../examples/login/react) - -Following **authentication methods** can be used: - - - -### API - -These are Applications without human interaction. These applications are accessed by other applications, so called machine to machine communication. - -Following authentication types can be used: - - - -After selecting your Apps Type and Authentication Method, you may need to specify redirect URIs. - -### SAML - -If your application doesn't support the OIDC standard, but SAML this is the right application type to choose. SAML is an open standard used for authentication based on XML. - -After entering a name and choosing the application type "SAML", you will get to the SAML configuration screen. - -You can either add a link to a SAML metadata file or upload it directly. -SAML metadata is an XML document which contains information necessary for interaction with SAML-enabled identity or service providers. - -You can find some example configurations for SAML 2.0 in our [integrate services](/guides/integrate/services) guides - -## Redirect URIs - -App Types with User interaction (Web, Native and User Agent) require redirect URIs. -Those redirects URIs are used to redirect the user back to your application on successful login. - -These URIs are defined in your application code and are checked by ZITADEL if they correspond to your applications configuration. -Redirect URIs are checked during the login process. -Native applications can use a different protocol than http or https in order to redirect your user. - -Redirect URIs - -### Development mode - -In order to develop locally, or you want to redirect users to any other protocol than https://, you must enable **Development mode**. -When disabled only https is allowed, as ZITADEL's configuration is secure by default. - -Development mode - -Development mode also allows glob patterns in redirect URIs with the following special terms in the patterns: - -| Special Terms | Meaning | -| ------------- | ---------------------------------------------------------------------------------------------------------- | -| `*` | matches any sequence of non-path-separators | -| `/**/` | matches zero or more directories | -| `?` | matches any single non-path-separator character | -| `[class]` | matches any single non-path-separator character against a class of characters [see "character classes"][1] | -| `{alt1,...}` | matches a sequence of characters if one of the comma-separated alternatives matches | - -[1]: https://github.com/bmatcuk/doublestar?tab=readme-ov-file#character-classes - -Special character can be escaped with a backslash (`\`). - -Double stars (`**`) should appear surrounded by a path separators such as `/**/`. -A mid-pattern double star (`**`) behaves like bash's glob star option: a pattern -such as `path/to/**.txt` would return the same results as `path/to/*.txt`. The -pattern you're looking for is `path/to/**/*.txt`. - -*Source: [github.com/bmatcuk/doublestar](https://github.com/bmatcuk/doublestar?tab=readme-ov-file#patterns)* - -> When IPv6 URIs are used as redirects in development mode, square brackets must be escaped as they are also Special Terms for globs. `http://\[::1\]:80` - -## Review Configuration - - - -## Application settings - -After creating the application, you can still change its configuration if you for example need a offline_access support (Refresh token). -You can easily change your authentication method via the colored toggle on top or directly change configuration via the input and dropdown fields. - -> Note: Changing application type is not possible. In this case you have to create a new application. - -Redirect URIs - -On the top of the page you can check if your application is OIDC compliant. -Tasks for completion are shown in the field. - -OIDC Compliance - -### Token settings - -In the token settings you can change the type from **Bearer Token** to **JWT**, and check some settings whether you need user roles and user information in the ID Token or not. -On the bottom you can optionally set a **ClockSkew** time which is added to the expiration time of the issued token. - -Token settings - -### Redirect settings - -Like on creation, you can modify you redirect settings here. -Note that for local development you most likely have to enable development mode, as redirects to http:// are otherwise blocked. -On Native Apps you can also skip the Login Success Page. - -Redirect URIs - -### Additional origins - -If you need to allow additional origins which should **NOT** be used as redirect you can specify them in the **Additional origins** section. - -Additional origins diff --git a/apps/docs/content/guides/manage/console/default-settings.mdx b/apps/docs/content/guides/manage/console/default-settings.mdx index 929066726..c60cabfd8 100644 --- a/apps/docs/content/guides/manage/console/default-settings.mdx +++ b/apps/docs/content/guides/manage/console/default-settings.mdx @@ -68,7 +68,7 @@ In the Branding settings, you can upload you Logo for the login interface, set y Make sure you click the "Apply configuration" button after you finish your configuration. This will ensure your design is visible for your customers. -Branding settings applied on you instance act as a default for all your organizations. If you need custom branding on a organization take a look at our guide under [organization setting](./organizations#organization-settings). +Branding settings applied on you instance act as a default for all your organizations. If you need custom branding on a organization take a look at our guide under [organization setting](./organizations-overview#organization-settings). ## Notification settings diff --git a/apps/docs/content/guides/manage/console/organizations.mdx b/apps/docs/content/guides/manage/console/organizations.mdx deleted file mode 100644 index 3770c0c6f..000000000 --- a/apps/docs/content/guides/manage/console/organizations.mdx +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: ZITADEL Organizations -sidebar_label: Organizations ---- - -import OrgDescription from "../../../concepts/structure/_org_description.mdx"; -import Column from "@/components/column"; - -## What is an organization? - -An Organization is where your projects and users live. Looking at a B2B use case, an organization represents a business partner who typically has its own branding and has different access settings like additional federated login providers. -Users from one organization are separated from others. - -## Create a new organization - -To create a new organization, click on the organizations dropdown and then select “New organization”. -You can either create a new organization with your logged in user as the organization manager or directly create another account. -If you choose your logged in user as organization manager, a membership for the new organization will be added to the account. - -Select Organization - -If you want to enable your customers to create their organization by themselves, we provide a creation form for an organization. `https://${CUSTOM_DOMAIN}/ui/login/register/org` -The customer needs to fill in the form with the organization name and the contact details. - -Register new organization - -## How ZITADEL handles usernames - -If your domain setting "user loginname must contain orgdomain" is disabled, your username will be unique within the whole instance. -At the moment the username only allows e-mail formatted input. (This will be changed soon) - -### User Loginname must contain orgdomain - -If this behavior is not suitable for you, ZITADEL has the option to suffix the usernames with the organization domain. -This setting is called **User Loginname must contain orgdomain** and is part of your [Domain settings](./default-settings#domain-settings). - -Those loginnames consist of the format `{username}@{domainname}.${CUSTOM_DOMAIN}`. -If your user had the username `john.doe`, the generated loginname would be `john.doe@acme.zitadel.cloud`. -This also means that only one user with the username `john.doe` can exist in your organization called `ACME`. - -If you verify your domain name or add additional domains, ZITADEL will generate those additional login names for you. -If the organization would own the domain `acme.ch` and verify it, then the resulting loginname would be `john.doe@acme.ch` in addition to the already generated `john.doe@acme.zitadel.cloud`. -The user can now use either login name to authenticate with your application. - -> Note: You can set this setting on your instance as well as your organizations. All available usernames are shown on the top of the user pages. - -## Domain verification and primary domain - -Once you have successfully registered your organization, ZITADEL will automatically generate a domain name for your organization (eg, acme.zitadel.cloud). -Users that you create within your organization will be suffixed with this domain name. - -You can improve the user experience, by suffixing users with a domain name that is in your control. -If the "validate org domains" settings in the [Domain Settings](./default-settings#domain-settings) is set to true, you have to prove the ownership of your domain, by DNS or HTTP challenge. -If the setting is set to false, the created domain will automatically be set to verified. - -An organization can have multiple domain names, but only one domain can be primary. -The primary domain defines which login name ZITADEL displays to the user, and what information gets asserted in access_tokens (`preferred_username`). - -Please note that domain verification also removes the login name from all users, who might have used this combination in the global organization (ie. users not belonging to a specific organization). -Relating to our example with acme.ch: If a user ‘coyote’ exists in the global organization with the login name coyote@acme.ch, then after verification of acme.ch, this login name will be replaced with `coyote@{randomvalue.tld}`. -ZITADEL will notify users affected by this change. - -## Verify your domain name - - -You can also disable domain verification with DNS challenge in the [default settings](/guides/manage/console/default-settings#domain-settings). - - -1. Browse to your organization settings -2. Select the menu entry **Verified domains** -3. To start the domain verification click the domain name and a dialog will appear, where you can choose between DNS or HTTP challenge methods. - -Select Organization - -4. For example, create a TXT record with your DNS provider for the used domain and click verify. ZITADEL will then proceed and check your DNS. Here are some useful links explaining how you can add TXT records for popular domain providers: - -- [Cloudflare](https://www.zoho.com/mail/help/adminconsole/cloudflare.html#alink1) -- [Squarespace](https://support.squarespace.com/hc/en-us/articles/205812388-Domain-verification-with-a-TXT-Record-alternative-method-) -- [Name.com](https://www.name.com/support/articles/115004972547-adding-a-txt-record) -- [EasyDNS](https://kb.easydns.com/knowledge/how-to-make-a-dns-entry/) -- [DNS Made Easy](https://support.dnsmadeeasy.com/support/solutions/articles/47001001376-create-a-txt-record) - -5. When the verification is successful you have the option to activate the domain by clicking **Set as primary** - - -Do not delete the verification code, as ZITADEL will re-check the ownership of your domain from time to time - - -## Organization Settings - -In organizations you also have settings that have higher priority than on your default settings, and therefore override them. -Those settings are the same as your default settings. - -> Note: that the following links, redirect to default settings to omit redundancy. - -- [**Domain settings**](./default-settings#domain-settings): Whether users use their email or the generated username to login. Other Validation, SMTP settings -- [**Branding**](./default-settings#branding): Appearance of the login interface. -- [**Notification settings**](./default-settings#notification-settings): Setup Notification and Email Server settings for initialization-, verification- and other mails. Setup Twilio as SMS notification provider. -- [**Login Behavior and Access**](./default-settings#login-behavior-and-access): Multifactor Authentication Options and Enforcement, Define whether passkeys are allowed or not, Set Login Lifetimes and advanced behavior for the login interface. -- [**Identity Providers**](./default-settings#identity-providers): Define IDPs which are available for all organizations -- [**Password Complexity**](./default-settings#password-complexity): Requirements for Passwords ex. Symbols, Numbers, min length and more. -- [**Lockout**](./default-settings#lockout): Set the maximum attempts a user can try to enter the password or any (T)OTP method. When the number is exceeded, the user gets locked out and has to be unlocked. -- [**Verified domains**](/guides/manage/console/organizations-overview#usernames-and-domains): This is where you manage your organization specific domains which can be used to build usernames -- [**Message Texts**](./default-settings#message-texts): Text and internationalization for emails -- [**Login Interface Texts**](./default-settings#login-interface-texts): Text and internationalization for the login interface -- [**External Links**](./default-settings#external-links): Links to your own Terms of Service and Privacy Policy regulations, Help Page, Support email, documentation link... - -If you need custom branding on a organization (for example in a B2B scenario, where organizations are allowed to use their custom design), navigate back to the home page, choose your organization in the header above, navigate to the organization settings and set the custom design here. - -The behavior of the login page, applying custom design, is then defined on your projects detail page. Read more about it [here](./projects#branding) - -## Show Organization Login - -As you should know by now ZITADEL knows the concept of Organizations. -You can define [default settings](/guides/manage/console/default-settings) for your ZITADEL, or you can overwrite them for an [Organization](#organization-settings). -Per default the ZITADEL Login will always show what is defined per default. As soon as the Organization context is given, the settings defined on the specific organization can be triggered. -This means when you want to trigger the settings of an organization directly, make sure to send the organization scope in the authentication request. - -```bash -urn:zitadel:iam:org:id:{id} -``` - -Read more about the [scopes](/apis/openidoauth/scopes#reserved-scopes) or try it out in our [OIDC Playground](https://zitadel.com/playgrounds/oidc). - -## Default organization - -On the Default settings page (`${CUSTOM_DOMAIN}`/ui/console/orgs) you can set an organization as default organization. -Click the "..." on the right hand side of the table and select "Set as default organization". - -The current default organization is marked by a label "Default". - -When no organization was selected (eg, with the auth request or through [Domain Discovery](/guides/solution-scenarios/domain-discovery)), then all users are allowed to login and users can self-register to this default organization. diff --git a/apps/docs/content/guides/manage/console/overview.mdx b/apps/docs/content/guides/manage/console/overview.mdx deleted file mode 100644 index 9e7fe4fb7..000000000 --- a/apps/docs/content/guides/manage/console/overview.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: ZITADEL Management Console -sidebar_label: Overview ---- - -## What is the management console? - -Management Console is the Dashboard UI for your instance. It can be accessed from all configured Custom Domains, defined in the Customer Portal. -The management console is used to configure global default settings and can be used by multiple Administrators. -Read more about [Console Administrators](./administrators) here. - -It can also be used by your application users to modify their profile, although we recommend that you build your own User Interface. - -When you are logged in, you are greeted by the home page. This page allows you to set shortcuts to settings and projects. -The management console has a context switcher on the **top-left** where your current organization is set. -Depending on your use case, multiple organizations can be created (B2B) or you can stick to your global organization (B2C). To get an understanding of your use cases and how we recommend setting up your organizations, read the [Solution Scenario](../../solution-scenarios/introduction) guides. - -Context switcher - -If you're new to management console, you'll probably want to set some settings initially. Continue reading Default settings on the next page. - -## Prevent management console access - -In some use cases you want to prevent users from accessing the ZITADEL management console. -Please follow this [guide](/guides/solution-scenarios/restrict-console) to achieve that. diff --git a/apps/docs/content/guides/manage/console/projects.mdx b/apps/docs/content/guides/manage/console/projects.mdx deleted file mode 100644 index 8295b3b10..000000000 --- a/apps/docs/content/guides/manage/console/projects.mdx +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: ZITADEL Projects -sidebar_label: Projects ---- - -import ProjectDescription from "../../../concepts/structure/_project_description.mdx"; - -## What is a project? - - - -### Example - -If you'd build a Point of Sales Platform, you would have one Project (maybe called `POS`) and all your applications (one Webapplication for administration, and your mobile applications for your users iOS and Android), would be part of it. -You would have to create roles for administration and your applications in this very project, and then create authorizations based on them. - -![](../../../../public/img/guides/console/posproject.png) - -## Create a project - -To create a project, navigate to your organization, then projects or directly via `https://${CUSTOM_DOMAIN}.zitadel.cloud/ui/console/projects`, and then click the button to create a new project. - -Empty Project - -then enter your project name and continue. - -## What is a granted project? - -Now imagine you could use the POS platform from the example not only for yourself but sell it to other business partners too. -Those partners would maybe have the need to have their own domain, their own branding and add additional social login options. -Setting this up in ZITADEL is very easy since all organizations can overwrite their settings. -You would only need a method to grant them access. - -To add a grant to another organization is done from the project itself. Navigate to grants and hit the new button. -Now, enter the domain of the partner organization (if you can't remember it, navigate to the organization and pick it up from the detail page), hit search and then continue. - -Now select the roles you want this organization to use and save. -This enables you to lock a certain organization out of a feature if you don't want their users to use it. -You can learn more about roles [here](./roles). - -Organizations can then create authorizations for their users on their own. The project is shown them separated from their own projects. - -Granted project - -## Grant a project - -1. Visit the project `POS` that you have created before, then in the section **Grants** click **New**. - -Grants - -2. Search the organization you want to grant using the auto complete input and continue. -3. Select some roles you would like to grant to the organization and confirm. -4. You should now see the granted organization in the section **grants**. - -## Project Settings - -### Branding - -If you have different designs for your organizations or probably and use project grants, you can define the login behavior on the project detail page. - -Project branding - -You can choose from - -| Setting | Description | -| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Unspecified | If nothing is specified the default will trigger. (System settings) | -| Enforce project's policy | This setting will enforce the private labeling of the organization of the project through the whole login process. | -| Allow login user policy | With this setting first the private labeling of the organization of the project will trigger. As soon as the user and its organization is identified by ZITADEL, the settings will change to the organization of the user. | - -In a B2B use case, you would typically use the organization setting. If you want to omit organization detection, you can preselect an organization with the [primary domain scope](/apis/openidoauth/scopes#reserved-scopes) (ex. `urn:zitadel:iam:org:domain:primary:{domainname}`). - -### Role settings - -Below the branding settings, you can check different checkboxes to get even more custom behavior on authentication. - -- **Assert Roles on Authentication**: - Role information is sent from Userinfo endpoint and depending on your application settings in tokens and other types. -- **Check authorization on Authentication**: If set, users are only allowed to authenticate if any role is assigned to their account. -- **Check for Project on Authentication**: - It is checked whether the user's organization has this project. If not, the user cannot be authenticated. - -Role settings - -If you want to have roles in your token, this has to be set in your applications as this is dependent on your application type. Navigate to your application and check this setting if you want so. - -Roles in token - -You can learn more about [Application and Token settings](./applications#token-settings) in the next section. diff --git a/apps/docs/content/guides/manage/console/roles.mdx b/apps/docs/content/guides/manage/console/roles.mdx index 2193cc259..745543ea6 100644 --- a/apps/docs/content/guides/manage/console/roles.mdx +++ b/apps/docs/content/guides/manage/console/roles.mdx @@ -3,7 +3,7 @@ title: ZITADEL Roles and Authorizations sidebar_label: Roles and Authorizations --- -If you would build out the [POS use case example](./projects#example) you would probably need an application for administration. +If you would build out the [POS use case example](./projects-overview#example-scenario) you would probably need an application for administration. In this application you would probably have somebody accessing as an accountant and somebody as an administrator, who is somebody with enhanced rights. To build this out, you would have to add this distinction as roles. To add roles, jump to the section **Roles** and create those new roles with the following values @@ -49,6 +49,6 @@ Type your username, hit continue, select the roles you want your user to have an alt="Authorization" /> -Now you can retrieve those roles in your application. ZITADEL has [multiple settings](./projects#project-settings) for you to access them more easily. Navigate to the **General** section of your project and check your needed ones. +Now you can retrieve those roles in your application. ZITADEL has [multiple settings](./projects-overview#project-settings) for you to access them more easily. Navigate to the **General** section of your project and check your needed ones. > Note: We did set up our authorizations from projects, but this can be achieved from multiple locations in console. You can view and add authorizations from your organization, your projects, or from your users page. diff --git a/apps/docs/content/guides/manage/console/users.mdx b/apps/docs/content/guides/manage/console/users.mdx deleted file mode 100644 index 47edb826b..000000000 --- a/apps/docs/content/guides/manage/console/users.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: ZITADEL Users -sidebar_label: Users ---- - -import CreateUser from './_create-user.mdx'; - -ZITADEL differs two different types of users: - -- Users (Humans) -- Service Accounts - -User types - -A user has an email address and a password, and can additionally save information about phone, nickname, gender, language. -A service account only has a name and a description aside his username. - -A service account can be authenticated with JWT profile or Personal Access Tokens. Both methods can specify an expiry. -A user can authenticate itself with his password, add multiple factors for additional security, and enable passkey authentication. - -Service accounts are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL administrators is used to restrict access to specific projects or organizations. -To get an understanding on how service accounts are used, take a look at our NextJS B2B Demo application. - -## Create User - - - -## Metadata - -When building complex applications, having the possibility to add metadata is essential. -ZITADEL provides a key value storage for users on the user pages. -Just navigate to the section **Metadata** and click on **edit**. - -> In our [Point of Sales example](./projects#example) from the projects guide, you could add a `stripeCustomerId` as a metadata key. In your client application you could then easily fetch the customer from Stripe APIs for your payments. - -User Metadata - -Metadata can be requested via our auth and management APIs, from userinfo endpoint or ID Token. -To get your metadata from the userinfo endpoint, add `urn:zitadel:iam:user:metadata` to your authentication request. Take a look at our reserved scopes [here](/apis/openidoauth/scopes#reserved-scopes) or take a look at our [metadata guide](../customize/user-metadata). - -You can then toggle **User Info inside ID Token** in your application settings if you need this information in the ID Token too. - -ID Token settings - -## Authorizations - -As described in [Roles and Authorizations](./roles), authorizations are shown on user profile pages too. -If you need user roles in the user info endpoint, check the **Assert roles on authentication** checkbox in your project as described in [Authorizations](./roles#authorizations). -If you need them in your ID Token, toggle **User roles inside ID Token** in application settings. diff --git a/apps/docs/content/guides/solution-scenarios/b2c.mdx b/apps/docs/content/guides/solution-scenarios/b2c.mdx index 31bcabb77..78a2cf3fe 100644 --- a/apps/docs/content/guides/solution-scenarios/b2c.mdx +++ b/apps/docs/content/guides/solution-scenarios/b2c.mdx @@ -23,7 +23,7 @@ Depending on your Software Development Life Cycle (SDLC) you can create multiple Right after org creation you'll be greeted with the domain section of your organization. ZITADEL automatically creates an organization domain of the form `[orgname].zitadel.cloud`, but you can create your own. Depending on the settings on the [Domain Policy](../../concepts/structure/policies) it has to be verified 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 and changes later on might create additional migration effort. -You can read more about how ZITADEL handles usernames [here](../manage/console/organizations#how-zitadel-handles-usernames). +You can read more about how ZITADEL handles usernames [here](../manage/console/organizations-overview#login-name-formats). ### Data Provisioning @@ -103,6 +103,6 @@ Read more about Authorization in our [Guide](../integrate/login/oidc/oauth-recom ## Learn more -- [Creating an organization](../manage/console/organizations#create-a-new-organization) +- [Creating an organization](../manage/console/organizations-overview#create-a-new-organization) - [Organization Branding](../manage/customize/branding) - [Authorization](../integrate/login/oidc/oauth-recommended-flows) diff --git a/apps/docs/content/guides/solution-scenarios/configurations.mdx b/apps/docs/content/guides/solution-scenarios/configurations.mdx index f18ee2b01..09ced5a84 100644 --- a/apps/docs/content/guides/solution-scenarios/configurations.mdx +++ b/apps/docs/content/guides/solution-scenarios/configurations.mdx @@ -33,7 +33,7 @@ ZITADEL Login: `login.app.com` In the OIDC Authorization request you always have to send the redirect URI to where you like to be redirected after login. To handle this scenario it is possible to register multiple URIs on each application in ZITADEL, the only criteria is that the requested URI has to match one of the registered URIs. -Read more about [applications](../manage/console/applications) and the [redirect urls](../manage/console/applications#redirect-ur-is) +Read more about [applications](../manage/console/applications-overview) and the [redirect urls](../manage/console/applications-overview#redirect-uris) ### Trigger organization in ZITADEL login diff --git a/apps/docs/content/sdk-examples/angular.mdx b/apps/docs/content/sdk-examples/angular.mdx index 44d24895e..15537ce7c 100644 --- a/apps/docs/content/sdk-examples/angular.mdx +++ b/apps/docs/content/sdk-examples/angular.mdx @@ -33,23 +33,23 @@ The example includes secure sign-out functionality implementing **[federated log ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/login-users): 1. Clone the [repository](https://github.com/zitadel/example-auth-angular). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). Use these environment variable names exactly as shown: +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). Use these environment variable names exactly as shown: ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/astro.mdx b/apps/docs/content/sdk-examples/astro.mdx index a6b988467..82b645827 100644 --- a/apps/docs/content/sdk-examples/astro.mdx +++ b/apps/docs/content/sdk-examples/astro.mdx @@ -25,7 +25,7 @@ This Astro application showcases a complete authentication workflow with [Zitade The example implements server-side session management with encrypted [JWT tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token_endpoint), ensuring secure authentication state across Astro's [server-rendered pages](https://zitadel.com/docs). Protected routes automatically redirect unauthenticated users to the login flow using [Astro's middleware](https://zitadel.com/docs), preventing unauthorized access to sensitive areas. -The application includes complete [logout functionality](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs) using [Auth.js](https://authjs.dev). Users start on a public landing page and click a login button to authenticate through Zitadel's [authorization endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token_endpoint) with the `offline_access` [scope](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/manage/customize/user-metadata), [organization information](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/manage/customize/user-metadata), [organization information](https://zitadel.com/docs/guides/manage/console/organizations), and [role assignments](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/manage/customize/user-metadata), [organization information](https://zitadel.com/docs/guides/manage/console/organizations), and [role assignments](https://zitadel.com/docs/guides/manage/console/roles). +The application includes complete [logout functionality](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs) using [Auth.js](https://authjs.dev). Users start on a public landing page and click a login button to authenticate through Zitadel's [authorization endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token_endpoint) with the `offline_access` [scope](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/manage/customize/user-metadata), [organization information](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/manage/customize/user-metadata), [organization information](https://zitadel.com/docs/guides/manage/console/organizations-overview), and [role assignments](https://zitadel.com/docs/guides/integrate/login/oidc/logout) that performs [federated single sign-out](https://zitadel.com/docs/guides/integrate/login/oidc/logout), terminating both the local session and the remote Zitadel session through the [end-session endpoint](https://zitadel.com/docs/apis/openidoauth/endpoints). It demonstrates [token refresh](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) capabilities using [refresh tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint) with the `offline_access` [scope](https://zitadel.com/docs/apis/openidoauth/scopes), allowing users to maintain authenticated sessions without repeated logins. The example also shows how to request additional [OIDC scopes](https://zitadel.com/docs/apis/openidoauth/scopes) like `profile`, `email`, and Zitadel-specific scopes for [user metadata](https://zitadel.com/docs/guides/manage/customize/user-metadata), [organization information](https://zitadel.com/docs/guides/manage/console/organizations-overview), and [role assignments](https://zitadel.com/docs/guides/manage/console/roles). --- @@ -33,22 +33,22 @@ The application includes complete [logout functionality](https://zitadel.com/doc ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/api/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/api/auth/logout/callback`) 5. Copy your **Client ID** from the application details -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/login-users): 1. Clone the [repository](https://github.com/zitadel/example-auth-astro). -2. Create a `.env` file based on `.env.example` and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). Use these environment variable names exactly as shown: +2. Create a `.env` file based on `.env.example` and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). Use these environment variable names exactly as shown: ``` PORT=3000 SESSION_DURATION=3600 diff --git a/apps/docs/content/sdk-examples/django.mdx b/apps/docs/content/sdk-examples/django.mdx index 032d8dc75..09ece4081 100644 --- a/apps/docs/content/sdk-examples/django.mdx +++ b/apps/docs/content/sdk-examples/django.mdx @@ -33,23 +33,23 @@ The application demonstrates proper **[federated logout](https://zitadel.com/doc ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-django). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` PORT=3000 SESSION_SECRET=your-very-secret-and-strong-session-key diff --git a/apps/docs/content/sdk-examples/expressjs.mdx b/apps/docs/content/sdk-examples/expressjs.mdx index 21874fbdd..2e0db4460 100644 --- a/apps/docs/content/sdk-examples/expressjs.mdx +++ b/apps/docs/content/sdk-examples/expressjs.mdx @@ -33,22 +33,22 @@ Sign-out functionality implements **[federated logout](https://zitadel.com/docs/ ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/login-users): 1. Clone the [repository](https://github.com/zitadel/example-auth-expressjs). -2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). Use the exact environment variable names from the repository: +2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). Use the exact environment variable names from the repository: ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/fastapi.mdx b/apps/docs/content/sdk-examples/fastapi.mdx index f34fed1d8..f9c3c8c16 100644 --- a/apps/docs/content/sdk-examples/fastapi.mdx +++ b/apps/docs/content/sdk-examples/fastapi.mdx @@ -33,23 +33,23 @@ The application demonstrates proper **[federated logout](https://zitadel.com/doc ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-fastapi). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` PY_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/fastify.mdx b/apps/docs/content/sdk-examples/fastify.mdx index 437b3045c..940120336 100644 --- a/apps/docs/content/sdk-examples/fastify.mdx +++ b/apps/docs/content/sdk-examples/fastify.mdx @@ -33,23 +33,23 @@ The application also demonstrates proper **[federated logout](https://zitadel.co ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-fastify). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/flask.mdx b/apps/docs/content/sdk-examples/flask.mdx index 0072d01a1..2086ff34d 100644 --- a/apps/docs/content/sdk-examples/flask.mdx +++ b/apps/docs/content/sdk-examples/flask.mdx @@ -33,23 +33,23 @@ The application demonstrates proper **[federated logout](https://zitadel.com/doc ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-flask). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` PY_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/hono.mdx b/apps/docs/content/sdk-examples/hono.mdx index cb6d5b011..8eeda73bd 100644 --- a/apps/docs/content/sdk-examples/hono.mdx +++ b/apps/docs/content/sdk-examples/hono.mdx @@ -31,22 +31,22 @@ The implementation uses [Handlebars templates](https://handlebarsjs.com/) for se ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your Zitadel application configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-hono). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use the exact environment variable names from the repository:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use the exact environment variable names from the repository:** ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/laravel.mdx b/apps/docs/content/sdk-examples/laravel.mdx index 8e12c7c23..0cb51ab96 100644 --- a/apps/docs/content/sdk-examples/laravel.mdx +++ b/apps/docs/content/sdk-examples/laravel.mdx @@ -33,23 +33,23 @@ The application demonstrates proper **[federated logout](https://zitadel.com/doc ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-laravel). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` APP_KEY=your-app-key APP_ENV=local diff --git a/apps/docs/content/sdk-examples/nestjs.mdx b/apps/docs/content/sdk-examples/nestjs.mdx index 7863cb4d1..924ec0658 100644 --- a/apps/docs/content/sdk-examples/nestjs.mdx +++ b/apps/docs/content/sdk-examples/nestjs.mdx @@ -35,22 +35,22 @@ All protected routes are secured using the [@mridang/nestjs-auth global guard](h ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your Zitadel application configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-nestjs). -2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use the exact environment variable names from the repository:** +2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use the exact environment variable names from the repository:** ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/nextjs.mdx b/apps/docs/content/sdk-examples/nextjs.mdx index ed7c2e008..f2ac0a6c7 100644 --- a/apps/docs/content/sdk-examples/nextjs.mdx +++ b/apps/docs/content/sdk-examples/nextjs.mdx @@ -33,23 +33,23 @@ The logout flow implements **[federated logout](https://zitadel.com/docs/guides/ ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/api/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/api/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production deployments, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/login-users): 1. Clone the [repository](https://github.com/zitadel/example-auth-nextjs). -2. Create a `.env.local` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). Use these environment variable names exactly as shown: +2. Create a `.env.local` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). Use these environment variable names exactly as shown: ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/nuxtjs.mdx b/apps/docs/content/sdk-examples/nuxtjs.mdx index 0f098b7da..387b26ba3 100644 --- a/apps/docs/content/sdk-examples/nuxtjs.mdx +++ b/apps/docs/content/sdk-examples/nuxtjs.mdx @@ -31,9 +31,9 @@ The example implements secure [session management](https://authjs.dev/concepts/s ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/api/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000`) @@ -46,7 +46,7 @@ Before running this example, you need to create and configure a PKCE application Once you have your Zitadel application configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-nuxtjs). -2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` PORT=3000 SESSION_DURATION=3600 @@ -59,7 +59,7 @@ Once you have your Zitadel application configured: AUTH_ORIGIN=http://localhost:3000 ``` Replace these values with: - - Your actual Zitadel instance URL (the **Issuer** from your [Zitadel instance settings](https://zitadel.com/docs/guides/manage/console/overview)) + - Your actual Zitadel instance URL (the **Issuer** from your [Zitadel instance settings](https://zitadel.com/docs/guides/manage/console/console-overview)) - The **Client ID** you copied when creating the application - A randomly generated **NUXT_AUTH_SECRET** for session encryption (generate using: `node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"`) - The **callback URI** you configured in the PKCE setup (must match exactly) diff --git a/apps/docs/content/sdk-examples/qwik.mdx b/apps/docs/content/sdk-examples/qwik.mdx index 361804aec..dcdf0ce40 100644 --- a/apps/docs/content/sdk-examples/qwik.mdx +++ b/apps/docs/content/sdk-examples/qwik.mdx @@ -23,7 +23,7 @@ This example uses **[@auth/qwik](https://www.npmjs.com/package/@auth/qwik)**, a This [Qwik](https://qwik.dev) application showcases a complete authentication implementation using [Zitadel](https://qwik.dev) application showcases a complete authentication implementation using [Zitadel](https://zitadel.com/docs) with the [Authorization Code Flow with PKCE](https://qwik.dev). The example includes secure sign-in functionality that redirects users to Zitadel's hosted login page, handles the OAuth callback to exchange authorization codes for [access tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token_endpoint), and manages sessions with [JWT tokens](https://qwik.dev) application showcases a complete authentication implementation using [Zitadel](https://zitadel.com/docs) with the [Authorization Code Flow with PKCE](https://oauth.net/2/pkce/). The example includes secure sign-in functionality that redirects users to Zitadel's hosted login page, handles the OAuth callback to exchange authorization codes for [access tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-endpoint), and manages sessions with [JWT tokens](https://zitadel.com/docs/apis/openidoauth/endpoints#token-jwt-response) stored in encrypted server-side cookies. -Route protection is implemented using [Qwik City's](https://qwik.dev/docs/qwikcity) `onRequest` handler, which performs server-side authentication checks before rendering protected pages. Unauthenticated users attempting to access secured routes are automatically redirected to the login page with a callback URL to return them to their intended destination after successful authentication. The application displays comprehensive user profile information including standard [OIDC claims](https://zitadel.com/docs/apis/openidoauth/claims) like name and email, as well as Zitadel-specific claims such as [organization membership](https://zitadel.com/docs/guides/manage/console/organizations) and [project roles](https://zitadel.com/docs/guides/manage/console/projects). +Route protection is implemented using [Qwik City's](https://qwik.dev/docs/qwikcity) `onRequest` handler, which performs server-side authentication checks before rendering protected pages. Unauthenticated users attempting to access secured routes are automatically redirected to the login page with a callback URL to return them to their intended destination after successful authentication. The application displays comprehensive user profile information including standard [OIDC claims](https://zitadel.com/docs/apis/openidoauth/claims) like name and email, as well as Zitadel-specific claims such as [organization membership](https://zitadel.com/docs/guides/manage/console/organizations-overview) and [project roles](https://zitadel.com/docs/guides/manage/console/projects-overview). Sign-out functionality implements **[federated logout](https://zitadel.com/docs/guides/integrate/login/oidc/logout)** through Zitadel's end-session endpoint, ensuring that users are logged out from both the application and Zitadel's single sign-on session. The logout process includes [CSRF protection](https://zitadel.com/docs/guides/integrate/login/oidc/logout#csrf-protection) using state parameters validated through secure cookies, followed by proper cleanup of session data and redirection back to the application. @@ -33,22 +33,22 @@ Sign-out functionality implements **[federated logout](https://zitadel.com/docs/ ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/api/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-qwik). -2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications): +2. Create a `.env.local` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview): ``` VITE_PORT=3000 VITE_SESSION_SECRET=your-very-secret-and-strong-session-key diff --git a/apps/docs/content/sdk-examples/react.mdx b/apps/docs/content/sdk-examples/react.mdx index 9c743216d..182264502 100644 --- a/apps/docs/content/sdk-examples/react.mdx +++ b/apps/docs/content/sdk-examples/react.mdx @@ -33,22 +33,22 @@ The example leverages [React Router](https://reactrouter.com) for client-side na ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your Zitadel application configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-react). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` VITE_ZITADEL_DOMAIN=https://your-instance.zitadel.cloud VITE_ZITADEL_CLIENT_ID=your_client_id_from_console diff --git a/apps/docs/content/sdk-examples/solidstart.mdx b/apps/docs/content/sdk-examples/solidstart.mdx index 39b32550c..4ec2eb8e1 100644 --- a/apps/docs/content/sdk-examples/solidstart.mdx +++ b/apps/docs/content/sdk-examples/solidstart.mdx @@ -31,22 +31,22 @@ The application implements automatic [token refresh](https://zitadel.com/docs/ap ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/api/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/api/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-solidstart). -2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). Use the exact environment variable names from the repository: +2. Create a `.env` file and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). Use the exact environment variable names from the repository: ``` NODE_ENV=development PORT=3000 diff --git a/apps/docs/content/sdk-examples/sveltekit.mdx b/apps/docs/content/sdk-examples/sveltekit.mdx index 4c6a7e8e0..0812b850e 100644 --- a/apps/docs/content/sdk-examples/sveltekit.mdx +++ b/apps/docs/content/sdk-examples/sveltekit.mdx @@ -33,22 +33,22 @@ The logout flow implements **[federated logout](https://zitadel.com/docs/guides/ ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback/zitadel` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your Zitadel application configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-sveltekit). -2. Create a `.env.local` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env.local` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` SESSION_SECRET=your-very-secret-and-strong-session-key SESSION_DURATION=3600 diff --git a/apps/docs/content/sdk-examples/symfony.mdx b/apps/docs/content/sdk-examples/symfony.mdx index 4f3f062a8..6e5c069d9 100644 --- a/apps/docs/content/sdk-examples/symfony.mdx +++ b/apps/docs/content/sdk-examples/symfony.mdx @@ -33,23 +33,23 @@ The application demonstrates proper **[federated logout](https://zitadel.com/doc ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000/auth/logout/callback`) 5. Copy your **Client ID** for use in the next steps 6. Optionally enable [refresh tokens](https://zitadel.com/docs/apis/openidoauth/grant-types#refresh-token) in Token Settings for long-lived sessions -> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [Zitadel Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example -Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications) configured: +Once you have your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview) configured: 1. Clone the [repository](https://github.com/zitadel/example-auth-symfony). -2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications). **Use these exact environment variable names:** +2. Create a `.env` file (copy from `.env.example`) and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview). **Use these exact environment variable names:** ``` APP_SECRET=your-app-secret-key SERVER_URL=http://localhost:3000 diff --git a/apps/docs/content/sdk-examples/vue.mdx b/apps/docs/content/sdk-examples/vue.mdx index 3e3ab9307..0d550e0cf 100644 --- a/apps/docs/content/sdk-examples/vue.mdx +++ b/apps/docs/content/sdk-examples/vue.mdx @@ -33,22 +33,22 @@ The example includes secure sign-out functionality implementing **[federated log ### Prerequisites -Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview). Follow the PKCE application setup guide to: +Before running this example, you need to create and configure a PKCE application in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview). Follow the PKCE application setup guide to: -1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects) +1. Create a new Web application in your [Zitadel project](https://zitadel.com/docs/guides/manage/console/projects-overview) 2. Configure it to use the PKCE authentication method 3. Set up your redirect URIs (e.g., `http://localhost:3000/auth/callback` for development) 4. Configure post-logout redirect URIs (e.g., `http://localhost:3000`) 5. Copy your **Client ID** for use in the next steps -> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. +> **Note:** Make sure to enable **Dev Mode** in the [ZITADEL Management Console](https://zitadel.com/docs/guides/manage/console/console-overview) if you're using HTTP URLs during local development. For production, always use HTTPS URLs and disable Dev Mode. ### Run the example Once you have your [Zitadel application configured](https://zitadel.com/docs/guides/integrate/login/oidc/login-users), follow these steps: 1. Clone the [repository](https://github.com/zitadel/example-auth-vuejs). -2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications): +2. Create a `.env` file in the project root and configure it with the values from your [Zitadel application](https://zitadel.com/docs/guides/manage/console/applications-overview): ``` VITE_ZITADEL_DOMAIN=https://your-instance.zitadel.cloud VITE_ZITADEL_CLIENT_ID=your_client_id_from_console diff --git a/apps/docs/redirects.json b/apps/docs/redirects.json index f7929b7fb..59482ed1f 100644 --- a/apps/docs/redirects.json +++ b/apps/docs/redirects.json @@ -3153,5 +3153,65 @@ "source": "/apis/resources/webkey_service_v2/zitadel-webkey-v-2-web-key-service-list-web-keys", "destination": "/reference/api/webkey/zitadel.webkey.v2.WebKeyService.ListWebKeys", "permanent": true + }, + { + "source": "/guides/manage/console/actions", + "destination": "/guides/manage/console/actions-overview", + "permanent": true + }, + { + "source": "/guides/manage/console/applications", + "destination": "/guides/manage/console/applications-overview", + "permanent": true + }, + { + "source": "/guides/manage/console/organizations", + "destination": "/guides/manage/console/organizations-overview", + "permanent": true + }, + { + "source": "/guides/manage/console/projects", + "destination": "/guides/manage/console/projects-overview", + "permanent": true + }, + { + "source": "/guides/manage/console/users", + "destination": "/guides/manage/console/users-overview", + "permanent": true + }, + { + "source": "/apis/actions/introduction", + "destination": "/guides/manage/console/actions-overview", + "permanent": true + }, + { + "source": "/concepts/structure/applications", + "destination": "/guides/manage/console/applications-overview", + "permanent": true + }, + { + "source": "/concepts/structure/organizations", + "destination": "/guides/manage/console/organizations-overview", + "permanent": true + }, + { + "source": "/concepts/structure/projects", + "destination": "/guides/manage/console/projects-overview", + "permanent": true + }, + { + "source": "/concepts/structure/users", + "destination": "/guides/manage/console/users-overview", + "permanent": true + }, + { + "source": "/concepts/features/console", + "destination": "/guides/manage/console/console-overview", + "permanent": true + }, + { + "source": "/guides/manage/console/overview", + "destination": "/guides/manage/console/console-overview", + "permanent": true } ] \ No newline at end of file