Вопрос или проблема
Мы создаем чистый фронтенд на чистом JavaScript (на Angular) для API, который по прежнему использует OAuth 1 по причинам наследия. Поскольку это чистый JavaScript, секрет потребителя является частью кода, который загружается в начале, до аутентификации, и, следовательно, легко доступен злоумышленнику.
Этот секрет используется для расчета кодов аутентификации вместе с секретом токена, и токен (и обмен аутентификацией) защищены с помощью TLS и песочницы браузера так же, как это было бы, если бы мы перешли на OAuth 2, который вообще не шифрует токен держателя.
Итак, раскрывая клиентский секрет, создаем ли мы дополнительную поверхность атаки по сравнению с OAuth 2, или это просто эквивалентно?
Другими словами, при условии, что используются одни и те же методы защиты связи и доставки токенов авторизации/доступа, существует ли атака, которая может быть реализована против OAuth 1 с утечкой клиентского секрета, которая не может быть реализована против OAuth 2 без клиентского секрета в режиме SPA?
В основном, вы раскрываете секрет… так что он больше не является секретом.
С OAuth 2 у вас есть возможность не использовать статический ключ, реализовав PKCE в вашем процессе. Это означает, что вы можете получить лучшее из обоих миров: легкий вход и защищенные секреты.
Большая разница между OAuth 1 и OAuth 2 заключается в том, что с OAuth 2 вы зависите от реализации криптографии в браузере, в то время как для OAuth 1 вам нужно использовать свои собственные средства.
Все это означает, что, если у вас нет дополнительных мер безопасности, и поскольку вы раскрываете секрет, ваше приложение не защищено от злоупотреблений и подслушивания, поэтому я бы рекомендовал перейти на OAuth 2 с PKCE.
Ответ или решение
Вопрос о сравнительной безопасности OAuth 1 и OAuth 2 в контексте одностраничного приложения (SPA) является существенным, особенно в условиях, когда клиентская секретная информация может быть раскрыта.
Сначала стоит отметить, что OAuth 1 предназначен для использования с клиентскими приложениями, где клиентская секретная информация должна оставаться защищенной и недоступной третьим лицам. Однако в случае SPA — приложения, написанного на чистом JavaScript, которое загружается в браузер, секрет клиента не может быть скрыт. Это создает определенный риск, так как злоумышленник может потенциально получить доступ к этому секрету и использовать его для атаки на API.
В OAuth 1 секрет клиента используется для вычисления различных аутентификационных кодов вместе с токеном секрета. Это подразумевает, что, зная секрет клиента, злоумышленник может подделать запросы к серверу, используя автентификационные данные, что приводит к несанкционированному доступу. Таким образом, утечка секретного ключа в контексте OAuth 1 действительно создает дополнительные уязвимости.
С другой стороны, OAuth 2 не требует такой строгой защиты клиентского секрета в сценариях отсутствия серверной обработки, так как община стандартов предоставляет возможность использовать «странные» методы, такие как PKCE (Proof Key for Code Exchange). PKCE позволяет обеспечивать дополнительный уровень безопасности, не полагаясь на статический секрет клиента. Вместо этого используется динамически создаваемый код, который защищает процесс аутентификации и значительно снижает риски, связанные с утечкой статического секрета.
Таким образом, если в вашем приложении используется OAuth 1, уязвимость при утечке секретного клиента очевидна, и атакующие могут подделывать запросы. В случае OAuth 2, особенно с использованием PKCE, вы защищаете свою аутентификацию, и утечка клиентского секретного ключа не приведет к такому же уровню уязвимости, так как компрометация клиента (в случае SPA) не откроет дверь для несанкционированных запросов к вашему API.
В заключение, я бы рекомендовал рассмотреть возможность перехода на OAuth 2 с использованием PKCE. Это обеспечит большую безопасность вашего приложения, особенно учитывая риски, связанные с использованием OAuth 1 в среде SPA.