You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/communication-services/concepts/identity-model.md
+37-19Lines changed: 37 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,15 +32,15 @@ After a user identity is created, a user is granted with the capability to parti
32
32
|---|----|
33
33
|Identity|Uniquely identifies a token|
34
34
|Expiration|An access token is valid for a period of time between 1 and 24 hours. After it expires, the access token is invalidated and can't be used to access any primitive. To generate a token with a custom validity, specify the desired validity period when generating the token. If no custom validity is specified, the token will be valid for 24 hours. We recommend using short lifetime tokens for one-off meetings and longer lifetime tokens for agents using the application for longer periods of time|
35
-
|Scope|The scope parameter defines a nonempty set of primitives (Chat/VoIP) that can be used.
35
+
|Scope|The scope parameter defines a nonempty set of primitives (Chat/VoIP) that can be used.
36
36
37
37
An access token is a JSON Web Token (JWT) and has integrity protection. That is, its claims can't be changed after it's issued. So a manual change of properties such as identity, expiration, or scopes will invalidate the access token. If primitives are used with invalidated tokens, then access will be denied to the primitives. Azure Communication Services supports the following scopes for access tokens.
38
38
39
-
## Chat token scopes
39
+
###Chat token scopes
40
40
Three types of chat token scopes are supported. Permissions for each token are described below.
@@ -60,10 +60,10 @@ Three types of chat token scopes are supported. Permissions for each token are d
60
60
|Send typing indicator | Y | Y | Y |
61
61
|Get participant for thread ID | Y | Y | Y |
62
62
63
-
## VoIP token scopes
63
+
###VoIP token scopes
64
64
Two types of VoIP token scopes are supported. Permissions for each token are described below.
65
-
- voip
66
-
- voip.join
65
+
-`voip`
66
+
-`voip.join`
67
67
68
68
|Capability / Token scope| voip | voip.join |
69
69
|---|---|---|
@@ -74,21 +74,39 @@ Two types of VoIP token scopes are supported. Permissions for each token are des
74
74
|All other in-call operations such as mute/unmute, screen share etc. | Y | Y |
75
75
|All other in-call operations such as mute/unmute, screen share etc. in Virtual Rooms| Determined by user role | Determined by user role |
76
76
77
-
## Revoke or update access token
77
+
You can the use `voip.join` scope together with [Rooms](./rooms/room-concept.md) to create a scheduled call where only invited users get access and where users are prohibited from creating any other calls.
78
+
79
+
### Revoke or update access token
78
80
- Azure Communication Services Identity library can be used to revoke an access token before its expiration time. Token revocation isn't immediate. It can take up to 15 minutes to propagate.
79
-
- The removal of an identity, resource, or subscription revokes all access tokens.
80
-
- If you want to remove a user's ability to access specific functionality, revoke all access tokens. Then issue a new access token that has a more limited set of scopes.
81
+
- The deletion of an identity, resource, or subscription revokes all access tokens.
82
+
- If you want to remove a user's ability to access specific functionality, revoke all access tokens for the user. Then issue a new access token that has a more limited set of scopes.
81
83
- Rotation of access keys revokes all active access tokens that were created by using a former access key. In this case all identities lose access to Azure Communication Services, and they must issue new access tokens.
82
84
83
-
## Considerations
84
-
- We recommend issuing access tokens in your server-side service and not in the client's application. The reasoning is that issuing requires an access key or Microsoft Entra authentication. Sharing secrets with the client's application isn't recommended for security reasons.
85
-
- Client application should use a trusted service endpoint that can authenticate clients. The endpoint should issue access tokens on their behalf. For more information, see [Client and server architecture](./client-and-server-architecture.md).
86
-
- If you cache access tokens to a backing store, we recommend using encryption. An access token is sensitive data. It can be used for malicious activity if it's not protected. Someone who has an access token can start the SDK and access the API. The accessible API is restricted only based on the scopes that the access token has.
87
-
- We recommend issuing access tokens that have only the required scopes.
85
+
## Client-server architecture
86
+
87
+
You should generate and manage user access tokens by using a trusted service and not from your client application. The connection string or Microsoft Entra credentials that are necessary to generate user access tokens need to be protected and passing them to a client would risk leaking the secret. Failure to properly manage access tokens can result in additional charges on your resource when discovered and misused by somebody else.
88
+
89
+
If you cache access tokens to a backing store, we recommend encrypting the tokens. An access token gives access to sensitive data and can be used for malicious activity if it's not protected. Someone who has an access token can access a user's chat data or participate in calls impersonating the user.
90
+
91
+
Make sure to only include those scopes in the token that your client application really needs in order to follow the security principle of least privilege.
92
+
93
+
:::image type="content" source="./media/architecture-identity.png" alt-text="Diagram that shows the user access token architecture." border="false":::
94
+
95
+
1. A user starts the client application.
96
+
1. The client application contacts your identity management service.
97
+
1. The identity management service authenticates the application user. Skip authentication for anonymous user scenarios, but be careful to then add other measures such as throttling and CORS to avoid abuse of your service.
98
+
1. Create or find a Communication Services identity for the user.
99
+
1._Stable identity scenario:_ Your identity management service maintains a mapping between application identities and Communication Services identities. (Application identities include your users and other addressable objects, like services or bots.) If the application identity is new, a new Communication identity is created and a mapping is stored.
100
+
1._Ephemeral identity scenario:_ The identity management service creates a new Communication identity. In this scenario the same user will end up with a different Communication identity for each session.
101
+
1. The identity management service issues a user access token for the applicable identity and returns it to the client application.
102
+
103
+
Azure App Service or Azure Functions are two alternatives for operating the identity management service. These services scale easily and have built-in features to [authenticate](/../../app-service/overview-authentication-authorization.md) users. They're integrated with [OpenID](../../app-service/configure-authentication-provider-openid-connect.md) and third-party identity providers like [Facebook](/../../app-service/configure-authentication-provider-facebook.md).
88
104
89
105
## Next steps
90
106
91
-
*For an introduction to access token management, see [Create and manage access tokens](../quickstarts/identity/access-tokens.md).
107
+
*To learn how to issue tokens, see [Create and manage access tokens](../quickstarts/identity/access-tokens.md).
92
108
* For an introduction to authentication, see [Authenticate to Azure Communication Services](./authentication.md).
93
-
* For an introduction to data residency and privacy, see [Region availability and data residency](./privacy.md).
94
-
* To learn how to quickly create identities for testing, see the [quick-create identity quickstart](../quickstarts/identity/quick-create-identity.md).
109
+
* To read about data residency and privacy, see [Region availability and data residency](./privacy.md).
110
+
* To learn how to quickly create identities and tokens for testing, see the [quick-create identity quickstart](../quickstarts/identity/quick-create-identity.md).
111
+
* For a full sample of a simple identity management service, visit the [Trusted service tutorial](../tutorials/trusted-service-tutorial.md).
112
+
* For a more advanced identity management sample which integrates with Entra ID and Microsoft Graph, head over to [Authentication service hero sample](../samples/trusted-auth-sample.md).
Access tokens enable Azure Communication Services SDKs to [authenticate](../../concepts/authentication.md) directly against Azure Communication Services as a particular identity. You need to create access tokens if you want your users to join a call or chat thread within your application.
20
20
21
-
This article describes how to use the Azure Communication Services SDKs to create identities and manage your access tokens. For production use cases, we recommend that you generate access tokens on a server-side service as described in [Mobile architecture design](../../concepts/client-and-server-architecture.md).
21
+
This article describes how to use the Azure Communication Services SDKs to create identities and manage your access tokens. For production use cases, we recommend that you generate access tokens on a server-side service as described in [Client and server architecture](../../concepts/identity-model#client-services-architecture).
Copy file name to clipboardExpand all lines: articles/communication-services/tutorials/events-playbook.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -108,7 +108,7 @@ Attendee experience can be directly embedded into an application or platform usi
108
108
109
109
2. Before developers dive into using [Azure Communication Services](../overview.md), they must [create a resource](../quickstarts/create-communication-resource.md?pivots=platform-azp&tabs=windows&preserve-view=true).
110
110
111
-
3. Once a resource is created, developers must [generate access tokens](../quickstarts/identity/access-tokens.md?pivots=programming-language-javascript&preserve-view=true) for attendees to access Azure Communication Services. We recommend using a [trusted service architecture](../concepts/client-and-server-architecture.md).
111
+
3. Once a resource is created, developers must [generate access tokens](../quickstarts/identity/access-tokens.md?pivots=programming-language-javascript&preserve-view=true) for attendees to access Azure Communication Services. We recommend using a [trusted service architecture](../concepts/identity-model#client-services-architecture).
112
112
113
113
4. Developers can leverage [headless SDKs](../concepts/teams-interop.md) or [UI Library](../concepts/ui-library/ui-library-overview.md) using the join link URL to join the Teams meeting through [Teams Interoperability](../concepts/teams-interop.md). Details below:
0 commit comments