Как пользоваться порталом разработчика

Станьте разработчиком

Войдите и на главной нажмите «Стать разработчиком». Это включает вам доступ к консоли. Роль разработчика также может выдать администратор.

Создайте приложение

Раздел «Приложения» → форма создания. Укажите название, при необходимости — Redirect URIs и scopes. Портал сгенерирует ClientId и секрет — секрет показывается один раз, сохраните его сразу.

Выберите grant types

Grant type определяет, как приложение получает токены. Кратко:

Оформите приложение

На странице приложения («Настроить»): загрузите логотип (не меньше 512×512 — будет уменьшен до 512×512) и описание в Markdown. И логотип, и описание показываются пользователю на форме входа. Здесь же — время жизни токенов и переключатель reference-токенов.

Опишите роли и claims

Для каждого приложения задайте роли и claims (тип + значение) — это права, которые попадут в токен пользователя при входе в ваше приложение. Claims одного приложения не видны другим.

Назначьте их пользователям

На странице приложения назначьте роль или claim конкретному уже зарегистрированному пользователю — по sub, логину или email. При следующем входе в ваше приложение пользователь получит их в токене.

Объединяйте в группы (по желанию)

Раздел «Группы» даёт двум связанным приложениям два общих ресурса. Первое — приложения группы могут вызывать API друг друга: клиент запрашивает scope соседа (other-app.read), и токен получает его аудиторию. Доступ действует, пока приложение в группе.

Второе (опционально, флажок «claims группы» в настройках приложения) — в токен добавляются claims/роли пользователя из соседних приложений группы с префиксом источника: other-app.role, other-app.department. По умолчанию флажок выключен. Стандартные OIDC-claims профиля (sub, name, email…) всегда плоские и выдаются по scope openid/profile/email.

Как читать роли/claims: если токен выдан одному API (обычный случай) — они плоские (role, department), стандартный [Authorize(Roles=…)] работает без настройки. Если же токен запрошен сразу под несколько API (aud содержит больше одного) — плоская роль была бы неоднозначной (чья именно?), поэтому каждая роль/claim префиксуется владельцем: my-app.role, other-app.role. Тогда читайте свои по своему client_id. Универсальное правило ниже покрывает оба случая.

// Универсально: плоскую роль (одна аудитория) ИЛИ свою префиксную (несколько аудиторий)
var myId = "my-app-1a2b";
var myRoles = User.FindAll("role").Select(c => c.Value)
    .Concat(User.FindAll(myId + ".role").Select(c => c.Value));

var dept = User.FindFirst("department")?.Value
        ?? User.FindFirst(myId + ".department")?.Value;

// Роль пользователя в СОСЕДНЕМ приложении — всегда по его префиксу:
var partnerRole = User.FindFirst("partner-app.role")?.Value;

Управляйте доступом из кода

То же самое можно делать программно из вашего backend через Identity API. Приложение получает токен по client-credentials (scope claims.manage) и назначает claims своим пользователям — например, сразу после регистрации или оплаты.

# 1) получить токен приложения
curl -X POST https://id.local/connect/token \
  -d "grant_type=client_credentials&client_id=$ID&client_secret=$SECRET&scope=claims.manage"

# 2) выдать пользователю claim
curl -X POST https://id.local/api/v1/users/user@mail/claims?by=email \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"type":"plan","value":"pro"}'