Аутентификация на основе утверждений и круги пользователей

Question

Давайте подумаем о простой веб-службе на основе REST для хранения и извлечения объектов JSON. Без какой-либо аутентификации каждый пользователь может получить доступ к любым данным.

Теперь давайте добавим использование JWT для аутентификации пользователей. Конечно, поскольку мы не выполняем авторизацию, все же каждый пользователь может получить доступ к чему-либо, но, по крайней мере, теперь мы знаем, кто обращается к чему.

Следующий шаг: при сохранении объекта сохраните заявку пользователя sub с этим объектом и убедитесь, что запрос пользователя sub соответствует одному из запрошенных объектов, и если да, поставьте его. Теперь у нас есть авторизация для каждого пользователя. Пока что так просто.

Теперь давайте добавим возможность пользователям обмениваться объектами с другими пользователями. Для простоты, скажем, мы хотим иметь предопределенные группы (т. Е. Роли), и мы хотим разрешить пользователю выбирать, какая группа (роль) имеет доступ к создаваемым им объектам. Это все еще легко, так как у вас есть предопределенный список групп, поэтому вы можете позволить пользователю выбрать один или несколько и прикрепить их к объекту. Кроме того, поставщик идентификации должен быть настроен таким образом, чтобы он вносил в токены каждого пользователя знак groups, поэтому мы можем их сопоставить. Как мы уже можем видеть из этого абзаца, все становится более сложным.

Вопрос 1: До сих пор я прав, что обработка «статических» групп таким образом - путь?

Теперь давайте пользователям возможность создавать группы самостоятельно. Это все еще не сложно, но как заставить поставщика удостоверений использовать динамически созданные группы? Конечно, мы не хотим, чтобы администратор обновлял конфигурацию поставщика удостоверений каждый день ;-).

Вопрос 2: Как мы обрабатываем динамически созданные группы?

Теперь, наконец, давайте забудем о группах и предположим, что мы хотим, чтобы пользователи могли просто делиться своими объектами с другими пользователями. Это должно настраиваться для каждого объекта отдельно. как нам это сделать? Сохраняем ли мы список пользователей на объекте? Если да, то что именно мы сохраняем? Требование sub? Если да, то как пользователь владельца знает соответствующие значения? Или ...?

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

Вопрос 3: Как токены и динамически создаваемые группы с динамически назначенными пользователями работают друг с другом?

Answer 1

На мой взгляд, маркеры должны включать только идентификационные данные (-задания), вам нужно будет идентифицировать пользователя на вашем сервере ressource или это не изменится при обновлении, так как вы не хотите, чтобы ваш пользователь (или ваше приложение на месте), чтобы обновлять свои токены доступа каждый раз, когда его разрешения изменяются (поскольку токены доступа предоставляют доступ в течение определенного времени, вы не хотите, чтобы ваш пользователь имел доступ к определенным ресурсам, что он потерял права доступа с тех пор его последний токен обновляется, не обновляя токен и просто используя старый). Чем больше информации, связанной с безопасностью, вы добавляете к вашему токену, тем больше уязвимостей вы можете добавить в свою систему (в зависимости от срока действия вашего токена).

Сказав это, я бы (и всегда) идентифицировал роли или группы пользователей своим идентификатором пользователя (который включен в jwt-токен) на сервере ressource. Чтобы достичь этого, я всегда прикрепляю идентификационную информацию пользователя к текущему запросу на моем сервере ressource и прикрепляю к ним «динамические» -классы, такие как роль или группа пользователей.

Добавляя только идентификационную информацию, мне необходимо идентифицировать пользователя и права пользователя на моем сервере ressource, я, как правило, использую свои поставщики удостоверений в нескольких приложениях, не обрабатывая область приложения в поставщике удостоверений, поэтому я могу использовать точные тот же токен доступа для нескольких независимых серверов ressource.