Closed garchiro7 closed 2 years ago
scheduled for 5/12 9-11am pst
For clarity, can we not mix async/await and then
such as the following?
async function getCommunicationTokenForTeamsUser() {
// Acquire a token with a custom scope for Contoso's 3P AAD app
let apiAccessToken = await acquireAadToken({ scopes: ["api://1875691f-131f-4802-95a5-4511bde1408e/Contoso.CustomScope"] })
// Acquire a token with a delegated permission Teams.ManageCalls for CTE's 1P AAD app
let teamsUserAccessToken = await acquireAadToken({ scopes: ["https://auth.msft.communication.azure.com/Teams.ManageCalls"] });
// Call your API with token
if (apiAccessToken !== null && teamsUserAccessToken !== null) {
try {
const response = await fetch("/exchange", {
method: "POST",
// Use API access token for authentication
headers: [["Authorization", `Bearer ${apiAccessToken}`], ["Content-Type", "application/json"]],
// Use Teams user access token as payload
body: JSON.stringify({ accessToken: teamsUserAccessToken })
});
const json = await response.json();
if (json) {
logMessage(JSON.stringify(json));
}
catch (error) {
console.log(error);
}
}
@mpodwysocki absolutely, the code was grabbed from my dirty PoC which I just started converting to async/await for better readability. we'll take your comment into consideration when polishing the final samples. thanks for pointing it out!
all api views approved & PRs merged
Metadata
Service team responsible for the client library:
Responsible:
Name of the client library:
Docs:
Timeline:
Link to the service REST APIs:
API Views
Changes
Compared to Public Preview, we're adding two parameters to the
getTokenForTeamsUser()
method. On top of existingtoken
parameter, we are adding two new parameters -appId
anduserId
allowing Contoso to specify the AAD user and app that are allowed to perform the token exchange.Problem definition
Contoso sends a PFT token obtained on the side of their user to ACS Auth. Because the PFT is encrypted, Contoso can’t verify its content and confirm that it belongs to their AAD app registration. It would be possible that a malicious actor could use an access token issued for a different 3P app or a different user which poses two main concerns:
Billing - Contoso is billed if a skypetoken minted for them is used in ACS. Without the validation, Contoso may think they pay for Alice who asked for the skypetoken, however they may unintentionally pay for Betty for whom the AAD token has been issued.
Problem mitigation
Adding the following two parameters to the endpoint so that ACS Auth service can verify them:
oid
retrieved from the bearer token (both access tokens and ID tokens containoid
) sent as an authorization headerChampion scenarios
This is the code representation of the scheme above:
CLIENT:
SERVER:
Sample apps
GH repo: https://github.com/petrsvihlik/azure-communication-identity-cte-samples