Интеграция внешнего интерфейса и сервера ресурсов с использованием аутентификации okta и аутентификации API учетных данных клиента

Question

У нас есть приложение с интерфейсом внешнего интерфейса (веб-приложением), которое взаимодействует с сервером ресурсов. Наш веб-интерфейс будет использовать некоторые API-интерфейсы с сервера ресурсов для получения данных.

Я планирую добавить веб-интерфейс к Okta и предоставить доступ зарегистрированным пользователям Okta.

На сервере ресурсов мы имеем некоторые API, которые мы хотим предоставить нашим клиентам для интеграции в их систему (программно). Чтобы использовать наши API, мы должны предоставить им учетные данные клиента (идентификатор клиента / секрет). Используя clientId / Secret, они получат access_token и будут использовать его в следующем запросе. Мы можем отобразить этот clientId / Secret через интерфейс внешнего интерфейса, как только пользователь войдет в него через Okta.

Как следует проверять подлинность запросов к серверу ресурсов от внешнего интерфейса? И как я могу аутентифицировать запросы к серверу ресурсов через клиента, используя clientId / Secret? Должен ли я использовать один или два разных токена для этой цели?

Предоставляет ли Okta идентификатор клиента / секретный ключ для каждого пользователя, который пользователь (клиент) может использовать для получения access_token и отправки его на сервер доступа к серверу ресурсов и на сервер проверки ресурса? против Окты.

Answer 1

Вам нужно будет использовать 2 разных токена доступа. Здесь происходит 2 различных потока:

• Веб-интерфейс для API
• Система делового партнера для API

Технически это означает:

• Поток кода авторизации (PKCE)
• Поток учетных данных клиента

А в терминах токенов это означает:

• В первом случае есть конечный пользователь, представленный в токенах доступа (претензия 'sub')
• Во втором случае в токенах доступа есть только требование Client Id

Я могу посоветовать токен методы проверки, если это необходимо - дайте мне знать.

Мне кажется, что это похоже на архитектурный вопрос - в частности, в отношении применения авторизации после идентификации вызывающего абонента и управления версиями / обновлениями.

На основании моего опыта я как правило, в наши дни предпочитают использовать следующую архитектуру, основанную на двух уровнях API: например, с этими, доступными для inte rnet:

• API пользовательского интерфейса обслуживает пользовательский интерфейс
• Partner API имеет дело с B2B * 10 34 *

И оба API-интерфейса точки входа вызывают одни и те же основные сервисы, которые являются внутренними. Возможно, стоит обсудить это с заинтересованными сторонами ..

Answer 2

Я только что сделал что-то очень похожее. Вы можете прочитать о моем опыте здесь: Как передать / проверить токен Open ID между net основным веб-приложением и веб-интерфейсом?

Я не знаю, какая у вас среда приложения используя (. net, node, et c), но если вы используете. NET необходимо выполнить следующие действия: (а) установить промежуточное ПО в ваше веб-приложение, (б) установить промежуточное ПО в ваше приложение API. и (c) убедитесь, что вызовы из вашего веб-приложения в приложение API передают id_token.

Если вам, в дополнение к этому, необходимо защитить его для внешних пользователей - он должен работать так же , Единственное отличие состоит в том, что они будут вручную вызывать конечную точку / authorize, чтобы получить свой токен, но промежуточное программное обеспечение должно позаботиться о проверке токена для вас в обоих случаях.

Примечание. Я столкнулся с одной странной вещью: необходимо передать id_token и , а не access_token. Стоит также упомянуть, что заявки были истолкованы по-разному в приложении и API (в том смысле, что названия заявок, скажем, userid, отличались между ними - данные были все те же).