Как предотвратить неутвержденный доступ сторонних SPA к ресурсу при использовании OAuth 2.0 для авторизации?

Question

Я пытаюсь разрешить доступ к нашим общедоступным API только к утвержденным одностраничным приложениям. В настоящее время мы используем OAuth 2.0 для управления доступом к нашим API. Сценарий высокого уровня заключается в том, что наши пользователи получат доступ к нашему общедоступному SPA, предоставят свое имя пользователя и пароль, а затем смогут использовать SPA, который, в свою очередь, сможет использовать наши API.

В настоящее время для OAuth 2.0 с SPA рекомендуется использовать предоставление кода авторизации с идентификатором клиента, но без секрета клиента, поскольку, очевидно, SPA не может хранить никаких секретов.

Мой вопрос: как мы можем предотвратить доступ сторонних SPA к нашим API? То есть они могли бы извлечь существующий client_id из нашего SPA и запросить код авторизации таким же образом, как и у нашего первого SPA. Предполагая, что они могут убедить пользователя войти в систему, они могут получить доступ к нашим API. Является ли предварительно зарегистрированный URL перенаправления единственной защитой в этом сценарии? Если это так, значит ли это, что если мы перейдем к использованию гранта учетных данных владельца ресурса для лучшего взаимодействия с пользователем (я не рекомендую это делать), то вообще не будет никакой защиты от сторонних приложений?

Я прочитал различные RFC для OAuth, и эта страница, в частности, очень полезна, но не совсем отвечает на мой вопрос: https://auth0.com/blog/oauth2-implicit-grant-and-spa/

Answer 1

Действительно, предварительно зарегистрированный URI перенаправления является единственным механизмом защиты в этом случае общедоступного клиента при использовании так называемого типа неявного предоставления. Злоумышленник может обмануть пользователя при запуске потока, но не получит выданный токен на URL-адресе перенаправления, которым он управляет. Это похоже на обман пользователя при запуске любого другого потока входа в систему.

Поскольку злоумышленник не получает токен (он все еще доставляется по назначенному URI перенаправления, контролируемому клиентом), он не может получить доступ к вашим API, даже если он может убедить пользователя войти в систему.

Когда злоумышленник контролирует DNS, все становится более опасным, но это касается и многих вещей вне OAuth 2.0. В целом: доставка токенов в приложение в браузере будет страдать от этого типа уязвимости независимо от используемого протокола.

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

В итоге: защита от этого есть, хотя и не суперсильная.

FWIW: последние передовые практики OAuth 2.0 предполагают, что токены больше не должны напрямую доставляться в URI перенаправления, а вместо этого используется промежуточный краткий одноразовый код авторизации использования, чтобы SPA мог получать свои токены в вызове XHR непосредственно от конечной точки токена.