Защита REST api с Token

Question

Я боролся с этим последние пару дней и не нашел надежного, понятного решения в Интернете.

У меня есть веб-приложение, которое состоит из априори отдыха и уровня представления, потребляющего его. Уровень представления имеет форму входа, данные, введенные пользователем, отправляются в REST api, который затем использует стороннюю службу для аутентификации пользователя. Эта часть, которую я уже создал.

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

Так что, в основном, используя Spring Security (версия 3.1.3), я теряю представление о том, как создать надежный, безопасный токен, вернуть его реквестору, а затем аутентифицировать запрос на основе указанного токена.

Можете ли вы указать мне направление вправо? Или на какой-то пример онлайн?

• Как вы создаете токен? Как вернуть токен клиенту ?
• Как бы вы отправили токен в последующих запросах?
• Как вы все настроите, так что в первый раз вы можете как-то отправить учетные данные (пользователь/пароль), а затем последующие запросы отправят только токен?
• Как вы выполняете аутентификацию против токена?
• Я видел реализации, в которых токен включает некоторое время expiryTime. Итак, что случилось после истечения срока? Пользователь должен снова войти в систему, даже если он все время делает запросы? Должен ли я обновить токен «за кулисами»?

Answer 1

Является ли приложение REST на стороне сервера устаревшим или без гражданства? Если вы работаете с состоянием, вам не нужно ничего делать, используя обычный сеанс HTTP. Просто начните использовать Spring Security, и если клиент и сервер уже обмениваются информацией о сеансе, ваши защищенные конечные точки API будут работать из коробки. Единственное предостережение в том, что если включена защита CSRF, в этом случае вам нужно немного настроить клиента. Подробности для этого приведены в документации Spring Security.

С другой стороны, если приложение REST не имеет гражданства, вам придется использовать подход, основанный на токенах, как вы предложили. См. my answer to a similar post. Если вы решите следовать шагам в этом ответе, ответы на ваши вопросы:

• Токен должен быть создан на стороне сервера. Если вы перейдете к образцу кода, связанного с моим ответом, вы увидите, что я заменил инфраструктуру Spring-based по умолчанию, зависящую от HTTP-сессии Spring Security, на инфраструктуру с кешем. В реализации на основе сеанса уникальный уникальный идентификатор сеанса, который является идентификатором сеанса, генерируется контейнером сервлета, тогда как в пользовательской реализации идентификатор, являющийся токеном, генерируется внутри приложения. В частности, я использовал экземпляр SecureRandom для создания сильных токенов.
• Токен отправляется клиентом как HTTP-заголовок. Это защищает контент по каналу SSL.
• Трюк заключается в реализации четырех очень простых интерфейсов от Spring Security. В моем примере приложения есть полная информация. Весь процесс занял у меня меньше часа.
• Аутентификация против токена выполняется автоматически с помощью Spring Security. Нам просто нужно предоставить реализацию для хранения и извлечения токенов, что является простым и занимает всего несколько строк кода.
• В моем примере приложения я использовал запасной кэш со скользящим истечением для хранения токенов. Если клиент периодически отправляет запросы, сервер продолжает обращаться к кешу для токена аутентификации, тем самым сохраняя токен в кеше. Токены выгружаются из кеша только после периода бездействия, равного или превышающего период истечения срока действия кеша.

В общем, подход аутентификации/авторизации на основе токенов можно легко реализовать с помощью Spring Security и использовать библиотеку кэширования, такую ​​как EHCACHE.