Хранение JWT в файле cookie на основе сеанса Angular 6

Question

Я новичок в разработке Angular и хотел бы знать, как правильно хранить JWT?

Я работаю над приложением, разработанным в одностраничном приложении Angular 6.1 с использованием аутентификации Auth0.

После аутентификации Auth0 возвращает JWT (токен доступа (jwt)), а затем приложение сохраняет его в локальном хранилище.Затем клиентское приложение выполняет пост-вызов к оформленному методу [authorize] в API (MVC C #) для проверки доступа к ресурсам API.API использует OWIN и выполняет проверку.

Хотя маркер доступа содержит значения эмитента и аудитории, которые проверяются промежуточным программным обеспечением OWIN, но меня беспокоит, может ли кто-нибудь получить к нему доступ из локального хранилища и использовать его позже имимо процесса входа в систему?

Должен ли я хранить "access_token" в файле cookie сеанса на стороне сервера?

Любое руководство будет высоко ценится.

Answer 1

Хранение «access_token» на стороне сервера - плохая идея, потому что оно нарушает основную цель аутентификации JWT без сохранения состояния.Поступая таким образом, вы можете просто реализовать любой другой вид авторизации на стороне сервера, например, старые хорошие сеансы, хранящиеся в базе данных, и JWT не требуется.

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

Благодаря этому вы можете реализовать чистую логику в промежуточном программном обеспечении авторизации (какой-нибудь хук preAuth?), Который будет проверять, равен ли IP-адрес запроса IP-адресу, сохраненному в JWT.Если IP-адрес изменился, вероятно, кто-то украл токен.

Answer 2

Blockquote Хотя маркер доступа содержит значения эмитента и аудитории, которые проверяются промежуточным программным обеспечением OWIN, но меня беспокоит, может ли кто-нибудь получить к нему доступ из локального хранилища и использовать его позже и пройти процедуру входа в систему?

Да, они могут использовать его повторно. Но вы можете установить срок действия основного токена, а также создать токен обновления, а также обновить его в главном токене X time и обновить токен, когда основной токен истек, вы запрашиваете токен обновления, и если он действителен, вы обновляете два токена. Это лучше, чем бесконечный токен доступа, который кто-то может использовать повторно. Вы реализуете эту логику в перехватчике, когда токен истекает из бэкэнда, вы возвращаете статус 403, и когда вы получаете этот статус во внешнем интерфейсе, вы отправляете основной токен и токен обновления в бэкэнд для его обновления. И если действительны два токена, вы обновляете его, иначе вы отключаете пользователя.