Я пытаюсь понять различные типы грантов, предлагаемые OAuth2.0. Я читал об этом, и есть много ресурсов, которые объясняют это в хороших деталях, таких как это , это & это , чтобы процитировать несколько.
В случае типа предоставления кода авторизации, насколько я понимаю, есть 2 шага.
Шаг 1 - Чтобы получить сам код авторизации
Итак, давайте предположим, что пользователь открывает приложение, скажем AwesomeApp в своем браузере. Это приложение имеет опцию, скажем, Войти через Facebook , которую пользователь выбирает на go вперед. Это инициирует запрос GET к серверу авторизации (в нашем примере, к Facebook) с необходимыми подробностями в параметре запроса, что-то вроде (взято из одного из ресурсов, указанных выше):
https://authorization-server-of-facebook.com/auth?response_type=code&
client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
Теперь я понять значение каждого из этих параметров (еще раз спасибо ресурсам). Я также понимаю, что прежде чем AwesomeApp сможет сделать этот вызов, он должен зарегистрироваться в Facebook, чтобы получить идентификатор клиента и секрет клиента ( с помощью некоторых средств ).
Теперь, когда пользователь утверждает запрос. Сервер авторизации Facebook отвечает на вышеуказанный запрос, перенаправляя браузер пользователя обратно на предоставленный URI перенаправления (в вышеуказанном запросе) и с кодом авторизации.
Шаг 2 - Обмен кода авторизации для фактического токена доступа
Теперь AwesomeApp необходимо обменять код авторизации, полученный выше, на токен доступа. Для этого AwesomeApp делает запрос POST, как показано ниже:
POST https://api.authorization-server-of-facebook.com/token
grant_type=authorization_code&
code=AUTH_CODE_RECEIVED_IN_THE_ABOVE_STEP&
redirect_uri=REDIRECT_URI&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
На указанный выше запрос сервер авторизации facebook возвращает обратно токен доступа, refre sh токен, время истечения срока действия et c. и др c.
Теперь мой вопрос в шаге 2 выше. Разве этот POST не должен быть внутренним вызовом? Почему? Потому что это требует, чтобы секрет клиента также передавался в запросе. Если бы это было сделано из внешнего интерфейса AwesomeApp, он легко просочился бы в поддельного пользователя. Не так ли?
Так что я подумал, что это должно быть что-то вроде того, как только AwesomeApp получит код авторизации, клиентский интерфейс AwesomeApp должен отправить это в свой собственный бэкэнд и затем AwesomeApp ' Бэкэнд должен выполнить вышеуказанный POST-запрос, получить токен доступа (и другие подробности) из ответа на вышеуказанный запрос и затем передать его внешнему интерфейсу. Разве это не так, как должно быть?
Теперь в большинстве ресурсов, с которыми я сталкивался (включая ссылки выше), обсуждается PKCE Extension, в котором говорится о генерации динамического c клиентского секрета каждый раз. , Но как лучше, если POST (тот, что на шаге 2) все еще выполняется из самого интерфейса? Также, если этот секретный ключ клиента генерируется динамически каждый раз, это может быть сделано ложным пользователем, не так ли? Я имею в виду, как сервер авторизации может проверить, что клиент, сделавший запрос, действительно был тем, кого он разрешил? (В случае с секретом клиента это имело смысл, потому что секрет клиента был передан AwesomeApp сервером авторизации Facebook. В этом случае это не так, потому что этот секрет генерируется самим клиентом).
Что за недоразумение во всем вышеперечисленном?
Согласно описанному потоку здесь , 
, как работает code_verifier мешать злоумышленнику играть за подлинное приложение? В отличие от секрета клиента, когда злоумышленник никогда не сможет выдать себя за подлинного клиента (если, конечно, сам секрет клиента не будет каким-то образом взломан), в этом случае злоумышленник может просто отправить любой code_verifier. Еще до того, как запрос токена и проверка code_verifier & окончательного ответа появятся на снимке, как сервер авторизации может даже проверить, что запрос авторизации действительно поступил от подлинного клиента?