Использование учетных данных клиента «OAuth» в приложении на базе браузера

Question

Мы создаем веб-приложение, которое обрабатывает приложения для объединения пользователей, и рассматривает несколько вариантов приложений приложений типа «клиент-сервер» и «СПА». Наше предпочтение от перспективы использования пользователей, вероятно, является полностью клиентским SPA, но у меня есть проблемы безопасности API.

Поскольку мы не являемся пользователями аутентификации (они еще не являются пользователями), стандарт OAuth подразумевает, что нам нужно будет использовать тип гранта «учетные данные клиента». Это не проблема, если сервер справляется с этим, но в SPA сами учетные данные сидят в браузере для всех, кто видит, и наш API-шлюз не может отличить законный вызов API от нашего SPA в браузере от сценария. написал с собранными подробностями.

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

С другой стороны, с помощью Одиночная страница, работающая в браузере, о единственных элементах управления, которые я могу думать о том, чтобы ограничить скорость вызовов API в шлюзе API, но я подозреваю, что этого будет очень мало.

Случайная мысль: Одна из моих идей заключалась в том, чтобы использовать «неявный» тип предоставления OAuth, как если бы это был процесс аутентификации пользователя. Когда мы перенаправляемся на страницу входа в систему, она фактически не требует взаимодействия с пользователем и вместо этого захватывает отпечаток пальца устройства (например, IP-адрес, браузер, язык, разрешение экрана), а затем перенаправляет обратно как «успешный» вход. Тогда у клиента есть уникальный токен доступа, и мы отслеживали несколько деталей о конечном пользователе для целей аудита и потенциально оценивали риск. Это требует настройки нашего Auth Server - безусловно, возможно, но не обязательно идеально.

Есть ли другие подходы, которые люди предпринимают для защиты вызовов API в веб-приложениях SPA, которые являются успешными и безопасными? Или я придерживаюсь маршрутизации вызовов API через сервер приложений, который применяет элементы управления на основе браузера?

Цените любые мысли или идеи ...

Answer 1

Если кто-то заботится - и, судя по количеству просмотров, возможно, не так!:) - подход, который мы берем следующим образом:

Где можно:

• Мы будем иметь сервер приложений какой-то ответственный за динамически генерировать JavaScript для страницы, а не служить статический контент с вебом-сервера
• сервер приложений собирается внутренне обмен учетных данных клиента для маркеров доступа с ограничением по времени, и врезать, что маркер доступа в JavaScript отправлена ​​в браузер
• Если хакер захватывает токен доступа, то он может использовать его, но только в ограниченном временном окне (хотя они всегда могут вернуться и получить новый, запросив сайт снова, но это не так уж и отличается от POSTing в веб-форме)
• Применение ограничение скорости на шлюзе API для соответствия ожидаемому трафику API с законного сайта, поэтому, если кто-то скриптит что-то, чтобы использовать API и собранный токен, то не только им не придется долго это делать, они выиграли «т иметь возможность вбить сайт с неограниченным количеством вызовов

, где это не возможно, чтобы динамически вставить маркер доступа в JavaScript:

• мы либо принесения в жертву SPA и делает клиент-сервер, или мы просто положить учетные данные клиента в JavaScript в любом случае, и признавая, что они могут быть скомпрометированы
• Мы снова
применять ограничение скорости на шлюзе API
• учетные данные рассматриваются только как показатель для отслеживания и скорости ограничения целей

Я решил каверзный вариант перенаправление-с-дактилоскопии, насколько слишком сложным для наших нужд, а другие могли бы хотеть продолжать, если вышеуказанные подходы не работают.

Надеюсь, что кто-то посчитает это полезным.