Аутентификация веб-приложения для REST API Backend

Question

Аутентификация веб-приложения для REST API Backend

1

В настоящее время я нахожусь на ранней стадии создания веб-приложения (HTML5, JS и т.д.), Которое использует REST API на бэкэнд (Java, в частности, Джерси v1.18). Характер данных, которые будут храниться, очень чувствителен, поэтому безопасность - это то, на что я начал смотреть, даже несмотря на то, что приложение находится только на ранних стадиях. Конечной целью будет также создание собственных мобильных приложений и потенциальный доступ к данным для внешних клиентов через один и тот же API.

В моих исследованиях до сих пор я определил множество методов аутентификации, включая HTTP Basic, маркер на основе токенов, cookie сеанса, OAuth, HMAC и т.д. Ключевым компонентом здесь является то, что API REST будет в первую очередь доступен пользователям, а не других приложений или бэкендов. Таким образом, важно иметь эквивалент "входа/выхода", и это сводится к аутентификации на уровне пользователя.

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

Я уже прочитал десятки сообщений SO, а также такие статьи, как: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ http://www.errant.me.uk/blog/2013/04/authenticating-restful-web-applications/ (примечание: это явно плохо, поскольку солить с именем пользователя не рекомендуется)

В идеале, HMAC, похоже, подходит, но мне еще предстоит увидеть рекомендуемый подход к работе с общим секретом. Идея использования ресурса для проверки учетных данных, которая затем предоставляет токен /nonce, который будет использоваться с помощью схемы HMAC, представляется вариантом, но Im сомневается в преимуществах только при использовании этого токена /nonce строго в качестве токена.

Я знаю, что проверка подлинности HMAC для REST API обсуждалась подробно, но при использовании в сочетании с данными аутентификации, которые пользователи ожидают (имя пользователя, адрес электронной почты, пароль и т.д.), Существует ли какой-либо рекомендуемый подход, который не требует предварительно открытый секретный ключ?

Matt Joseph 18 март 2014, в 03:47

Источник

Теги:

java

hmac

security

rest

jersey

1 ответ

Ещё вопросы

Tom G · Answer 1 · 2014-03-18T00-21-00.000Z

Это прежде всего вопрос, основанный на мнениях, но я предлагаю свои два цента: просто заходите в cookie сеанса.

Если ваша основная аудитория - это люди, и вам не нужно интегрироваться с третьими лицами, не беспокойтесь о OAuth. Просто убедитесь, что ваш API доступен только через HTTPS и выдает токен сеанса, который сервер может отменить после входа в систему. Строго говоря, это не обязательно быть печеньем; Я видел API, которые фиксируют токен в хранилище сеансов HTML5 и предоставляют его в заголовке авторизации или в качестве параметра запроса.

Если вы правильно настроили SSL, ваши пользователи получат ожидаемый замок в браузере, и вы будете в безопасности от всех, кто находится между вами и клиентом. Если клиент взломан, вы все равно ввернуты. И поскольку клиент не может хранить тайну, нет никаких преимуществ для более сложных схем HMAC.

Есть ли какие-либо рамки, которые вы бы порекомендовали, которые хорошо работают с Джерси? Я смотрел на Apache Shiro, Spring Security, Apache Oltu и на использование HTTP Basic auth как части Джерси.
Для чего-то такого простого я бы использовал базовый фильтр сервлетов или аналогичный. Просто отправьте запросы на аутентифицированные конечные точки в фильтр и отклоните их с 401, если токена нет. Очевидно, что если у вас есть логика авторизации для конкретного домена, вам все равно придется обрабатывать ее отдельно для каждого ресурса.