#oauth-2.0 #identityserver4
#oauth-2.0 #identityserver4
Вопрос:
Я разрабатываю приложение без браузера, которому необходим доступ к двум API-интерфейсам — API приложения (только для чтения, например, удаленная настройка) и пользовательский API (чтение-запись, например, пользовательские настройки).
Приложение хранит идентификатор клиента и секрет локально и, следовательно, использует поток учетных данных клиента для доступа к API приложения. Теперь мне нужно, чтобы пользователи могли получать доступ к пользовательскому API, и мне интересно, как настроить серверную часть (которая в данном случае использует IdentityServer4) для этого. API должен быть защищен, чтобы к нему могли получить доступ только аутентифицированные пользователи, и я планирую прочитать заявки, отправленные для идентификации пользователя.
Должен ли я расширить существующий идентификатор клиента, чтобы также разрешить тип предоставления потока устройств или создать отдельный клиент только для этого потока «только для пользователя»?
Я новичок в OAuth и хочу убедиться, что я делаю это правильно, чтобы все было в безопасности.
Ответ №1:
Всегда используйте разные клиенты OAuth для разных подключений на стороне клиента, что даст вам больше контроля:
- Такие правила, как время жизни токена доступа, могут быть установлены по-разному, когда это необходимо
- Скомпрометированный клиент (например, украденный секрет) может быть отключен без ущерба для других клиентов
- Показатели и ведение журнала также будут более полезными
Обычно легко настроить несколько клиентов на сервере авторизации через пользовательский интерфейс управления.
Комментарии:
1. Имеет смысл, спасибо. Я должен признать, что наличие 1 приложения заставило меня усомниться в необходимости большего количества «клиентов», когда это по сути одно и то же, просто разные варианты использования.
2. Другим вариантом может быть один клиент с разными областями, хотя лично я бы разделил их. Похоже, вам нужно написать код для 2 потоков и использовать 2 типа токенов, какой бы вариант вы ни выбрали. Если возможно, я бы стремился сделать так, чтобы удаленная загрузка конфигурации содержала только общедоступную информацию, чтобы она не нуждалась в защите, чтобы вам нужна была только опция потока устройства.
3. В качестве примера мой веб-интерфейс загружает эти данные конфигурации , и меня бы не беспокоило, если бы хакер получил их.
4. Согласовано. Удаленная конфигурация была просто примером, в моем случае приложению потребуется прочитать больше, чем это, но именно из-за аспекта безопасности я сохраняю вещи только для чтения и не буду иметь конфиденциальных данных на этих конечных точках. Если что-то случится с ключами, по крайней мере, злоумышленник не сможет ничего уничтожить, пока они не будут повернуты …!