Appearance
Подключение стороннего приложения к SSO
Этот раздел — для команды, которая администрирует своё приложение (сайт, CLI, бэкенд-сервис) и хочет добавить в него вход через данный SSO-сервер (OpenID Connect Identity Provider).
Кому подойдёт этот раздел: руководителю проекта, техлиду или разработчику, ответственному за интеграцию своего приложения с корпоративным/платформенным SSO.
Весь путь целиком
1. Регистрация аккаунта /register
│
2. Заявка на организацию /account/org-requests/new
│ (название, описание, причина)
▼
3. Ожидание решения глобального администратора SSO
│
├── Отклонено ──→ причина видна в /account/org-requests, cooldown 3 дня, заявку можно подать снова
│
▼ Одобрено
4. Автоматически, атомарно:
- создаётся организация
- вы становитесь её участником с role: "admin"
- вам выдаётся роль org-admin
│
▼
5. В меню появляется пункт «⚙️ Админ» — доступна /admin, ограниченная вашей организацией
│
▼
6. Регистрация OAuth-клиента /admin/clients/new
(название, redirect URI, scope, брендирование, эндпоинты логаута)
│
▼
7. Выбор направления интеграции — зависит от типа вашего приложения:
┌─────────────────┬──────────────────────┬───────────────────────────┐
│ Web-приложение │ CLI / без браузера │ Сервис без пользователя │
│ (браузер есть) │ (Device Flow) │ (M2M, Client Credentials)│
└─────────────────┴──────────────────────┴───────────────────────────┘
│
▼
8. Продакшн: мониторинг токенов, отзыв, план на компрометацию секретаСтруктура раздела
| # | Файл | Что внутри |
|---|---|---|
| 1 | 00-overview.md | Этот файл — карта всего пути |
| 2 | 01-organization-and-access.md | Как получить доступ к панели администратора: заявка на организацию и что происходит после одобрения |
| 3 | 02-client.md | Регистрация и настройка OAuth-клиента: поля формы, client_id/client_secret, брендирование, RBAC-клеймы |
| 4 | 03-web-app.md | Направление Web: Authorization Code + PKCE, обновление токена, logout |
| 5 | 04-cli-app.md | Направление CLI: Device Authorization Grant |
| 6 | 05-service-to-service.md | Направление M2M: Client Credentials Grant |
| 7 | 06-operations.md | Эксплуатация: компрометация секрета, /introspect, /revoke, лимиты, справочник ошибок, чек-лист перед продакшном |
Прежде чем начать — три развилки
Нужна ли вам организация? Организация — это мультитенантность: изоляция пользователей, своя политика входа (обязательный MFA, домены email, время жизни сессии), своя видимость в панели администратора. Самостоятельная заявка на организацию нужна, если вы хотите сами управлять своими клиентами, пользователями и политикой входа.
Какое у вас приложение — web, CLI или сервис без пользователя? Это определяет, какой grant type использовать (раздел 4, 5 или 6). У одного OAuth-клиента может быть несколько направлений сразу — например, веб-панель и сопутствующий CLI-инструмент можно завести как два отдельных клиента с общей организацией, либо как один клиент, если это уместно.
У организации может быть сколько угодно клиентов, но у клиента — не более одной организации.organizationId задаётся на уровне OAuth-клиента: одно значение или пусто, привязать один клиент сразу к двум организациям нельзя. Обратное ограничений не имеет — заводите под одной организацией любое количество клиентов (веб, CLI, отдельные продукты), если у них разная политика входа или разные redirect URI.
Управлять вы сможете только одной организацией. Технически пользователь может состоять в нескольких организациях (OrgMembership — отдельная таблица), но панель org-admin использует только первое найденное членство с role: "admin" — остальные организации, даже если вы в них состоите, через /admin будут недоступны. Поэтому на практике: если вы администрируете несколько организаций, для полноценного управления второй потребуется отдельный аккаунт. Подробности — 01-organization-and-access.md.