#oauth-2.0
#oauth-2.0
Вопрос:
Я внедрил проверку подлинности OAuth 2.0 между серверами для веб-приложения, которое я разрабатываю.
Обе службы являются внутренними для моей компании, поэтому я отправляю запрос с сервера A на сервер B, содержащий имя пользователя, пароль, client_id и client_secret, после чего в ответ получаю access_token.
После этого я могу отправить второй запрос от A к B, содержащий access_token в заголовке, для извлечения некоторых данных.
Данные, полученные с сервера B на сервер A, в конечном итоге передаются в представление на сервере A и показываются конечному пользователю. Поэтому я никогда не запрашиваю какие-либо входные данные у конечного пользователя, потому что я использую вышеупомянутую «учетную запись службы» для извлечения необходимых мне данных. Конечные пользователи даже ничего не знают о таком соединении в фоновом режиме.
Сказав это, я сейчас схожу с ума, объясняя своим коллегам, что это безопасный подход. Мне было интересно, есть ли у кого-нибудь какая-либо официальная документация или рекомендации, которыми можно поделиться со мной, которые могут помочь обосновать ИТ-вертикали правильность такого подхода. Мне сказали, что базовый метод аутентификации запрещен в компании, но на самом деле это не базовая аутентификация, не так ли ?! Я даже не могу найти правильное имя для этого, кто-то называет этот метод потоком предоставления пароля, кто-то еще — двуногим OAuth. Дело в том, что в моем случае все взаимодействие происходит сервер-сервер без каких-либо входных данных, необходимых от конечных пользователей.
Любая помощь очень ценится!
Ответ №1:
ПРЕДОСТАВЛЕНИЕ ПАРОЛЯ ВЛАДЕЛЬЦА РЕСУРСА
Вы используете этот поток между сервером A и сервером B, что не рекомендуется, поскольку приложения OAuth не должны иметь доступа к паролю конечного пользователя. Более стандартным является использование потока учетных данных клиента для вызовов от сервера к серверу.
ЭМИТЕНТ ТОКЕНА OAUTH
Другим нестандартным аспектом является то, что сервер B не должен выдавать свои собственные токены. Более стандартным является использование готового сервера авторизации (AS) для обработки сообщений OAuth и выдачи токенов. AS — единственная сторона, которая видит учетные данные — ваши пользовательские интерфейсы и API используют только токены, срок действия которых короткий по сравнению с учетными данными.