#azure #api #oauth #bearer-token
#azure #oauth #токен на предъявителя
Вопрос:
У меня есть локальный API, который использует OAuth, поэтому я использую заголовок «Авторизация: на предъявителя …» при вызове его из on-prem. Теперь я хочу вызвать этот API из внешнего, используя прокси-сервер приложения Azure с аутентификацией. Я знаю, как получить токен-носитель для аутентификации на прокси-сервере приложения.
Проблема в том, что при одном и том же HTTP-вызове on-prem API из внешнего мне нужно иметь 2 разных заголовка «Authorization: Bearer …», один для прокси-сервера приложения и один для on-prem API.
У меня не может быть просто 2 заголовка авторизации, верно? Итак, как мне вызвать свой встроенный API из внешнего?
Редактировать: я так и не нашел реального решения, поэтому я создал «Локальный прокси», который заменяет Authorization: Bearer после прокси-сервера Azure App. Вот как это работает :
- Внешнее приложение вставляет 2 заголовка с вызовом прокси-сервера приложений Azure (AAP). Во-первых, это авторизация: предъявитель с токеном, требуемым AAP. Второй — это фиктивный заголовок «AuthorizationOnPrem» с токеном, который требуется приложению за прокси-сервером Azure (on-prem).
- Прокси-сервер Azure перенаправляет вызов на мой пользовательский «локальный прокси».
- Этот предварительный прокси-сервер копирует токен из AuthorizationOnPrem в Authorization.
- Затем предварительный прокси-сервер вызывает реальное предварительное приложение с теми же данными, которые были вызваны, но с правильным токеном.
Я знаю, что он довольно исправлен, но он работал для меня с приложением on-prem, в котором я нуждался. И это было на удивление легко сделать. Однако это может быть недостаточно масштабируемо.
Комментарии:
1. Прямо сейчас сталкиваюсь с той же проблемой. Приводит в бешенство то, что прокси-сервер приложения ожидает токен в заголовке авторизации вместо заголовка авторизации прокси. Я не знаю, как они могли пренебречь вариантом использования необходимости авторизации для чего-то за прокси.