HTTP-аутентификация и файлы cookie

Question

Кажется, что аутентификация на основе файлов cookie сегодня является очевидным выбором для веб-служб, которым требуются учетные данные для входа.

Но что если вы разрабатываете веб-сервис, в котором клиенты являются не браузерами, а клиентским программным обеспечением (например, мобильным приложением), которое обращается к ресурсам через HTTP, вы бы использовали HTTP-аутентификацию или cookie-аутентификацию?

HTTP-аутентификация:

• Веб-сервер обрабатывает аутентификацию, поэтому при необходимости проще изменить платформу веб-приложения
• Автоматически применяется к некодовым ресурсам (например, JPG, XML и т. Д.) (Сторона Q: Есть ли способ сделать это с помощью аутентификации на основе файлов cookie?)
• Труднее интегрировать сохраненные в базе данных учетные данные с аутентификацией сервера (.htaccess / .htpasswd)

Cookie Auth:

• Мелкозернистые элементы управления доступом (ресурс кода может реагировать по-разному в зависимости от учетных данных)
• Контроль истечения сеанса (через истечение срока действия куки)
• Полный контроль над входом пользователя в систему

Какие еще соображения я оставляю вне дома? Любые другие плюсы / минусы?

Некоторые полезные обсуждения здесь

Answer 1

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

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

Answer 2

Базовая аутентификация HTTP - это кошмар, когда пароль взломан, так как невозможно изменить его, не изменив сначала все легитимные клиенты. Вы также не можете принудительно деаутентифицировать отдельного пользователя, а механизм передачи учетных данных аутентификации небезопасен (если вы не заключите его в https)

Действительно, ваш лучший вариант - использовать систему на основе файлов cookie, позволяющую детально контролировать отдельные сеансы с проверкой подлинности

Answer 3

Что ж, когда клиент является мобильным приложением или чем-то, что отличается от обычного браузера, серверное приложение все еще нуждается в некотором отслеживании сеансов. Самый простой способ выполнить отслеживание сеанса - это использовать некие «куки», либо стандартные HTTP-куки, либо пользовательские идентификаторы сеанса. Таким образом, идентификатор сеанса фактически является «cookie», даже если стандартный механизм cookie не используется. Я всегда назначаю идентификаторы сеансов для клиентских сеансов, поэтому я склонен голосовать за авторизацию cookie.