Короткий ответ: в концепции этого подхода нет серьезных проблем с безопасностью, но реализация является ключевой, и это, вероятно, мой самый важный момент.
Проблема пользовательской реализации
То, что вы описали, в основном является простым старым сеансом. «Токен» здесь - просто идентификатор сеанса. Веб-приложения работали таким образом целую вечность. Известны высококачественные реализации, которые избегают фиксации сеансов, генерации слабых или небезопасных идентификаторов сеансов и т. Д., Существует длинный список уязвимостей управления сеансами. Если вы попытаетесь реализовать это самостоятельно, то это будет непросто сделать правильно и безопасно. Так что, если вы собираетесь сделать это таким образом, просто используйте известную хорошую реализацию и все.
Проблема XSS
Есть разница, однако, вы хотите хранить свой «токен» (идентификатор сеанса) в «webstorage», который может быть одним из локальных, сессионных или WebSQL. Традиционное управление сессиями хранит идентификаторы сессий в файлах cookie по хорошей причине - cookie может быть намного лучше защищен от межсайтовых сценариев (XSS). Если cookie-файл сеанса помечен как httpOnly, Javascript не сможет получить к нему доступ, он будет только отправлен обратно на тот же сервер (на самом деле, источником) браузером. Это невозможно с любым другим хранилищем, что означает, что если на вашем сайте есть уязвимость XSS (любая страница того же источника), то пользовательские токены могут быть украдены. И это значительно менее безопасно, чем использование файла cookie httpOnly.
В современных веб-приложениях это часто является допустимым риском. Это происходит в основном, когда вы хотите отправить один и тот же токен на несколько серверов (источник). Это было бы невозможно с файлом cookie httpOnly. Но если ваш токен хранится в базе данных, вы, вероятно, не захотите делать это по архитектурным соображениям, если не иначе.
Проблема CSRF - предотвращена
Также обратите внимание, что эта схема отправки токена в заголовках практически полностью предотвращает подделку межсайтовых запросов (CSRF). Таким образом, положительным моментом является то, что вам не нужно (сильно) заботиться о CSRF, но это происходит за счет воздействия XSS, и это перевешивает это преимущество в большинстве случаев.
вопрос состояния
Как последнее замечание, это не вопрос безопасности, но при использовании вашего дизайна ваш API будет иметь состояние, он будет хранить состояние для каждого клиента. Это не очень хорошо, потому что, как вы правильно сказали, вам придется заходить в базу данных, чтобы проверять токен для каждого отдельного запроса (или вы можете пройти сквозь дыру в кешировании и подобных источниках сложности). А затем представьте, что произойдет, если ваш сервис должен быть сбалансирован по нагрузке, запущен на нескольких серверах с несколькими экземплярами реплик базы данных. Таким образом, современный дизайн API направлен на то, чтобы не сохранять состояния - для клиентов не хранится состояние. И именно здесь сияет (настоящая) аутентификация токенов, токены не нужно хранить в базах данных, они сами являются аутентичными. Вот где аутентификация на основе токенов действительно имеет смысл, а не в простых сценариях, где простой идентификатор сеанса также подойдет и будет более безопасным.