Разрешение / авторизация OpenId Connect в потоке заявок

Мы внедряем IdentityServer4 с MS.Identity для единого входа, аутентификации и авторизации, используя неявный поток для нескольких наших SPA и WebAPI (все они принадлежат нам).

В неявном потоке Id_Token - это то место, где мы размещаем дополнительные «заявки». Укажите здесь.

Access_token не содержит настраиваемых утверждений разрешений в соответствии с этим.

Неявная спецификация потока здесь.

Вопрос: Каков процесс предоставления и удаления разрешений?

  • Как клиент узнает об изменении разрешений / требований без опроса конечной точки информации о пользователе?
  • Откуда сервер ресурсов знает?

Отзыв Id_token не предусмотрен. Похоже, что полезность утверждений в токенах, зная, что разрешения больше не применимы, с моим пониманием OpenID Conenct.

Мне не хватает очевидного встроенного в спецификацию решения, или мы реализуем какую-то перевыпуск Id_Token при изменении разрешений?

Спасибо..


jwt oauth openid-connect identityserver4 openid
person ttugates    schedule 27.02.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Токены не содержат разрешений. Они содержат идентификационные данные о клиенте и пользователе.

https://leastprivilege.com/2016/12/16/identity-vs-permissions/

person leastprivilege    schedule 27.02.2017
comment
Спасибо за ответ. Я прочитал эту статью и поделился ею со своим коллегой пару недель назад, когда мы решили реализовать токены обновления, что в конечном итоге привело к переписыванию всей нашей аутентификации / авторизации. В конечном итоге статья заканчивается словами «Оставайтесь с нами». Есть ли где-нибудь существующее решение или шаблон, связанный с OpenId Connect? - person ttugates; 27.02.2017
comment
Чтобы решить проблему размера полезной нагрузки, мы кодируем Enums как Shorts до 2 Bytes ea, а затем кодируем Base64URL. - person ttugates; 27.02.2017

arrow_upward
0
arrow_downward

В свете ответа Доминика.

Я собираюсь реализовать сервер разрешений / авторизации и конечную точку.

Клиенты SPA и WebAPI могут вызывать его для получения разрешений с проверкой подлинности. Теперь мы можем вернуть любой настраиваемый объект разрешения, который нам нужен.

В access_token мы добавим настраиваемый «ETAG разрешений», чтобы при изменении разрешений пользователя каждый клиент знал, что нужно получить новые разрешения.

Конструктивная критика приветствуется.

person ttugates    schedule 28.02.2017