Запутался в том, какой тип потока OAuth2 реализовать для связи нашего веб-приложения с веб-приложением.

У нас есть небольшой устаревший веб-сайт .NET MVC, для которого мы пытаемся внедрить OAuth2. Вот как это работает в настоящее время: На веб-сайте нет учетных записей пользователей. Таким образом, вход в систему не требуется — аутентификация не выполняется. Вместо этого запросы GET отправляются методу контроллера. Эти запросы GET состоят из зашифрованных параметров, которые принимаются, расшифровываются, а затем отображается веб-страница. «Клиент» (wep-приложение), который отправляет эти запросы GET, имеет уникальный ключ шифрования и IV, которые мы им предоставили. Конечно, мы доверяем им держать эту информацию в «секрете». Если в этом сценарии есть фактический владелец ресурса, кажется, что это будет фактическое «клиентское приложение», от которого исходит запрос.

Увы, пришло время сделать этот процесс немного более безопасным. Существует много статей о потоках OAuth2, и кажется, что поток учетных данных клиента подходит для этого варианта использования, но обычно информация об этом потоке предполагает, что «клиентское приложение» является «доверенным», а значение «доверия» заключается в том, что мы на самом деле также владеет «клиентским приложением». Ну, у нас нет клиентского приложения, что заставляет меня задаться вопросом, действительно ли это правильный поток для этого варианта использования. Кажется, что любой другой поток OAuth2 лучше всего подходит для доступа к ресурсам владельца ресурса, который, как правило, является пользователем с именем пользователя и паролем. У нас нет фактических учетных записей пользователей для аутентификации имен пользователей и паролей, что возвращает меня обратно к потоку учетных данных клиента.

Кроме того, нам не удалось найти какие-либо примеры, похожие на наш конкретный вариант использования, который в основном представляет собой взаимодействие веб-приложений с веб-приложениями, когда клиентское веб-приложение не принадлежит нам. После прочтения этой статьи: Использование собственного API для веб-приложения - Процесс аутентификации с OAuth2, где поток учетных данных клиента не рекомендуется, нам интересно, какой поток будет рекомендован.

Как вы думаете, какой поток OAuth2 подойдет для описанного выше случая использования лучше всего?


person codenewbie    schedule 28.07.2017    source источник


Ответы (1)


приложение к приложению довольно просто. Я отсылаю вас к более старой статье, которую я написал на эту тему некоторое время назад: https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-веб-токены/. Статья довольно длинная и много говорит, поэтому я просто не вставлю сюда кое-что.

Все, что вам действительно нужно, это защитить свой сервер ресурсов, и вы можете выдать каждому клиентскому приложению свой уникальный ClientID / CLientSecret, и это то, что они будут использовать для аутентификации.

Разумеется, ваши клиенты будут нести ответственность за сохранение конфиденциальности своих ClientID и Secret.

person Andrei Dragotoniu    schedule 28.07.2017
comment
Спасибо за ответ, и извините, что я так долго не мог ответить. В своей статье вы описываете использование .NET Membership и Authorize Attribute для аутентификации пользователей. Я использовал этот метод в других проектах, но в настоящее время он не существует в этом проекте. Это не похоже - person codenewbie; 01.08.2017
comment
Хорошо, так что не нажимайте Enter, когда пытаетесь оставить комментарий. Вот что я имел в виду: Спасибо за ответ, и извините, что мне потребовалось так много времени, чтобы ответить. Действительно, это очень похоже на то, что я прошу. Я обязательно посмотрю поближе. Как защищен первоначальный запрос токена аутентификации? Может ли кто-нибудь перехватить запрос, содержащий client_id/client_secret, а затем отправить его на нашу конечную точку аутентификации и получить от нас токен аутентификации? - person codenewbie; 01.08.2017
comment
пока запрос выполняется через HTTPS, вы в безопасности. CLientID и секрет передаются в заголовке, поэтому они будут в безопасности. - person Andrei Dragotoniu; 06.09.2017