вы путаете понятия
вы предоставляете не права на чтение приложению
а пользователь предоставляет права на чтение его данных какому-то приложению

это и есть задача oauth2

А как тогда управлять данным абаком? Если на каждом сервисе свой абак, то получается что менеджерить его будет сложно. В понятие абак, я вкладываю структуру выходного токена с рядом информации о данном пользователе. Сами сервисы же держат в себе ворты, которые проверяют полномочия придаставленные токеном

я не знаю какая у вас там архитектура приложения, но как одна из идей
токен oauth2 приходит на один из сервисов, по нему запросите в центральном сервисе авторизации абак

либо же зашейте в сам токен уже список абак для конкретного scope

либо же используйте паттерны для микросервисной архитектуры чтобы кешировать права пользователя по токену

Да, я какраз и хочу их разграничить,  потому что не очень понимаю. Если ограничение прав к клиентскому ПО осуществляется в разрезе прав пользователя, то получается какой то жирнющий токен, потому что таких прав может быть очень и очень много. + они не отвечают на вопрос кому все таки, и что можно. Приведу пример read:orders
Может значить дай вообще все ордеры, если я евляюсь админом системы.
Если я менеджер подразделения, то дай мне все ордеры этого подразделения.
А если я штатный человечек который просто купил что то, то вообще дай мне только мои заказы

ну так и будет, потому что каждый ваш админ менеджер и человек выдаст отдельные oauth2 токены

по нему приложение обратиться на сервис заказов
тут увидит токен
спросит у сервиса авторизации - а что можно вот такому вот токену
ему скажут - ему можно crud заказов пользователя с ид 1

Спросит у сервиса авторизации. По каждому запросу... А если информация нужна с 2 сервисов и более то получается что за 1 реквест к сервису авторизации сходят N раз, что бы получить информацию о доступности запрашиваемых данных. 2 момент получается что при каждом добавление каких либо ресурсов, надо обновить информацию в сервисе авторизации. Я вас верно понимаю? Мне кажется это очень дорогая и затратная операция

а вы думали микросервисы это вам раз и сделал ?
применяйте паттерны для построения микросервисной архитектуры, там достаточно механизмов для снижения нагрузки

есть и другие механизмы, типа использования того же JWT

и да, валидатор токенов у вас будет нагружен по самое немогу, на пхп его лучше не писать

Я расскажу как я себе это вижу, но не притендую на правильность... Тема очень крупная, и сложная, во всяком случае мне так кажется.
У нас есть абак на уровне аутентификационного сервиса. После того как человек прошёл аутентификацию абак запихнет в токен нужную информацию о человеке. "в каком городе работает, какая должность, кем мы его считаем в разрезе системы", и так далие... Дальше этот токен будет попадать на конкретные сервисы, и исходя из этих утверждений будет принимается решение, о предоставление доступа к ресурсу

вы сейчас описали jwt

Jwt это тип токена что там будет запихвно, и по средствам каких протоколов это вопрос уже другой

я не знаю можно ли jwt присобачить к oauth2

Да я думаю о связке oauth oidc  jwt

разве что взять oauth2 стандарт, потом этот токен менять на jwt а потом jwt уже слать на сервисы, это снизит нагрузку на oauth2

Дим, а есть ли какие то паттерны на эту историю?