#oauth-2.0 #authorization #csrf #csrf-token
#oauth-2.0 #авторизация #csrf #csrf-токен
Вопрос:
У меня есть несколько вопросов о потоке предоставления кода авторизации. Я знаю, что первая часть oauth2 заключается в том, чтобы отправлять https://auth.server/oauth2/auth?scope= amp;redirect_uri=https://app.example.com/oauth2/callback amp;response_type=codeamp;client_id=123 amp;state=af0ifjsldkj
Меня смущает параметр состояния. Я понимаю, что параметр состояния предназначен для предотвращения атаки csrf. Но где я должен сохранить этот параметр? Если я сохраню его в сеансе сервера аутентификации, как я могу проверить состояние на следующем шаге?
https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7amp;state=af0ifjsldkj
как я могу проверить параметр состояния в app.example.com но параметр состояния сохраняется в сеансе сервера авторизации?
Ответ №1:
Библиотека безопасности вашего стека технологий должна управлять этим за вас, и состояние будет сохранено в вашем приложении:
- Для одностраничного приложения обычно сохраняется состояние в локальном хранилище
- Для веб-приложения на стороне сервера обычно вместо этого используется временный файл cookie только HTTP
Единственная задача сервера аутентификации — гарантировать, что он возвращает в ответе приложению то же состояние, которое он получил в запросе от приложения. Любой готовый сервер аутентификации сделает это за вас.
Поведение наглядно описано в шагах 4 и 7 моего сообщения в блоге. В моем случае я использую SPA, а клиентская библиотека OIDC управляет проверкой состояния ответа.
В результате мое приложение защищено от атак CSRF. Если бы кто-то вставил это в адресную строку браузера, мое приложение не пыталось бы обработать код авторизации:
Комментарии:
1. но, как вы упомянули о cookie, почему мы не используем session?
2. Состояние предназначено для сохранения в клиенте / пользовательском интерфейсе и проверки там, в соответствии со стандартами OAuth, для защиты от определенного класса атак с подменой. В некоторых случаях сервер аутентификации действительно сохраняет состояние в своем сеансе, например, для защиты PKCE, хотя это защищает от различных атак. В модели угроз OAuth эти аспекты рассматриваются более подробно.