Как получить доступ к API с помощью токена доступа Azure, полученного при входе в систему?

Question

Мой интерфейс использует OAuth2 Azure AD. При входе в систему это разрешает и получает токен доступа и id_token, которые я отправляю на сервер с каждым запросом, который затем я могу проверить (на сервере).

Проблема в том, что теперь у меня есть сервер API Rest Azure. Этот API используется моим сервером.

Как использовать этот API? Я читал о потоке от имени или генерировал сертификат для сервера. Или я должен использовать тот же токен доступа, который был предоставлен моему внешнему интерфейсу на моем сервере?

Answer 1

Давайте рассмотрим различные варианты:

1. Поток от имени
2. Поток учетных данных клиента
3. Использовать тот же токен

Основная причина использования «от имени» - сохранить пользовательский контекст в токене. Это позволит другому API применять авторизацию на основе идентификатора пользователя. Если это то, что вам нужно и полезно для вас, определенно go с «от имени». Недостатком является необходимость кэширования токенов для каждого пользователя на вашем сервере. Вам также необходимо убедиться, что согласие пользователя / администратора сделано для этого API перед вызовом, так как в противном случае вы получите ошибку.

Поток учетных данных клиента может использоваться с секретом клиента или сертификатом , Его проще использовать, чем от имени, но он теряет пользовательский контекст. Маркер будет содержать только информацию о вашем приложении. Если API, который вы вызываете, является тем, который вы создали, обязательно укажите хотя бы одно разрешение приложения . В настоящее время это необходимо сделать через манифест приложения (appRoles) на портале или через PowerShell. Затем вы можете назначить эти разрешения для вашего фонового приложения в AAD и получать токен, когда вам это нужно. Не требуется отдельного согласия пользователя, и кэш токена в памяти, вероятно, будет работать довольно хорошо. Преимущество здесь в простоте.

Использование того же токена, который получает ваш API, обычно не очень хорошая идея. Например, вы можете захотеть определить делегированные / прикладные права / роли пользователя для вашего API. Это, скорее всего, не тот, который другой API будет использовать. Это определенно самый простой вариант, но в большинстве случаев я бы его не рекомендовал.