«Общая» аутентификация для веб-сайта и RESTful API

Question

Цель: Мой сервер должен направлять не-пользователей на посадку/домашнюю страницу и регистрироваться в реальном приложении. Когда приложение будет загружено, оно сделает аутентифицированным HTTP-запросы к API RESTful (через Ajax).

У меня есть API RESTful, который нуждается в аутентификации. На другом сервере у меня есть свой веб-сайт, для которого также требуется аутентификация, поэтому я могу определить, отображать ли вы посадку/домашнюю страницу для не-пользователей или приложение для зарегистрированных пользователей.

Первоначально я думал, что этого достаточно, чтобы реализовать HTTP Basic Auth для RESTful API. Однако, чтобы получить аутентификацию для моего веб-сайта, мне также необходимо настроить аутентификацию, что означало бы дублирование низкоуровневого кода для проверки учетных данных в базе данных как в REST API, так и на серверах веб-сайта.

В качестве альтернативы, я задавался вопросом, может ли веб-сайт аутентифицироваться через API RESTful. Например, в моем обработчике запросов для POST /login я мог бы сделать запрос GET к моему API, передав учетные данные пользователя из тела запроса. Если запрос возвращает 200 OK, я могу подписать сеанс пользователя, тем самым подтвердив его. Оттуда и далее, запросы Ajax к REST API должны быть заверены с теми же учетными данными, так что я мог:

• установить кук, содержащих учетные данные, таким образом, позволяя JavaScript, чтобы получить учетные данные, прежде чем делать запрос (OK с SSL?)
• dump учетные данные в обслуживаемом HTML для веб-приложения, позволяя JavaScript получить учетные данные перед выполнением запроса (ОК с SSL?)
• прокси API через сервер веб-приложений, где Я могу получить учетные данные из сеанса и добавить их в заголовок Authorization прокси-запроса?

В качестве альтернативы, я полагаю, я мог бы просто поделиться сеансом между двумя серверами, хотя я слышал, что это плохая практика для дизайна RESTful.

Что было бы не так с этим? Есть ли лучший способ выполнить мою задачу?

Answer 1

Я думаю, что ваш подход с использованием базовой HTTP-аутентификации в службе REST и проверка подлинности вашего приложения с помощью сервиса отлично. Единственное предостережение (которое, я уверен, вы знаете), заключается в том, что ваша служба REST должна работать через SSL, поскольку базовая HTTP-аутентификация не очень безопасна - имя пользователя и пароль просто закодированы в Base64.

Answer 2

Недавно я реализовал нечто похожее на это (предполагая, что я вас правильно понимаю), и, казалось, было несколько жизнеспособных вариантов.

• Есть на стороне сервера вашего веб-приложения всегда аутентификации с определенным именем пользователя/пароля при доступе к REST API, гарантируя, что ваш веб-приложение всегда доверяли и предполагая, что пользователи должным образом вошли в систему на web- приложение, если запрос аутентифицирован как приложение.
  • Плюсы: Простая в применении, понятная и простая в использовании для других приложений (у нас была CLI, которая также обращалась к тому же REST API).
  • Недостатки: API REST не может знать, какой пользователь фактически обращается к нему. Если доверенный клиент взломан, вся система скомпрометирована.
• Имеет ли серверная часть вашего веб-приложения информацию о пользователе в сеансе и аутентифицируется с использованием учетных данных пользователей при каждом доступе к API REST.
  • Плюсы: Довольно легко реализовать (хотя некоторые механизмы аутентификации затрудняют сохранение пароля пользователя - по уважительной причине). Вся процедура прозрачна для API REST.
  • Недостатки: теперь вы сохраняете (для всех целей и целей в текстовом виде) имя пользователя и пароль пользователя в сеансе веб-сервера - одну из самых главных целей для атаки в системе.
• Создайте систему аутентификации в REST API, которая аутентифицирует запрос с авторизацией имени пользователя и пароля и возвращает токен, действительный в течение ограниченного времени.
  • Плюсы: более безопасно, если ваше веб-приложение скомпрометировано, вы не предоставляете злоумышленнику имя пользователя/пароли пользователей, но вместо этого разрешаете им ограниченный доступ времени.
  • Против: Намного сложнее реализовать. Возможно, вам придется иметь дело с тайм-аутами токенов. Для пуристов это также означает, что ваша реализация REST (или, по крайней мере, система аутентификации) будет, возможно, «stateful».

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