Я думаю, что по практическим соображениям (в основном для просмотра) вам необходимо различать состояние приложения и состояние аутентификации . Я не могу вспомнить ни один механизм аутентификации, который не сохраняет какую-либо форму состояния на стороне сервера.
Что действительно важно, так это то, насколько он отделен от приложения. Например, HTTP Digest сохраняет некоторую форму состояния на сервере, но это явно абстрагируется как часть обычного согласования заголовка WWW-Authenticate и Authorization. Поскольку большинство браузеров поддерживают его изначально, это ортогонально приложению и, как таковое, не нарушает принцип безгражданства REST.
В настоящее время, поскольку у пользователей есть некоторые эстетические ожидания, что базовая / дайджест-проверка подлинности HTTP не встречается в браузерах, веб-сайты, как правило, используют проверку подлинности на основе форм и впоследствии файлы cookie. Чтобы быть справедливым, это больше, чем просто внешний вид, это также вопрос удобства использования (например, информация «забыли свой пароль», хотя это может быть частью ответа 401) и безопасности. Браузеры не позволяют вам легко выйти из базовой / дайджест-аутентификации / проверки подлинности сертификатов, если только это не сделано полностью в Ajax на одной странице, как вы упомянули, и это может помочь CSRF.
Я думаю, что файлы cookie приемлемы для аутентификации, но убедитесь, что вы не храните переменные, связанные с приложением, в сеансе.
Вы можете прочитать некоторые комментарии Роя Филдинга на тему :
Аутентификация является ортогональной. Печенье
также ортогональны, когда они
просто используется для согласования контента или
аутентификация. Тем не менее, Cookie
аутентификация не разрешена в REST
потому что ему не хватает видимости, что
вызывает проблемы с безопасностью, потому что
другие компоненты не знают, что это
конфиденциальная информация.
РЕДАКТИРОВАТЬ (дополнительные комментарии по вопросам безопасности):
Я понимаю, что комментарии Роя Филдинга в цитируемом мною сообщении направлены против файлов cookie по соображениям безопасности. Он, конечно, прав. Однако, по моему мнению, защищать от CSRF с помощью Basic / Digest / Cert (который на самом деле не был в радаре в 2003 году, дата того сообщения) труднее, чем от кражи cookie. Это зависит от реализации, конечно. Идеального решения не существует, но если вы используете куки-файлы, используйте безопасные куки-файлы через HTTPS.