Является ли этот процесс аутентификации пользователя разумным?

Question

Я занимаюсь разработкой RESTful API-сервера для связи с кроссплатформенными клиентами, такими как Android, iOS, веб-браузер и т. Д.

При успешном входе пользователя по имени пользователя и паролю этот сервер выдает токен доступа (JWT, 5 минут) и токен обновления (GUID, 20 дней).

Когда мы разрабатываем клиентское приложение Android для связи с сервером, мы просто можем хранить эти токены на мобильном устройстве, и я считаю, что это не будет проблемой с точки зрения безопасности (при использовании SharedPreferences).

Но когда речь заходит о веб-браузерах, (React App) мне пришлось решить, где хранить эти токены. Наконец, я решил HttpOnly Cookie, потому что я могу легко управлять атаками CSRF, а не XSS.

Вскоре я сомневаюсь, что это типичный дизайн. Например, пользователи веб-браузера не могут выйти из системы, когда они хотят. Поэтому я решил изменить сервер-оболочку (Node.js) между приложением React и сервером RESTful API.

В моем втором проекте приложение React и сервер-оболочка аутентифицируют модель cookie-файлов сеанса, используя passport.js для примера. И когда оболочка распознает запрос, прошедший проверку подлинности, оболочка выдает токен краткосрочного доступа (1-минутный JWT) и реорганизует запрос, вставляя только что выданный маркер доступа в заголовок, отправленный на сервер API RESTful.

Это разумный процесс? Заранее спасибо.

Answer 1

Вы можете упростить свое решение, полностью удалив маркер доступа JWT. Токен обновления можно использовать в качестве идентификатора сеанса. Каждый раз, когда клиент отправляет вызов API на сервер, идентификатор сеанса отправляется в заголовке HTTP, поэтому вы можете проверить, является ли запрос законным.

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

Надеюсь, это поможет вам, дайте мне знать, если я что-то упустил.