Безопасный способ обмена JWT в ASP.NET Core + SPA

[ultrinfaern]

Из-за того что вы превратили jwt в обычный ид сессии храня его в куках, вся схема прекрасно подходит для CSRF атаки.

Обычно jwt добавляют в авторизационный заголовок:
Authorization: Bearer [jwt]

[edk55]

Для того, чтобы отправлять токен в заголовке, его необходимо хранить в месте, доступном из JS. (память/localStorage/sessionStorage, etc) Это порождает уязвимость к cross-site scripting (XSS) атакам.

[neonbones_sp]

Хорошее замечание. Добавил реализацию защиты против CSRF.

[vanbukin]

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

[neonbones_sp]

Подпись JWT валидируется с помощью настройки в AddJwtBearer -> TokenValidationParameters.
Не совсем понял что значит пойти и подредачить, я именно от этого и старался защититься используя серверные (httpOnly) куки.
Можно подредактировать, если зайти в Dev Tools на браузере с авторизованным пользователем, но тут уже вопрос о нерасторопности человека который отдал свои credentials. В таком случае, это целесообразно чтобы человек не переподписал на себя другую роль.

[andreyverbin]

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

До полноценного решения ещё далеко. Если память мне не изменяет, то в Claims, а затем в JWT попадает SecurityStamp. AspNet.Identity использует это поле для генерации 2fa токенов для totp аутентификации. Зная токен, теоретически можно генерировать такие же токены. Потому крайне желательно шифровать security stamp в JWT.

[MisFis123]

Здравствуйте, я правильно понял что такой jwt нельзя просить для получения его body? Тогда не лучше ли использовать session id он и по объему меньше и там нет оверхеда на внутренние поля

[neonbones_sp]

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

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

[Michael_SL]

Спасибо за статью! Скажите, а вы пробовали подключать swagger (или OpenApi) к API с такой системой аутентификации?

[neonbones_sp]

Не пробовал.