Я имею в виду параметр состояния , который можно использовать для предотвращения CSRF-атак при использовании авторизации OAuth2.
Мой сервер API выступает в качестве бэкэнда для реакции на одну страницу приложение и без сохранения состояния, используя JWT вместо сессий. Я пытаюсь разрешить пользователям входить в мое приложение, используя OAuth2, в частности службу OAuth2 Discord, но у меня возникли некоторые проблемы с этим параметром состояния.
Поскольку я не использую сеансы, не очевидно, где я должен хранить уникальный параметр состояния на моем сервере. Я думал о хешировании идентификатора пользователя, который можно найти в JWT пользователя, и использовании его в качестве состояния, но пользователь не будет проходить аутентификацию с моим API, пока он не аутентифицируется с поставщиком OAuth2, поэтому у него еще не будет JWT .
Единственное решение, которое я мог придумать, - это использовать http-only, secure cook ie и хранить там параметр состояния. Например, поток будет:
- Пользователь переходит на mysite.com/login. Случайный уникальный параметр состояния генерируется и сохраняется в защищенном режиме только для http ie. Затем пользователь перенаправляется к поставщику OAuth2 с параметром состояния в URL.
- Пользователь проходит проверку подлинности с поставщиком OAuth2 и перенаправляется на конечную точку обратного вызова моего API. Затем параметр состояния извлекается из пользовательского кода cook ie и сравнивается с состоянием в URL обратного вызова. Если они одинаковы, пользователь проходит проверку подлинности.
Я думаю, что это должно быть безопасно, потому что я считаю, что он ведет себя так же, как и состояние на основе сеанса. Например, обычной практикой является использование ha sh идентификатора сеанса пользователя в качестве параметра состояния, а идентификатор сеанса сохраняется в файле cook ie.
Правильны ли мои логики c здесь ? Является ли это правильным способом обработки состояний OAuth2 при использовании JWT вместо сессий?
Заранее спасибо!