mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-24 16:22: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).
61 lines
2.7 KiB
Plaintext
61 lines
2.7 KiB
Plaintext
---
|
|
title: Migrate from Generic to Specific Identity Provider
|
|
description: "Migrate from generic OIDC provider to Entra ID or Google using API requests or Terraform for user connectivity"
|
|
sidebar_label: Migrate IdP
|
|
---
|
|
|
|
## Migrate Generic OIDC Provider
|
|
|
|
You can migrate from a generic OIDC provider to the following supported templates:
|
|
|
|
- Entra ID (former Azure Active Directory)
|
|
- Google
|
|
|
|
To migrate, you either use the [Migrate Generic OIDC Identity Provider (Instance)](/reference/api/admin/zitadel.admin.v1.AdminService.MigrateGenericOIDCProvider) or [Migrate Generic OIDC Identity Provider (Organization)](/reference/api/management/zitadel.management.v1.ManagementService.MigrateGenericOIDCProvider) API request.
|
|
These calls change the type of the provider and don't delete any linked users.
|
|
|
|
<Callout title="Linked users will not notice the change and be able to login as usual.">
|
|
</Callout>
|
|
|
|
### Google Configuration
|
|
|
|
The available settings are described in [Google Configuration](./google).
|
|
|
|
### Entra ID Configuration
|
|
|
|
The available settings are described in [Entra ID Configuration](./azure-ad-oidc).
|
|
|
|
## Migrate with Terraform
|
|
|
|
Please note that you only have to perform this migration if you already have an existing IDP with linked users, that should not loose the connection to the provider.
|
|
If that isn't your case please just add a new provider from scratch.
|
|
To migrate to a specific provider, you need to follow a few essential steps:
|
|
1. Create a desired IDP as Terraform resource for example [Google](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/idp_google).
|
|
2. Remove the old terraform resource from the state as to not destroy the migrated IDP accidentally.
|
|
```bash
|
|
# terraform state rm *address*
|
|
terraform state rm zitadel_idp_oidc.oidc_idp
|
|
```
|
|
|
|
After this command you can also remove the resource from the terraform files, as it is not managed anymore but also not deleted.
|
|
|
|
3. Make the corresponding API call to [migrate the IDP](./migrate#migrate-generic-oidc-provider), save the ID of the IDP for the import
|
|
4. Before applying the Terraform resources again, import the new IDP resource.
|
|
```bash
|
|
#resource "zitadel_idp_google" "google" {
|
|
# name = "Google"
|
|
# client_id = "182902..."
|
|
# client_secret = "GOCSPX-*****"
|
|
# scopes = ["openid", "profile", "email"]
|
|
# is_linking_allowed = false
|
|
# is_creation_allowed = true
|
|
# is_auto_creation = false
|
|
# is_auto_update = true
|
|
#}
|
|
|
|
# terraform import zitadel_idp_google.*resource_name* *id*:*client_secret*
|
|
terraform import zitadel_idp_google.google 222302827723096428:GOCSPX-*****
|
|
```
|
|
|
|
You have now migrated your provider and you should be able to apply the resource again. There should be no changes and the IDP is maintained by Terraform again.
|