Да, вы можете сделать это.
Примечание. Я предполагаю, что ваш API защищен Azure AD, и что для вызова вашего API пользователи должны войти в клиент вашего APIс Azure AD.
Допустим, вы хотели, чтобы ваш API отправлял запросы не только в DevOps Azure, но и в Microsoft Graph (например, другой API, защищенный Azure AD - это может быть любойдругой API, включая второй собственный API), и что вы хотите, чтобы эти запросы выполнялись от имени вошедшего в систему пользователя.То есть от имени пользователя, который идентифицирован в токене доступа, полученном API.
Вы можете сделать следующее (диаграмма ниже):
- Пользователь входит в систему с помощьюAzure AD для клиентского приложения, а клиентское приложение запрашивает токен доступа для вашего API.
- Клиентское приложение представляет этот токен доступа вашему API при выполнении любых запросов API (например, в заголовке авторизации), а такжеAPI выполняет все необходимые проверки.
- Ваш API-интерфейс берет полученный токен доступа и представляет его Azure AD, запрашивая новый токен доступа "от имени" вошедшего в систему пользователя.из представленного токена доступа, но для другого ресурса: Azure DevOps.При условии наличия всех необходимых разрешений и разрешений Azure AD отвечает API-интерфейсом с токеном доступа для DevOps Azure.
- API представляет этот токен доступа при выполнении запросов к DevOps Azure.
- Ваш API также хочет вызвать Microsoft Graph (например, чтобы получить более подробную информацию о пользователе или отправить электронное письмо или что-то в этом роде), поэтому API снова отправляется в Azure AD, представляя маркер доступа, полученный в (2), и запрашиваеттокен для Microsoft Graph.Если согласие и разрешения проверяются, Azure AD соответствует.
- Ваш API использует этот третий токен доступа при отправке запросов в Microsoft Graph.
+--------+ +-----------+ +-----------------+
(User)+---> +-(2)--> +-(4)---> |
| Client | | Your API <-------+ Azure DevOps |
| <------+ | | |
+----^---+ | +-(6)+ +-----------------+
| | | <--+ |
| | +---^----^--+ | | +-----------------+
(1) (3) (5) | +--> |
| | || || +----+ Microsoft Graph |
| | +--v----v--+ | (or other API) |
| +--------> | | |
| | Azure AD | +-----------------+
+----------+ |
+----------+
Подробный поток токенов описан вдокументация по Azure AD (как для конечной точки v1 , так и для конечной точки v2 ).
Разумеется, все сложности, а также кэширование и обновление токенов должны обрабатываться простыми библиотеками, такими как ADAL или MSAL, каждая из которых имеет вики-страницы для потока от имени ( с ADAL , с MSAL ).Вот краткий пример того, как это выглядит с ADAL (взято из To
// Use ADAL to get a token On Behalf Of the current user. To do this we will need:
// The Resource ID of the service we want to call.
// The current user's access token, from the current request's authorization header.
// The credentials of this application.
// The username of the user calling the API
//
string resourceId = "499b84ac-1321-427f-aa17-267ca6975798"; // this is the Azure DevOps app ID
string userName = "...";// get from incoming token
string userAccessToken = "..." // from incoming Authorization header;
UserAssertion userAssertion = new UserAssertion(userAccessToken, "urn:ietf:params:oauth:grant-type:jwt-bearer", userName);
ClientCredential clientCred = new ClientCredential(clientId, appKey);
AuthenticationContext authContext = new AuthenticationContext(authority, tokenCache);
// Now make the on-behalf-of request
result = await authContext.AcquireTokenAsync(resourceId, clientCred, userAssertion);
accessToken = result.AccessToken; // <-- this is a token for Azure DevOps!