Appearance
Scopes — какие есть и когда использовать
Scope определяет, какие данные о пользователе попадут в токен и в ответ /userinfo, а для Client Credentials — какие права запрашивает сервис. Запрашивайте минимально необходимый набор: чем шире scope, тем больше данных получает ваше приложение и тем заметнее это на экране согласия пользователя.
Пользовательские потоки (Web, CLI)
| Scope | Что даёт | Когда запрашивать |
|---|---|---|
openid | Claim sub (идентификатор пользователя), сам id_token | Всегда — обязателен для Authorization Code и Device Flow |
profile | name, picture | Если показываете имя/аватар пользователя в интерфейсе |
email | email, email_verified | Если используете email как идентификатор или для уведомлений |
offline_access | Выдаёт refresh_token | Если приложению нужен долгоживущий доступ без повторного входа — фоновые задачи, мобильные клиенты, CLI |
roles | roles[], groups[] в токене и /userinfo | Если приложению нужно знать роли/группы пользователя внутри SSO для собственной логики доступа (см. 02-client.md) |
Типичный набор для веб-приложения: openid profile email offline_access. Типичный набор для CLI: openid profile email offline_access — offline_access здесь особенно важен, иначе пользователю придётся логиниться заново при каждом истечении access token.
Без offline_access refresh_token не выдаётся вообще, даже если остальная логика Authorization Code Flow отработала штатно.
Client Credentials (M2M)
Для сервисных клиентов (см. 05-service-to-service.md) openid, profile, email не имеют смысла — токен не привязан к пользователю, id_token не выдаётся в принципе. Здесь используются собственные scope вашего API, определяющие уровень доступа сервиса:
| Scope | Что даёт |
|---|---|
read:data | Чтение данных |
write:data | Запись данных |
delete:data | Удаление данных |
Это не фиксированный список — фактический набор доступных M2M-scope определяется тем, что разрешено в allowedScopes вашего клиента (см. 02-client.md). Заведите отдельные scope под свою предметную область по той же схеме действие:ресурс, если встроенных read/write/delete:data недостаточно, и укажите их в allowedScopes при регистрации или редактировании клиента.
Ограничение scope на уровне клиента
Даже если ваше приложение запросит более широкий scope, чем разрешено, сервер выдаст токен только с пересечением запрошенного и allowedScopes клиента. Планируя интеграцию, держите allowedScopes синхронизированным с тем, что реально использует приложение — не оставляйте его пустым (что равносильно «разрешены все scope») без осознанного решения.
Если после фильтрации по allowedScopes не остаётся обязательного openid — сервер вернёт ошибку invalid_scope (см. 06-operations.md).