Использование собственного API Publi c на моем веб-сайте - PullRequest
Новая
       20

Использование собственного API Publi c на моем веб-сайте

0 голосов
/ 07 января 2020

У меня есть веб-сайт, который предоставляет API-интерфейс publi c. Я хочу защитить API publi c с помощью OAuth 2. Чтобы свести к минимуму количество поддерживаемых путей кода, я хочу реорганизовать свой веб-сайт, чтобы использовать защищенные OAuth 2 публичные c конечные точки API.

Способ, которым я собираюсь это сделать, - зарегистрировать клиента OAuth 2 на моем сервере как «мой веб-сайт», а затем получить этот токен с коротким сроком службы. Я вижу 2 проблемы с этим подходом:

  1. Мой клиент должен был бы эффективно иметь каждую область, так как веб-сайт охватывает все возможные действия. API является лишь частью этого (хотя я надеюсь изменить это). Второй вопрос - безопасность и кеширование токена. Токен будет жить в течение часа.
  2. Если пользователь обновляет страницу, могу ли я получить другой токен? Если я храню его локально в cook ie или localStorage, существует ли какая-либо уязвимость безопасности?

Допустим, я регистрирую отдельный клиент OAuth для каждой страницы моего пользовательского интерфейса. Это сделало бы так, что токен в # 2 имел бы ограниченную область действия в случае кражи, но он становился чрезвычайно утомительным.

Альтернативой является не использовать API publi c на моем веб-сайте, и защита полагается на CORS. Злоумышленники не могут получить доступ к этим конечным точкам, потому что им разрешено входить только из домена, в котором находится пользователь (и подобных вещей).

1 Ответ

1 голос
/ 07 января 2020

Звучит так, будто вы хотите создать модель, основанную на API-интерфейсе обозревателя браузера, которая, безусловно, является наиболее привлекательной в архитектурном отношении.

Это может быть первым шагом к архитектуре одностраничного приложения, которая стремится обеспечить самое простое и чистое решение.

См. Open Id Connect для приложений браузера для новейших стандартов.

  • В SPA пользовательский интерфейс не имеет файлов cookie и является общим для хранить кратковременные токены доступа в HTML5 хранилище сеансов, что означает, что пользователь может обновить sh страницу в порядке
  • Это правда, что все области извлекаются после входа в систему, но если вы сохраняете области простыми и авторизуетесь в Ваш API основан на правах пользователя. Вы можете уменьшить это

. Вышеуказанное хранилище токенов является поведением по умолчанию для сертифицированной OID C Клиентской библиотеки и широко используется.

Существует риск межсайтового скриптинга: вредоносный контент на вкладке браузера может получить токен и вызвать API - но вы должны защищать в любом случае против этого.

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

Оценка необходимости использования HTML5 хранилища токенов - это больше, чем просто технический механизм - речь идет о приемлемых компромиссах в отношении удобства использования и того, что можно сделать с токеном. Мой пост в блоге о хранилище токенов пользовательского интерфейса углубляется в это.

Если это поможет, в моем блоге также есть довольно много постов и примеров кода на SPA, на случай, если это будет интересно.

...