mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-05 05:42:16 +00:00
Florian ForsterandGitHub
2763e93a61
## What
Shorten the `title` frontmatter on 20 docs pages so that the rendered
`<title>` tag stays within the 70-character SEO limit.
The root layout appends ` | ZITADEL Docs` (15 chars) to every page
title, meaning the raw frontmatter `title` must be ≤ 55 characters. A
site scan flagged all 20 pages for the "Title too long" warning (titles
ranged from 71 to 92 characters in the final rendered tag).
## Why
Search engines may truncate or ignore `<title>` tags longer than 70
characters, hurting click-through rates and keyword relevance in search
results.
## How
Each title was rewritten to:
- Fit within 55 characters (leaving room for ` | ZITADEL Docs`)
- Front-load the primary search keyword (product name, protocol, or
feature)
- Include "ZITADEL" where users realistically search for `{feature}
ZITADEL`
- Avoid generic filler words ("Configure", "Set up", "Support for")
All 20 files already have a `sidebar_label` field that preserves the
original descriptive title for sidebar navigation — no navigation
changes result from this PR.
## Pages updated
| Page | Before (chars) | After (chars) |
|---|---|---|
| concepts/features/passkeys | 82 | 64 |
| guides/integrate/identity-providers/openldap | 72 | 58 |
| guides/solution-scenarios/b2b | 78 | 59 |
| guides/integrate/services/cloudflare-oidc | 86 | 54 |
| guides/integrate/login/hosted-login | 71 | 55 |
| guides/integrate/service-accounts/private-key-jwt | 76 | 56 |
| guides/integrate/service-accounts/client-credentials | 78 | 60 |
| guides/integrate/services/google-cloud | 92 | 57 |
| guides/solution-scenarios/saas | 88 | 65 |
| guides/migrate/sources/auth0 | 73 | 65 |
| guides/integrate/login-ui/oidc-standard | 81 | 55 |
| guides/integrate/login-ui/username-password | 73 | 59 |
| guides/integrate/login-ui/device-auth | 78 | 60 |
| guides/integrate/identity-providers/linkedin_oauth | 72 | 58 |
| guides/integrate/identity-providers/pingfederate-saml | 74 | 61 |
| guides/integrate/service-accounts/personal-access-token | 82 | 62 |
| legal/service-description/cloud-service-description | 76 | 61 |
| guides/integrate/login/login-users | 83 | 55 |
| guides/integrate/identity-providers/migrate | 74 | 65 |
| guides/manage/console/projects-overview | 71 | 62 |
All final `<title>` values are between 54 and 66 characters (well under
the 70-char limit).
70 lines
3.3 KiB
Plaintext
70 lines
3.3 KiB
Plaintext
---
|
|
title: Personal Access Token Auth for Service Accounts
|
|
description: "Generate and manage Personal Access Tokens (PAT) for service accounts to enable non-interactive API access to ZITADEL."
|
|
sidebar_label: Personal access token authentication
|
|
---
|
|
|
|
A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header.
|
|
At the moment ZITADEL only allows PATs for service accounts.
|
|
|
|
It is an alternative to the [private key JWT](./private-key-jwt) and [client credentials](./client-credentials). Read more about the different [authentication methods for service accounts](./authenticate-service-accounts).
|
|
|
|
## Create a Service Account with a PAT
|
|
|
|
1. Navigate to Service Accounts
|
|
2. Click on **New**
|
|
3. Enter a username and a display name
|
|
4. Click on the Personal Access Token menu point in the detail of your user
|
|
5. Click on **New**
|
|
6. You can either set an expiration date or leave it empty if you don't want it to expire
|
|
7. Copy the token from the dialog (You will not see this again)
|
|
|
|
|
|
|
|
## Grant role for ZITADEL
|
|
|
|
To be able to access the ZITADEL APIs, your service account needs permissions to ZITADEL.
|
|
|
|
1. Go to the detail page of your organization
|
|
2. Click in the top right corner the "+" button
|
|
3. Search for your service account
|
|
4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators))
|
|
|
|
|
|
|
|
## 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 account.
|
|
|
|
### 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 token introspection.
|
|
Follow our [guide on token introspection with private key JWT](../token-introspection/private-key-jwt) to learn more.
|
|
|
|
## Call ZITADEL API with PAT
|
|
|
|
Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API.
|
|
In this example we read the organization of the service account.
|
|
|
|
```bash
|
|
curl --request GET \
|
|
--url ${CUSTOM_DOMAIN}/management/v1/orgs/me \
|
|
--header 'Authorization: Bearer {PAT}'
|
|
```
|
|
|
|
## Client application authentication
|
|
|
|
The above steps demonstrate service account authentication.
|
|
If your application also needs to authenticate itself, you can utilize [Client Credentials Grant](./client-credentials).
|
|
Refer to ZITADEL documentation for details on this alternative method.
|
|
|
|
## 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 JWT expiration times:** Limit the validity period of tokens to minimize the impact of potential compromise.
|
|
* **Implement proper error handling:** Handle situations where JWT verification fails or tokens are expired.
|
|
|
|
By following these steps and adhering to security best practices, you can effectively secure service account and client application communication within ZITADEL using private key JWT authentication.
|