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