Single-tenant and multi-tenant authentication for Teams users

This article gives you insight into the authentication process for single-tenant and multi-tenant, Azure Active Directory (Azure AD) applications. You can use authentication when you build calling experiences for Teams users with the Calling software development kit (SDK) that Azure Communication Services makes available. Use cases in this article also break down individual authentication artifacts.

Case 1: Example of a single-tenant application

The Fabrikam company has built a custom, Teams calling application for internal company use. All Teams users are managed by Azure Active Directory. Access to Azure Communication Services is controlled by Azure role-based access control (Azure RBAC).

A diagram that outlines the authentication process for Fabrikam's calling application for Teams users and its Azure Communication Services resource.

The following sequence diagram details single-tenant authentication.

A sequence diagram that details authentication of Fabrikam Teams users. The client application gets an Azure Communication Services access token for a single tenant Azure A D application.

Before we begin:

  • Alice or her Azure AD administrator needs to give the custom Teams application consent, prior to the first attempt to sign in. Learn more about consent.
  • The Azure Communication Services resource admin needs to grant Alice permission to perform her role. Learn more about Azure RBAC role assignment.

Steps:

  1. Authenticate Alice using Azure Active Directory: Alice is authenticated using a standard OAuth flow with Microsoft Authentication Library (MSAL). If authentication is successful, the client application receives an Azure AD access token, with a value of 'A1' and an Object ID of an Azure AD user. Tokens are outlined later in this article. Authentication from the developer perspective is explored in this quickstart.
  2. Get an access token for Alice: The application for Teams users performs control plane logic, using artifacts 'A1', 'A2' and 'A3'. This produces Azure Communication Services access token 'D' and gives Alice access. This access token can also be used for data plane actions in Azure Communication Services, like Calling. The 'A2' and 'A3' artifacts are expected to be passed along with the artifact 'A1' for validation that the Azure AD Token was issued to the expected user and application and will prevent attackers from using the Azure AD access tokens issued to other applications or other users. For more information on how to get 'A' artifacts, see Receive the Azure AD user token and object ID via the MSAL library and Getting Application ID.
  3. Call Bob: Alice makes a call to Teams user Bob, with Fabrikam's app. The call takes place via the Calling SDK with an Azure Communication Services access token. Learn more about developing custom Teams clients.

Artifacts:

  • Artifact A1
    • Type: Azure AD access token
    • Audience: Azure Communication Services — control plane
    • Source: Fabrikam's Azure AD tenant
    • Permissions: https://auth.msft.communication.azure.com/Teams.ManageCalls, https://auth.msft.communication.azure.com/Teams.ManageChats
  • Artifact A2
    • Type: Object ID of an Azure AD user
    • Source: Fabrikam's Azure AD tenant
  • Artifact A3
    • Type: Azure AD application ID
    • Source: Fabrikam's Azure AD tenant
  • Artifact D
    • Type: Azure Communication Services access token
    • Audience: Azure Communication Services — data plane
    • Azure Communication Services Resource ID: Fabrikam's Azure Communication Services Resource ID

Case 2: Example of a multi-tenant application

The Contoso company has built a custom Teams calling application for external customers. This application uses custom authentication within Contoso's own infrastructure. Contoso uses a connection string to retrieve tokens from Fabrikam's application.

A sequence diagram that demonstrates how the Contoso application authenticates Fabrikam users with Contoso's own Azure Communication Services resource.

The following sequence diagram details multi-tenant authentication.

A sequence diagram that details authentication of Teams users and Azure Communication Services access tokens for multi-tenant Azure AD applications.

Before we begin:

  • Alice or her Azure AD administrator needs to give Contoso's Azure Active Directory application consent before the first attempt to sign in. Learn more about consent.

Steps:

  1. Authenticate Alice using the Fabrikam application: Alice is authenticated through Fabrikam's application. A standard OAuth flow with Microsoft Authentication Library (MSAL) is used. If authentication is successful, the client application, the Contoso app in this case, receives an Azure AD access token with a value of 'A1' and an Object ID of an Azure AD user with a value of 'A2'. Token details are outlined below. Authentication from the developer perspective is explored in this quickstart.
  2. Get an access token for Alice: The Contoso application by using a custom authentication artifact with value 'B' performs authorization logic to decide whether Alice has permission to exchange the Azure AD access token for an Azure Communication Services access token. After successful authorization, the Contoso application performs control plane logic, using artifacts 'A1', 'A2', and 'A3'. This generates Azure Communication Services access token 'D' for Alice within the Contoso application. This access token can be used for data plane actions in Azure Communication Services, like Calling. The 'A2' and 'A3' artifacts are expected to be passed along with the artifact 'A1' for validation that the Azure AD Token was issued to the expected user and application and will prevent attackers from using the Azure AD access tokens issued to other applications or other users. For more information on how to get 'A' artifacts, see Receive the Azure AD user token and object ID via the MSAL library and Getting Application ID.
  3. Call Bob: Alice makes a call to Teams user Bob, with Fabrikam's application. The call takes place via the Calling SDK with an Azure Communication Services access token. Learn more about developing custom, Teams apps in this quickstart.

Artifacts:

  • Artifact A1
    • Type: Azure AD access token
    • Audience: Azure Communication Services — control plane
    • Source: Contoso application registration's Azure AD tenant
    • Permission: https://auth.msft.communication.azure.com/Teams.ManageCalls, https://auth.msft.communication.azure.com/Teams.ManageChats
  • Artifact A2
    • Type: Object ID of an Azure AD user
    • Source: Fabrikam's Azure AD tenant
  • Artifact A3
    • Type: Azure AD application ID
    • Source: Contoso application registration's Azure AD tenant
  • Artifact B
    • Type: Custom Contoso authorization artifact (issued either by Azure AD or a different authorization service)
  • Artifact C
    • Type: Hash-based Message Authentication Code (HMAC) (based on Contoso's connection string)
  • Artifact D
    • Type: Azure Communication Services access token
    • Audience: Azure Communication Services — data plane
    • Azure Communication Services Resource ID: Contoso's Azure Communication Services Resource ID

Next steps

The following sample apps may be interesting to you:

  • Try the Sample App, which showcases a process of acquiring Azure Communication Services access tokens for Teams users in mobile and desktop applications.

  • To see how the Azure Communication Services access tokens for Teams users are acquired in a single-page application, check out a SPA sample app.

  • To learn more about a server implementation of an authentication service for Azure Communication Services check out the Authentication service hero sample.