mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-07 14:52:15 +00:00
## Todos for release - [x] Configure Env in docs project on vercel - [x] Configure Root Path in the docs project on vercel - [ ] Remove old CSP https://github.com/zitadel/website/pull/1592 ## What we did This pull request migrates the project documentation from the old `docs/` directory to the new `apps/docs/` directory, introduces a new documentation system built with Next.js and Fumadocs, and updates all relevant references, configuration files, and documentation to reflect this change. It also adds new configuration and ignore files for the new documentation app, updates CI and linting to exclude the new docs from certain checks, and revises the contributing guidelines accordingly. **Documentation System Migration and New Docs App** * Migrated all documentation from `docs/` to `apps/docs/`, and updated all references in `README.md`, `CONTRIBUTING.md`, and other files to point to the new location. [[1]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L585-L640) [[2]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L660-R607) [[3]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L740-R687) [[4]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L2-R3) [[5]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L30-R30) * Added a new Next.js/Fumadocs-based documentation app under `apps/docs/`, including core app files, layouts, routing, search API, and a comprehensive `README.md` with development and contribution instructions. [[1]](diffhunk://#diff-5a1b07344a2c1b4d3f37b23ff1388b62cd9f57dea3c1cd23d8a0412b7602b132R1-R74) [[2]](diffhunk://#diff-462b9ad1eabbb7d1c29bb9c36e4931eb180fd7190900e6d2babf8f4d66ad1c28R1-R39) [[3]](diffhunk://#diff-e16ae25660ded787b10ac35dea96d5ecaacf895dae0afc8a9bd4382dc79a8c87R1-R7) [apps/docs/app/[[...slug]]/layout.tsxR1-R81](diffhunk://#diff-59e08acde4e805b7aeccef1dcf98f1d71dfc550777e6b9402085cee0e9fa4e0aR1-R81), [apps/docs/app/[[...slug]]/page.tsxR1-R79](diffhunk://#diff-e5df3f80d0fa01e12d63d81f29c57a9d14e846c78fd3beabb2ef768e38fd9580R1-R79), [[4]](diffhunk://#diff-389b34918e040cacaa87cd7201ffa462cc2b0b716736f537e3d3c660ac69353bR1-R7) [[5]](diffhunk://#diff-d3b03416d1c457b19f1c27b26f2db741412df841b875c26ccadc36e4522247f4R1-R29) [[6]](diffhunk://#diff-c8fb8339570a5305809be7c618e14705fd86390dc278e6ce8ba224a7bc8b0c3cR1-R25) **Configuration and Tooling Updates** * Updated `.github/workflows/codeql.yml`, `.golangci.yaml`, and `.github/dependabot.yml` to properly handle the new docs app: excluded `apps/docs` from certain checks, added npm dependency updates for the docs app, and excluded generated content. [[1]](diffhunk://#diff-12783128521e452af0cfac94b99b8d250413c516ec71fe6d97dbea666ff7ba27L8-R14) [[2]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R5-R6) [[3]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R126-R129) [[4]](diffhunk://#diff-dd4fbda47e51f1e35defb9275a9cd9c212ecde0b870cba89ddaaae65c5f3cd28R89-R106) * Updated `.devcontainer/devcontainer.json` to use the latest Go 1.25.3 version for consistency. **Licensing and Miscellaneous** * Added `apps/docs/` to the list of licensed directories in `LICENSING.md`. These changes ensure the documentation is now maintained in a modern, scalable system and all project tooling is updated to support the new structure. --------- Co-authored-by: Federico Coppede <[email protected]>
94 lines
3.7 KiB
Plaintext
94 lines
3.7 KiB
Plaintext
---
|
|
title: Authenticate users with OpenID Connect
|
|
sidebar_label: OIDC Code Flow + PKCE
|
|
---
|
|
|
|
import AuthMethods from "./_authmethods.mdx";
|
|
|
|
## Overview
|
|
|
|
This guide will show you how to use ZITADEL to login users into your application (authentication).
|
|
It will guide you step-by-step through the basics and point out on how to customize process.
|
|
|
|
## OIDC / OAuth Flow
|
|
|
|
OAuth and therefore OIDC know three different application types:
|
|
|
|
- Web (Server-side web applications such as java, .net, ...)
|
|
- Native (native, mobile or desktop applications)
|
|
- User Agent (single page applications / SPA, generally JavaScript executed in the browser)
|
|
|
|
Depending on the app type you're trying to register, there are small differences.
|
|
But regardless of the app type we recommend using Proof Key for Code Exchange (PKCE).
|
|
|
|
Please read the following guide about the [different-client-profiles](./oauth-recommended-flows#different-client-profiles) and why to use PKCE.
|
|
|
|
### Code Flow
|
|
|
|
For a basic understanding of OAuth and its flows, we'll briefly describe the most important flow: **Authorization Code**.
|
|
|
|
The following diagram demonstrates a basic authorization_code flow:
|
|
|
|

|
|
|
|
1. When an unauthenticated user visits your application,
|
|
2. you will create an authorization request to the authorization endpoint.
|
|
3. The Authorization Server (ZITADEL) will send an HTTP 302 to the user's browser, which will redirect them to the login UI.
|
|
4. The user will have to authenticate using the demanded auth mechanics.
|
|
5. Your application will be called on the registered callback path (redirect_uri) and be provided an authorization_code.
|
|
6. This authorization_code must then be sent together with you applications authentication (client_id + client_secret) to the token_endpoint
|
|
7. In exchange the Authorization Server (ZITADEL) will return an access_token and if requested a refresh_token and in the case of OIDC an id_token as well
|
|
8. The access_token can then be used to call a Resource Server (API). The token will be sent as Authorization Header.
|
|
|
|
This flow is the same when using PKCE or JWT with Private Key for authentication.
|
|
|
|
## Create Application
|
|
|
|
To create an application, open your project in Management Console and start by clicking on the "New" button in the Application section.
|
|
|
|
#### Application type
|
|
|
|
This will start a wizard asking you for an application name and a type.
|
|
|
|
<Tabs
|
|
groupId="app-type"
|
|
default="web"
|
|
values={[
|
|
{'label': 'Web Application', 'value': 'web'},
|
|
{'label': 'Native Application', 'value': 'native'},
|
|
{'label': 'Single Page Application', 'value': 'spa'},
|
|
]}
|
|
>
|
|
<Tab value="web">
|
|
|
|
#### Authentication method
|
|
|
|
After selecting WEB, you'll next have to choose an authentication method. As mentioned before we recommend using PKCE.
|
|
For even better security you could switch to JWT or just rely on the standard Code Flow. For security reasons we don't
|
|
recommend using POST and will not cover it in this guide.
|
|
|
|
Please change the authentication method here as well, if you did so in the wizard, so we can better guide you through the process:
|
|
|
|
<AuthMethods components={props.components} selected="web" />
|
|
</Tab>
|
|
|
|
<Tab value="native">
|
|
|
|
#### Authentication method
|
|
|
|
When selecting Native the authentication method always needs to be PKCE.
|
|
|
|
<AuthMethods components={props.components} selected="native" />
|
|
</Tab>
|
|
|
|
<Tab value="spa">
|
|
|
|
#### Authentication method
|
|
|
|
When selecting SPA the recommended authentication method is again PKCE. All common Frameworks like Angular, React, Vue.js and so on
|
|
are able to successfully authenticate with PKCE. Our management console UI for instance uses PKCE as well.
|
|
|
|
<AuthMethods components={props.components} selected="spa" />
|
|
</Tab>
|
|
</Tabs>
|