Мы используем библиотеку gRPC-Web от Improbable для предоставления службы gRPC (реализованной в Go) клиенту Javascript, работающему в браузере.Этот сервис будет находиться рядом с существующим внешним интерфейсом Go, в котором размещается API на основе REST.Существующая служба использует аутентификацию на основе сеансов для аутентификации своих пользователей (сеансовые куки-файлы + защита XSRF с двойными файлами cookie , которые также проверяются с использованием некоторого состояния на стороне сервера на стороне сеанса).
Внешний интерфейс Go обслуживает различные конечные точки API, которые обрабатываются локально или выполняются путем передачи запроса другим службам.Все конечные точки предоставляются через цепочку обработчиков промежуточного программного обеспечения Gin, которая реализует вышеупомянутые проверки подлинности сеанса и проверки защиты XSRF.Было предложено, чтобы мы разместили gRPC-Web компонент gogrpcproxy за этим существующим промежуточным программным обеспечением, чтобы предоставить миру наш сервис gRPC.
Я заинтересован в обеспечении подхода для аутентификации входящего gRPC-Веб-запросы безопасны.Были предложены следующие методы:
Аутентификация на основе токенов - т.е. передача токенов-носителей в метаданных запроса gRPC, которые проверяются серверной службой gRPC,Это соответствует модели аутентификации, с помощью которой собственные вызовы gRPC будут аутентифицироваться, если gRPC-Web не был задействован.
В этой модели ответственность gRPC-Web заключается в реализации транспортной абстракции между браузером и сервером и распределении запросовв / из нативного представления gRPC;аутентификация делегируется службе поддержки gRPC.Прокси-сервер gRPC-Web размещается как отдельная конечная точка, внешняя по отношению к существующему API REST.
Аутентификация на основе сеанса - повторное использование существующего промежуточного ПО аутентификации сеанса,В этой модели прокси-сервер grpcweb размещен за цепочкой обработчиков Gin.Gin выполняет свои обычные проверки, чтобы проверить наличие соответствующих файлов cookie и заголовков XSRF до принятия запроса.
Этот подход повторно использует большую часть существующей логики аутентификации.Однако требуется передача заголовка XSRF, чтобы гарантировать, что запрос принят промежуточным программным обеспечением Gin.Это возможно в текущей реализации путем установки метаданных запроса, который (в настоящее время) реализуется путем установки заголовков в исходящем HTTP-запросе.Однако мне неясно, подходит ли это:
- , так как это выглядит как нарушение уровня, используя детали реализации, согласно которым метаданные в настоящее время передаются как заголовки HTTP.Это не задокументировано и может измениться;
- совместимо с транспортом веб-сокетов gRPC-Web, который, по-видимому, не передает метаданные в заголовки, так как транспорт веб-сокетов набирается до передачи любых запросов;
- в будущем может столкнуться с потенциальными проблемами безопасности, поскольку долгоживущее транспортное соединение gRPC-Web с внешней службой аутентифицируется только внешним прокси-сервером при первом установлении, а не постоянно при каждом запросе (если только служба gRPCтакже проверяет метаданные запроса).
Насколько я понимаю, gRPC-Web стремится эмулировать передачу gRPC между браузером и сервером, поэтому, соответственно, не реализует никакой специальной логики аутентификации.Стандартные механизмы gRPC для передачи деталей аутентификации не учитывают неявное состояние на основе сеанса, поэтому я предпочитаю подход на основе маркеров.
Является ли это разумным анализом доступных параметров?