mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-22 15:32: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]>
109 lines
5.2 KiB
Plaintext
109 lines
5.2 KiB
Plaintext
---
|
|
title: Configure client credential authentication for service users
|
|
sidebar_label: Client credential authentication
|
|
---
|
|
|
|
This guide demonstrates how developers can leverage Client Credential authentication to secure communication between [service users](/guides/manage/console/users-overview#service-users-machine-accounts) and client applications within ZITADEL.
|
|
|
|
In ZITADEL, the Client Credentials Flow can be used for this [non-interactive authentication](./authenticate-service-users) as alternative to the [JWT profile authentication](./authenticate-service-users).
|
|
|
|
## Steps to authenticate a Service User with client credentials
|
|
|
|
### 1. Create a Service User with a client secret
|
|
|
|
1. Navigate to Service Users
|
|
2. Click on **New**
|
|
3. Enter a username and a display name
|
|
4. Click on **Create**
|
|
5. Open **Actions** in the top right corner and click on **Generate Client Secret**
|
|
6. Copy the **ClientID** and **ClientSecret** from the dialog
|
|
|
|
<Callout>
|
|
Make sure to copy in particular the ClientSecret. You won't be able to retrieve it again.
|
|
If you lose it, you will have to generate a new one.
|
|
</Callout>
|
|
|
|

|
|
|
|
### 2. Authenticating a service user and request a token
|
|
|
|
In this step, we will authenticate a service user and receive an access_token to use against the ZITADEL API.
|
|
|
|
You will need to craft a POST request to ZITADEL's token endpoint:
|
|
|
|
```bash
|
|
curl --request POST \
|
|
--url https://${CUSTOM_DOMAIN}/oauth/v2/token \
|
|
--header 'Content-Type: application/x-www-form-urlencoded' \
|
|
--data grant_type=client_credentials \
|
|
--data scope='openid profile' \
|
|
--user "$CLIENT_ID:$CLIENT_SECRET"
|
|
```
|
|
|
|
* `CUSTOM_DOMAIN` should be set to your [Custom Domain](/concepts/features/custom-domain)
|
|
* `grant_type` should be set to `client_credentials`
|
|
* `scope` should contain any [Scopes](/apis/openidoauth/scopes) you want to include, but must include `openid`. For this example, please include `profile`
|
|
* `CLIENT_ID` and `CLIENT_SECRET` should be set with the values shown in Management Console when generating a new secret to enable [basic authentication](/apis/openidoauth/authn-methods)
|
|
|
|
If you want to access ZITADEL APIs, make sure to include the required scopes `urn:zitadel:iam:org:project:id:zitadel:aud`.
|
|
Read our guide [how to access ZITADEL APIs](../zitadel-apis/access-zitadel-apis) to learn more.
|
|
|
|
**Important Note:** If the service user token needs to be validated using token introspection, ensure you include the `urn:zitadel:iam:org:project:id:{projectid}:aud` scope in your token request.
|
|
Without this, token introspection will fail.
|
|
|
|
You should receive a successful response with `access_token`, `token_type` and time to expiry in seconds as `expires_in`.
|
|
|
|
```bash
|
|
HTTP/1.1 200 OK
|
|
Content-Type: application/json
|
|
|
|
{
|
|
"access_token": "MtjHodGy4zxKylDOhg6kW90WeEQs2q...",
|
|
"token_type": "Bearer",
|
|
"expires_in": 43199
|
|
}
|
|
```
|
|
|
|
Per default a service user will get an opaque access token.
|
|
If you want to get a Jason Web Token (JWT) as an access token for your user, you can change the token type in the general settings of your service account.
|
|
To learn more about opaque and JWT tokens read our [Opaque Tokens in ZITADEL: Enhancing Application Security](/concepts/knowledge/opaque-tokens) Guide
|
|
|
|

|
|
|
|
### 3. Include the access token in the authorization header
|
|
|
|
When making API requests on behalf of the service user, include the generated token in the "Authorization" header with the "Bearer" prefix.
|
|
|
|
```bash
|
|
curl --request POST \
|
|
--url $YOUR_API_ENDOINT \
|
|
--header 'Content-Type: application/x-www-form-urlencoded' \
|
|
--header 'Authorization: Bearer MtjHodGy4zxKylDOhg6kW90WeEQs2q...'
|
|
```
|
|
|
|
## Accessing ZITADEL APIs
|
|
|
|
You might want to access ZITADEL APIs to manage resources, such as users, or to validate tokens sent to your backend service.
|
|
Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-apis) to use the ZITADEL APIs with your service user using client credentials.
|
|
|
|
### Token introspection
|
|
|
|
Your API endpoint might receive tokens from users and need to validate the token with ZITADEL.
|
|
In this case, your API needs to authenticate with ZITADEL and then do a token introspection.
|
|
Follow our [guide on token introspection with client credentials](../token-introspection/basic-auth) to learn more.
|
|
|
|
## Security considerations
|
|
|
|
* **Store private keys securely:** **Never share or embed the private key in your code or application.** Consider using secure key management solutions.
|
|
* **Set appropriate expiration times:** Limit the validity period of tokens to minimize the impact of potential compromise.
|
|
|
|
By following these steps and adhering to security best practices, you can effectively secure service user and client application communication within ZITADEL using client credential authentication.
|
|
|
|
## Notes
|
|
|
|
* Read about the [different methods to authenticate service users](./authenticate-service-users)
|
|
* [Service User API reference](/reference/api/user)
|
|
* [OIDC client secret basic](/apis/openidoauth/authn-methods#client-secret-basic) authentication method reference
|
|
* [Access ZITADEL APIs](../zitadel-apis/access-zitadel-apis)
|
|
* Validate access tokens with [token introspection with basic auth](../token-introspection/basic-auth)
|