Как обезопасить токены JWT с помощью серверной части DRF, поддерживающей как мобильных, так и SPA-клиентов?

Я разрабатываю приложение, которое использует фреймворк Django REST для предоставления REST API.

Я намерен защитить его с помощью аутентификации по токену с помощью simple_jwt.

Пример обзора API:

• /auth/login/: Поддерживает POST, требует допустимых username и password, возвращает JWT access и refresh
• /auth/refresh/: Поддерживает POST, требует действительный токен refresh, возвращает новые токены доступа и обновления
• /protected/endpoint/: Требуется действительный токен доступа

Из прочитанного о CSRF я сделал вывод:

• CSRF необходим только в том случае, если задействованы файлы cookie, поэтому используйте его только для клиента SPA
• Для сохранения токена JWT:
  • SPA: Сохраняется в файле cookie httpOnly с параметрами secure=true и same-origin, установленными на
  • App: Сохраняется, однако постоянное состояние приложения работает

Пока все хорошо, однако это означало бы, что мой REST API должен требовать токены CSRF для запросов, поступающих из SPA, и не требовать / игнорировать токены CSRF для запросов, поступающих от клиентов мобильных приложений.

Поскольку это логически невозможно, я сначала подумал о реализации 2 отдельных API. т.е.:

• /spa/auth/..., /spa/protected/...: Для клиентов SPA, где для всех конечных точек требуется токен CSRF
• /mobile/auth/..., /mobile/protected/...: Для мобильных клиентов, где все конечные точки не подпадают под действие CSRF.

Но это просто означает, что моя защита от CSRF бесполезна, поскольку злоумышленник может просто нацелиться на мой мобильный API вместо моего SPA API.

Я также немного читал об АВТОМОБИЛЯХ, но не уверен, как это вписывается во все это.

Вопросов:

• Правильно ли я понимаю, что CSFR необходим только при использовании файлов cookie?
• Если ответ на предыдущий вопрос "да", могу ли я вообще не сохранять токен JWT в cookie для SPA, но при этом каким-то образом надежно сохранять вход в SPA во время сеансов браузера и обновлений страницы?
• Если ответ на предыдущий вопрос "нет", то как я могу поддерживать оба типа клиентов, одновременно предотвращая атаки CSRF?
• Если я не могу использовать токены CSRF для SPA, как мне следует хранить файл cookie CSRF (нужно ли мне вообще, чтобы он был в файле cookie?)? Я предполагаю, что для этого потребуется установить как минимум same-origin, чтобы избежать утечки в другие домены, но должны ли они также быть httpOnly и secure=true? Я читал противоречивые мнения по этому поводу.
• Как я должен реализовать CSRF с помощью DRF? В документации для SessionAuthentication упоминается CSRF, но она расплывчата и даже указывает, что реализация DRF CSRF по умолчанию не подходит для представлений входа в систему.
• Как CORS вписывается во все это? Могу ли я использовать это для устранения возникающих у меня проблем?

РЕДАКТИРОВАТЬ:

Я думал об этом больше - что, если я создам подкласс промежуточного программного обеспечения CSRF и разрешу его обходить, если присутствует заголовок Authorization? Затем запрос может быть удовлетворен или отклонен непосредственно промежуточным программным обеспечением аутентификации (фактически я предполагаю, что при наличии заголовка авторизации я имею дело с мобильным клиентом, который не нуждается в защите CSRF).

Это плохая идея?

Если это не так, то как должен выглядеть LoginView? Он по-прежнему должен быть защищен от CSRF, но ни у мобильных, ни у SPA-клиентов не будет токена для установки в качестве заголовка Authorizaton...

Вернуться на верх