Нужен шаблон проектирования API, в котором я могу предоставить один и тот же API для фонового процесса и конечных клиентов
Наши API используются сторонними приложениями deamon, а также клиентскими приложениями. Для стороннего приложения deamon мы можем предоставить API через поток oauth учетных данных клиента, а для клиентского приложения (S) мы используем поток неявного предоставления.
Проблема, с которой мы сталкиваемся, состоит в том, что в случае неявного потока предоставления пользовательские данные извлекаются из ACKESS TOKEN. Но когда тот же API-интерфейс используется для потока учетных данных клиента, пользовательские данные не могут быть получены из токена ACCESS, так как он содержит только специфические данные приложения.
Каков наилучший подход к разработке API для решения вышеуказанной проблемы? Нужны ли мне два набора API, один для интеграции с клиентским приложением и один для интеграции с серверным приложением? Поможет ли использование какого-либо альтернативного потока oauth?
1 ответ
Обратитесь к сценариям аутентификации для документации Azure AD, поскольку вы правильно указали, что взаимодействие с пользователем невозможно с приложением-демоном, для которого требуется, чтобы приложение имело свою собственную идентификацию. Приложение такого типа запрашивает токен доступа, используя его идентификатор приложения и представляя свой идентификатор приложения, учетные данные (пароль или сертификат) и идентификатор URI идентификатора приложения в Azure AD. После успешной аутентификации демон получает токен доступа от Azure AD, который затем используется для вызова веб-API.
Наиболее существенное предоставление кода авторизации OAuth2 - это разрешение авторизации, которое использует две отдельные конечные точки. Конечная точка авторизации используется на этапе взаимодействия с пользователем, что приводит к коду авторизации. Конечная точка токена затем используется клиентом для обмена кода на токен доступа, а также часто токен обновления. Веб-приложения должны представлять свои собственные учетные данные приложения конечной точке токена, чтобы сервер авторизации мог аутентифицировать клиента.
Следовательно, рекомендуется использовать две версии API, реализованные с двумя разными типами аутентификации в зависимости от вашего сценария.
Ссылка -
Демон или серверное приложение к веб-API
Понимание потока неявного предоставления OAuth2 в Azure Active Directory (AD)