По состоянию на август 2020 года указанный документ о передовых методах работы все еще находится в стадии разработки и активно обновляется - см. Редакцию здесь: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/. В реализации OAuth2 в Google еще не применена рекомендация по применению PKCE к веб-приложениям. Для SPA по-прежнему рекомендуется использовать неявный поток в онлайн-документации Googles: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow).
В стандарте PKCE (https://tools.ietf.org/html/rfc7636) говорится, что он был разработан как средство защиты от атак с перехватом кода авторизации, обнаруженных на мобильных платформах, и изначально был рекомендован для реализации собственными клиентами. Документация Google для мобильных и настольных приложений побуждает разработчиков использовать поток кода авторизации PKCE. Клиенты, использующие типы учетных данных Google Android, iOS или Windows с PKCE, могут опускать client_secret (см. Примечание к таблице параметров токена обновления - и подтверждено Криштиану).
В настоящее время признано, что PKCE устраняет необходимость для любых общедоступных клиентов в хранении секрета клиента и, как таковой, может использоваться для исключения неявного потока, который всегда имел недостаток включения возвращаемых токенов доступа и идентификаторов в URI перенаправления. https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead.
В проекте документа IETF говорится в разделе 2.1.1, что это признание, вероятно, станет опубликованным стандартом.
Надеюсь, Google обновит свою реализацию, убрав требование client_secret для запроса токена PKCE, когда передовые методы будут приняты. Между тем, похоже, у нас нет другого выбора, кроме как продолжать писать SPA с использованием неявного потока.
person
Richard Woods
schedule
06.08.2020
