mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-22 15:32:15 +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).
74 lines
3.5 KiB
Plaintext
74 lines
3.5 KiB
Plaintext
---
|
|
title: SaaS Authentication and Authorization with ZITADEL
|
|
description: "Multi-tenancy authentication for a SaaS product using ZITADEL."
|
|
sidebar_label: Software-as-a-Service
|
|
---
|
|
|
|
This is an example architecture for a typical SaaS product.
|
|
To illustrate it, a fictional organization and project is used.
|
|
|
|
## Example Case
|
|
|
|
The Timing Company has a product called Time.
|
|
They have two environments, the development and the production environment.
|
|
In this case Time uses authentication and authorizations from ZITADEL.
|
|
This means that the users and also their authorizations will be managed within ZITADEL.
|
|
|
|
|
|
|
|
## Organization
|
|
|
|
An organization is the ZITADEL resource that contains users, projects, applications, policies and so on.
|
|
The organization manages the projects and users.
|
|
You need at least one organization for your own company, in our case "The Timing Company."
|
|
Your next step is to create an organization for each of your customers.
|
|
|
|
## Project
|
|
|
|
The idea of projects is to have a vessel for all components who are closely related to each other.
|
|
|
|
In this use case, we would have two different projects, one each for the Development and Production environments.
|
|
Let us call them "Time Dev" and "Time Prod". These projects should be created in "The Timing Company" organization.
|
|
|
|
In the project you will configure all your roles and applications (clients and APIs).
|
|
|
|
### Project Settings
|
|
|
|
Enable the `Only authorized users can authenticate` setting on the project to restrict authentication to users with at least one role assigned to this project.
|
|
|
|
### Project Grant
|
|
|
|
To grant a customer permission to a project, a project grant to the customer's organization is needed (search the granted organization by its domain).
|
|
It is also possible to delegate only specific roles of the project to a certain customer.
|
|
As soon as a project grant exists, the customer will see the project in the granted projects section of their organization and will be able to assign roles to their own users to the given project.
|
|
|
|
## Role Assignments
|
|
|
|
To give a user permission to a project, a role assignment is needed.
|
|
All organizations that own projects or received a grant can assign roles to users to have access to projects.
|
|
It is also possible to assign roles to users outside the own company if the exact login name of the user is known.
|
|
|
|
## Project Login
|
|
|
|
There are some different use cases how the login should behave and look like:
|
|
|
|
1. Restrict Organization
|
|
|
|
With the Organization Domain scope the organization will be restricted to the requested domain, this means only users of the requested organization will be able to log in.
|
|
The private labeling (branding) and the login policy of the requested organization will be set automatically.
|
|
|
|
<Callout>
|
|
More about the [Scopes](/apis/openidoauth/scopes)
|
|
</Callout>
|
|
|
|
2. Show private labeling (branding) of the project organization
|
|
|
|
You can configure on project-level which branding should be shown to users.
|
|
In the default the design of the instance will be shown, but as soon as the user is identified, the policy of the users organization (if specified) will be triggered.
|
|
If the setting is set to `Ensure Project Resource Owner Setting`, the private labeling of the project organization will always be triggered.
|
|
The last possibility is to show the private labeling of the project organization, and as soon as the user is identified, the user organization settings will be triggered.
|
|
For this the Allow User Resource Owner Setting should be set.
|
|
<Callout>
|
|
More about [Private Labeling](/guides/manage/customize/branding)
|
|
</Callout>
|