Я тщательно изучил всю документацию, которую смог найти, и все, что я вижу, похоже, направляет меня к решению, которое не работает.
Текущая ситуация:
Я использую поток кода аутентификации для своего веб-приложения (. NET Core). У меня есть промежуточное ПО Okta, реализованное в веб-приложении. Я использую веб-виджет Okta. После входа пользователя в систему мое веб-приложение передает токены моему API, а в моем приложении API также работает промежуточное ПО Okta. Все отлично работает. Мой API знает, кто является пользователем, и может аутентифицировать токен, а затем даже выполнять дополнительные проверки для ролей / et c.
Теперь мне нужно добавить несколько Azure функций, которые будут запускать запланированные задания. Им также нужно поговорить с моим API. Я прочитал все документы и не могу понять, как я должен это делать.
Сначала я подумал, что это очевидный случай для модели учетных данных клиента (с сервера на сервер) . Итак, я реализовал учетные данные клиента и сделал вызов API, чтобы получить access_token. Но когда я передаю этот токен своему API, он терпит неудачу:
Bearer was not authenticated. Failure message: IDX10214: Audience
validation failed. Audiences:
Аудитория для кода, который дает мне поток кредитов клиента: "aud": "api: // {{идентификатор моего сервера аутентификации }} "
Но одно мое приложение использует виджет okta и поток кода аутентификации:" aud ":" {{my client id}} ",
Итак, нет никакого способа чтобы заставить это работать. Итак, я перехожу к потоку владельцев ресурсов.
Я не могу использовать поток владельцев ресурсов в моем текущем приложении (в Okta), потому что мое текущее приложение его не поддерживает. Если я устанавливаю новое приложение и использую этот поток, access_token, который я получаю от него, не работает, опять же, потому что он не проходит при проверке аудитории. Аудит для этого токена: "aud": "{{diff client id}}",
Итак, в итоге:
- Если я использую client_creds в моем текущем приложении, токен не подходит
- Если я использую поток владельца ресурса в новом приложении, токен не подходит
Поскольку мы говорим о приложении, здесь нет способ для него использовать поток кода аутентификации, потому что я не могу что-то там "получить" обратный вызов. Так что я немного застрял.
Фактически все, что я хочу сделать, - это заставить функцию Azure действовать как пользователь и вызывать определенные API. Я чертовски близок к тому, чтобы создать отдельный экземпляр моих API, который не открыт для inte rnet и доступен только через IP-адрес Azure Functions (или что-то действительно неубедительное), чтобы я мог отключить Okta в этом случае и двигаться вперед - но это кажется безумным. / OpenId не совсем моя специальность. Меня также беспокоит то, что я не знаю, как я могу предоставить доступ к своим API-интерфейсам внешним платформам в какой-то момент в будущем, когда я даже не могу заставить работать свой собственный.
Есть ли у кого-нибудь рекомендуемый подход для обработки этого сценария?