Является ли oauth2 небезопасным?

Я реализую решение oauth2 для созданного API, и я борюсь с потенциальными insecurites (или, по крайней мере, с пониманием).

Правильно ли, что генерируется только один токен и используется в качестве учетных данных аутентификации для запроса конечной точки. Что прекращает потенциальную атаку грубой силы, когда злоумышленник просто подает токены в API в надежде, что он будет действительным и будет использоваться?

Я, вероятно, неправильно понял что-то, но я не могу понять, что это такое.

2
nl ja de
В какой-то степени каждая система небезопасна. Но вы не должны беспокоиться о «преждевременной секущей», так сказать.
добавлено автор user529758, источник
Так беспокоиться об этом только после того, как вы внедрили решение и были взломаны?
добавлено автор Nick, источник

2 ответы

Конечно же, токены должны быть трудно себе представить. Например, они не должны быть простыми последовательными целыми числами. Также нет предела длине маркера. Есть два варианта:

1) создайте длинный токен, зашифрованный с помощью вашего собственного ключа (обратите внимание: он не должен иметь быть длинным, но с тех пор, как криптография сделает его неявным). Вы можете проверить, что токен действительно ваш, потому что вы единственный, кто может шифровать и расшифровывать эти токены.

2) строят маркеры, которые также хранятся в вашей базе данных, и их достаточно сложно создать, поэтому вы проверите токены в своей базе данных.

Вы также можете комбинировать два подхода. Вы также должны добавить некоторое время истечения срока действия для токенов (либо встроенных в него в 1-м случае, либо в стороне от токена в базе данных во втором случае).

2
добавлено
То, что вы рекомендуете, не препятствует нападению грубой силы. Зашифрованный или нет, токен - это всего лишь последовательность символов и чисел.
добавлено автор Maxime Laval, источник

Одним из наиболее уязвимых типов грантов в OAuth 2.0 для Brute Force Attack является тип учетных данных владельца ресурса. В этом случае хакер имеет доступ к учетным данным клиента (clientId и пароль), и он/она требует только учетных данных владельца ресурса (пользователя) (имя пользователя и пароль). Существует модель реализации аутентификации, описанная в Java - Spring Security здесь , которая прольет некоторый свет, чтобы избежать этой проблемы.

1
добавлено