Фон
Я работаю над проектом, в котором мы настраиваем интеграционную платформу/ESB, а также продукт управления API.
Стратегия состоит в том, чтобы иметь уровень интеграции, через который осуществляется большая часть интеграции. Это разделяет отдельные системы, позволяет контролировать доступ и мониторинг в одном месте.
Я тоже новичок в управлении API, но уже несколько лет работаю с интеграцией корпоративных приложений.
Сценарий
В первых интеграциях мы должны предоставить бэкэнд API через платформу управления API. Серверный API, а также вызывающее приложение существуют в Интернете, и серверный API защищен с помощью OAuth 2 (тип гранта = пароль). Однако учетные данные конечного пользователя не отправляются, это своего рода поток от машины к машине.
Нам был предоставлен клиент, а также учетные данные пользователя, и идея состоит в том, чтобы абстрагироваться от приложений, которые вместо этого будут аутентифицироваться в продукте управления API.
Проблема
Однако этот сценарий было трудно реализовать в продукте управления API, похоже, он требует посредничества, поскольку шлюз API не может просто отправить запрос к серверному API, ему сначала нужно получить токен, чтобы иметь возможность вызывать API.
Я разместил еще один вопрос (WSO2 APIM — серверная служба использует OAuth 2 с предоставлением пароля), который больше ориентирован на продукт, но я хочу параллельно спросить об этом сценарии в более широкой перспективе.
Возможное решение
Используйте ESB для передачи потока OAuth к серверному API и используйте продукт управления API в качестве фасада, где осуществляется управление аутентификацией и другими аспектами для вызывающих приложений.
Вопросы
- Поскольку продукт управления API не поддерживает аутентификацию с помощью OAuth 2 по отношению к серверному API, мне интересно, необычен ли этот сценарий? т.е. чтобы абстрагироваться от проверки подлинности внутреннего API при использовании OAuth.
- Является ли это вариантом использования продукта для управления API?
- Является ли возможное решение разумным?
