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

Question

В настоящее время я работаю над приложением, состоящим из веб-приложения и клиентского программного обеспечения.Клиент связывается через веб-сервисы, поддерживая реализацию SOAP и Protobuffer.

Первоначальная регистрация выполняется через веб-приложение, которое позже использует аутентификацию по имени и паролю.

После завершения процесса регистрациивсе функции также доступны через клиента, который будет взаимодействовать только через HTTPS.Для проверки подлинности вызовов веб-службы в настоящее время я думаю о трех возможных подходах:

1. Включение имени пользователя и пароля в каждое сообщение.Но действительно ли целесообразно включать учетные данные в каждый запрос, даже если он защищен HTTPS?

2. Предоставление имени пользователя и пароля в первом запросе веб-службы.Затем клиент получает токен, который используется для всех будущих запросов.(Примечание. Считается неприемлемым принуждать пользователя копировать сгенерированный сервером токен в клиентское приложение.) Только если пользователь аннулирует токен, ему необходимо повторно отправить свое имя пользователя и пароль для получения нового токена.Такие подходы на основе токенов кажутся довольно распространенными, например, Google, AWS и Rackspace часто их используют.Но действительно ли это оправдывает себя в этом сценарии?

3. Хеширование пароля на клиенте звучит как хорошее решение.Однако я бы хотел посолить зашифрованные пароли на стороне сервера.Добавление запросов только для получения солей не звучит как оптимальное решение или нет?

Есть ли лучшие практики или советы?Я не мог найти слишком много информации именно для этих требований.В настоящее время я бы остановился на 2), но я еще не совсем уверен.

Проект основан на Java, Apache CXF, Protobuffers и Shiro, но не должен оказывать слишком сильного влияния наобщий вопрос ...

Answer 1

Если вас интересует только аутентификация, а не конфиденциальность и целостность, вы можете справиться с ней, обеспечив:

• уровень транспорта HTTP, используя HTTP BasicAuth (пользователь + пароль для каждого сообщения) +в конечном итоге HTTPS для конфиденциальности, однако, как вы заметили (решение 1), это своего рода старая школа, и сохранение имени пользователя / пароля в локальном кэше не представляет особой проблемы, но не рекомендуется.
• Уровень сообщения (мыльное сообщение)) используя токен безопасности, например, но я не знаю, Protobuffer
• Уровень приложения (решения 2 и 3), так работают Google, Amazon, Ebay и другие.Вы не будете просить пользователя скопировать / вставить свой токен, вы сгенерируете его из имени пользователя / пароля

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

Лучше, ноболее сложным решением было бы использование SSL-сертификатов, доступных как в браузере, так и в клиентском программном обеспечении.