Токены пользовательской плоскости

Обменяйте логин-сессию на короткоживущий токен под этот сервис, и как маппятся роли.

Пользовательская плоскость принимает ровно один вид токена: короткоживущий exchange-токен, отчеканенный identity-провайдером (auth.console) с audience provider-credentials-service. Логин/менеджмент-токен — даже валидный — отклоняется: дисциплина audience — это один JWT, один целевой сервис.

Флоу

1. Залогиньтесь у identity-провайдера: POST /v1/auth/login. Аккаунты, состоящие в нескольких организациях, получают status: org_selection_required и завершают через POST /v1/auth/select-org — выбранная организация становится org_id токена.
2. Обменяйте сессию на токен под сервис: POST /v1/auth/token/exchange с {"audience": "provider-credentials-service"}. Результат — access-only JWT (ES256, живёт минуты, без refresh), несущий sub (UUID пользователя), org_id и сырые организационные roles.
3. Вызывайте этот сервис с Authorization: Bearer <token>. Когда токен истечёт, обменяйте снова — ваш якорь обновления — логин-сессия, а не этот сервис.

import httpx

auth = httpx.post(f"{AUTH_BASE}/v1/auth/login", json={"email": EMAIL, "password": PASSWORD}).json()
# ... handle org selection / MFA states per the auth service's own docs ...
exchange = httpx.post(
    f"{AUTH_BASE}/v1/auth/token/exchange",
    headers={"Authorization": f"Bearer {auth['access_token']}"},
    json={"audience": "provider-credentials-service"},
).json()
TOKEN = exchange["access_token"]

Identity-провайдер публикует собственную вики разработчика с полной стейт-машиной логина; эта страница покрывает только то, что нужно от него этому сервису.

Что должен нести токен

• iss/aud — сконфигурированный издатель и provider-credentials-service; всё прочее — 401.
• sub — пользователь, канонический UUID (неканонические формы отклоняются).
• org_id — опционален; если присутствует — канонический UUID. Отсутствие означает «нет контекста организации»: Organization Credentials отвечает 403, а Credential Status сообщает null для уровня организации.
• roles — сырые организационные роли (owner, admin, member, viewer).

Как маппятся роли

Два независимых маппинга читают один и тот же клейм roles:

1. Сервисные роли (JWT_ROLE_MAP, по умолчанию owner→user, admin→user, member→user): дают роль §5.1, которая гейтит эндпоинты. viewer не маппится ни во что — такие токены получают 401. Повышенные роли (provider_admin, auditor) никогда не выводятся из орг-ролей по умолчанию; их выдача — осознанное решение развёртывания.
2. Менеджеры организации (JWT_ORG_MANAGER_ROLES, по умолчанию owner,admin): сверяются с сырыми ролями, чтобы гейтить Organization Credentials — намеренно переживая сплющивание выше.

Итак, дефолтное развёртывание читается так: каждый участник организации — user; управляют credentials организации только владельцы и админы.