#oauth #jwt #auth0 #apigee
#oauth #jwt #auth0 #apigee
Вопрос:
У меня есть служба, защищенная с помощью OAuth. Для его использования сначала требуется токен. У меня есть приложение, которое имеет доступ только к прокси-серверу Apigee. Я бы хотел, чтобы Apigee выполнял аутентификацию для клиента (приложения) и устанавливал защиту с помощью ключа API для клиента в Apigee. Как мне это сделать?
Комментарии:
1. Вы хотите сказать, что Apigee выполнит рукопожатие OAuth, используя учетные данные, хранящиеся в Apigee, чтобы получить токен OAuth и передать его вашей службе, которая затем проверит токен OAuth?
2. Первая часть: да, вторая часть не полностью. Apigee извлекает токен (из Auth0) с интерфейсом m2m и сохраняет этот токен в памяти (время от времени обновляя его). Таким образом, Apigee может получить доступ к серверной службе. Затем есть клиентское приложение, пытающееся получить данные через Apigee с помощью ключа API. Apigee проверяет этот ключ API и, если все в порядке, вызывает серверную службу с ранее требуемым токеном.
3. Поэтому я не хочу предоставлять клиенту что-либо из серверной службы, я хочу, чтобы Apigee позаботился об этой части (с ограничением скорости и т.д. и т.п.)
4. Итак, просто для ясности, вы используете защищенную конечную точку, требующую токена OAuth, и снижаете эту безопасность, требуя только ключ API?
5. Да, исходящий OAuth — это определенно то, что вы ищете. Мне потребовалось около 30 минут, чтобы адаптировать образец проекта из Apigee к моим потребностям (имитируя ваши потребности).
Ответ №1:
Я думаю, что вы пытаетесь сделать то, что Apigee называет безопасностью последней мили. К сожалению, это не так просто, как добавить политику и настроить ее с помощью URL-адреса токена, идентификатора клиента и секрета. Вам нужно убедиться, что вы надежно храните учетные данные, соответствующим образом кэшируете токен и передаете токен целевому прокси.
К счастью для вас, у Apigee есть демонстрационный проект, который делает то, что, как я полагаю, вы пытаетесь сделать. В принципе, ваш прокси-сервер будет настроен с помощью простой политики проверки ключа API (сделайте это сначала, как если бы ключ API был неправильным, нет необходимости выполнять все проверки подлинности OAuth). После подтверждения вы можете использовать политики Javascript для проверки кэша на наличие токена, а затем вызвать конечную точку токена OAuth, чтобы получить ее, если в кэше отсутствует. Я полагаю, что затем он использует политику AssignMessage для установки заголовка авторизации для токена. (Обратите внимание, что пример проекта не включает политику проверки ключа API, но это должно быть достаточно легко добавить)
Кроме того, демонстрационный проект хранит идентификатор клиента и секрет в файле js, что я бы не рекомендовал. Может быть, сохранить его в зашифрованных записях KVM?
Пример проекта Outbound OAuth можно найти здесь.
Комментарии:
1. Я действительно следовал их инструкциям, изменил api-config.js в мой локальный OAuth добавил политику проверки ключа API, изменил целевой URL на мой собственный API и заставил его работать. Вы даже можете увидеть, как работает кэширование, когда последующие вызовы пропускают извлечение токена OAuth.
2. Я действительно думал об этом, и это потребовало бы больше работы, но, возможно, было бы неплохо иметь набор учетных данных для каждого из ключей API, которые вы разрешили вызывать API. Таким образом, базовый API сможет различать разных потребителей. В противном случае у вас могло бы быть 10 потребителей через Apigee, и все они выглядели бы как один потребитель для вашего внутреннего API.
3. Кроме того, принятие ответа позволяет другим пользователям, которые испытывают такую же потребность, быстро найти тот, который отвечает на ваш вопрос. Я полагаю, что я предоставил решение вашего вопроса, даже подтвердив, что оно делает то, что вам нужно.
Ответ №2:
пожалуйста, ознакомьтесь с приведенными ниже видеороликами об использовании аутентификации oauth в ваших прокси-серверах API:
https://www.youtube.com/watch?v=zn94GhcdgHcamp;list=PLsWqc60hQz4clQ4ykjCu4qyEhdKe11Lvy
Комментарии:
1. Пользователь хочет использовать исходящий OAuth, а не OAuth для защиты своего прокси-сервера API.
Ответ №3:
Вы можете использовать тип предоставления учетных данных клиента Ouath2, что подразумевает, что вы должны добавить и настроить политики безопасности в своем прокси, проверьте следующую ссылку, которая объясняет этот процесс.
https://docs.apigee.com/api-platform/security/oauth/oauth-20-client-credentials-grant-type
Комментарии:
1. Они хотят, чтобы прокси-сервер api был защищен только с помощью api ket, в то время как целевой сервер требует передачи токена доступа oauth в заголовке Auth. они не хотят, чтобы Apigee требовал токен доступа oauth.