Вопрос, собственно, следующий - в процессе получения сведений по организациям пользователя (запрос GET /rs/prns/{oid}/roles), требуется указать этот самый OID пользователя.
В реализации авторизации пользователя через ЕСИА и получения данных из Цифрового профиля гражданина моих коллег, они используют в качестве OID пользователя значение атрибута urn:esia:sbj_id из полученного ранее маркера доступа. В методичке к использованию ЕСИА данный атрибут тоже описывается как уникальный идентификатор субъекта [так понимаю, что доступа]. И видимо у них это работает.
Однако, в нашем случае нам придется использовать именно рест ЕСИА, т.к. в схеме с реестром платформы согласий, используемой при запросах к ЦПГ, банально нет соответствующей области доступа (usr_org). И при попытках выяснить корректный алгоритм формирования запросов с помощью Дипсика, я получил утверждение, что использовать значение urn:esia:sbj_id в качестве OID - некорректно, т.к. это "идентификатор контекста сессии" (правда я пока так и не нашел прямое подтверждение данной трактовки, но робот прям настаивает). А идентификатор пользователя - это значение атрибута urn:esia:sbj:oid из состава маркера идентификации (который в методичке описан как OID учетной записи пользователя).
Соответственно, вопрос - какое же из этих двух значений корректно использовать в запросе GET /rs/prns/{oid}/roles?
Это классическая путаница между маркером доступа (Access Token) и маркером идентификации (ID Token), которые являются основой протокола OpenID Connect, используемого в ЕСИА.
"urn:esia:sbj:oid (из ID Token)" - это постоянный и уникальный OID пользователя. Он предназначен для идентификации. А "urn:esia:sbj_id (из Access Token)" - это временный идентификатор сессии. Полагаться на него некорректно, даже если где-то это случайно работает. Ваш алгоритм должен быть таким:
В процессе авторизации запросить и получить от ЕСИА и access_token, и id_token.
Распарсить id_token (это стандартный JWT).
Извлечь из него значение поля urn:esia:sbj:oid. Это и будет искомый {oid}.
Сформировать URL запроса, подставив туда полученный oid.
Выполнить GET запрос по этому URL, передав access_token в заголовке Authorization: Bearer ... для авторизации на сервере.
Простой
Средний
Простой
Простой
