Как работает аутентификация по токену с помощью сбалансированных веб-сервисов с нагрузкой

Question

Мы используем защиту на основе токенов на некоторых наших веб-сервисах ArcGIS Server, и я пытаюсь лучше понять, как они работают. В настоящее время мы должны использовать липкие сеансы, потому что у нас есть сбалансированные нагрузки для избыточности и производительности. Однако вся документация, которую я читаю (например, в приведенной ниже статье), предполагает, что использование аутентификации на токенах фактически должно устранять необходимость в липких сеансах. После всего того, что я прочитал, я все еще не уверен, почему это так.

Если пользователь входит в систему и получает токен с одного из наших серверов с балансировкой нагрузки, а токен передается с каждым последующим запросом, почему не обязательно, чтобы запрос заканчивался на том же сервере. Как другой сервер сможет аутентифицировать токен? Единственный способ, с помощью которого я могу думать о том, что это можно сделать для работы без липких сеансов, заключается в том, чтобы хранить подпись маркера в центральном репозитории, доступном для всех серверов с балансировкой нагрузки. Опять же, это не то, что отличается от простого хранения самого токена, который совпадает с хранением информации сеанса.

http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543

Answer 1

Единственный способ, которым я могу думать на основе моих показаний, что это может быть заставить работать без липких сессий для хранения маркеров подписи в центральном хранилище доступной для все балансировки нагрузки сервера.

Да, это правильно. Связанная статья показывает постоянное хранилище токенов.

Единственным исключением является использование JWT (также в связанной статье) или аналогичный механизм, который не хранит маркеры на стороне сервера.

Это потому, что хотя имя пользователя находится в JWT, которое может быть сохранено на стороне клиента cookie, имя пользователя защищено MAC. Этот код аутентификации сообщения хэширует имя пользователя с секретностью на стороне сервера. Этот секрет можно распределять между всеми серверами с балансировкой нагрузки, а повторный запуск алгоритма MAC может гарантировать, что имя пользователя, сохраненное на стороне клиента, не было изменено.

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