В настоящее время я нахожусь на ранних этапах создания веб-приложения (HTML5, JS и т. д.), которое использует REST API на серверной части (Java, в частности, Jersey v1.18). Характер данных, которые будут храниться, очень важен, поэтому безопасность — это то, на что я начал обращать внимание, хотя приложение находится только на ранних стадиях. Конечная цель будет состоять в том, чтобы также иметь собственные мобильные приложения и потенциально предоставлять доступ к данным для внешних клиентов через тот же API.
В своем исследовании я выявил множество методов аутентификации, в том числе HTTP Basic, на основе токенов, файлы cookie сеанса, OAuth, HMAC и т. д. Ключевым компонентом здесь является то, что REST API будет в первую очередь использоваться пользователями, а не другие приложения или серверные части. Таким образом, наличие эквивалента «вход/выход» важно, и это сводится к аутентификации на уровне пользователя.
На данный момент аутентификация 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 кажется подходящим вариантом, но я еще не видел рекомендуемого подхода к работе с общим секретом. Идея использования ресурса для проверки учетных данных, который затем предоставляет токен/одноразовый номер для использования со схемой HMAC, кажется вариантом, но я сомневаюсь в преимуществах по сравнению с использованием этого токена/одноразового номера исключительно в качестве токена.
Я знаю, что аутентификация HMAC для REST API подробно обсуждалась, но при использовании в сочетании с деталями аутентификации, которые ожидают пользователи (имя пользователя, адрес электронной почты, пароль и т. д.), существует ли какой-либо рекомендуемый подход, который не требуется предварительно общий секретный ключ?
