Authorize access with Azure Active Directory for Azure SignalR Service
Azure SignalR Service supports Azure Active Directory (Azure AD) to authorize requests to SignalR resources. With Azure AD, you can use role-based access control (RBAC) to grant permissions to a security principal. The security principal is authenticated by Azure AD, which returns an OAuth 2.0 token. The token is used to authorize a request against the SignalR resource.
Authorizing requests against SignalR with Azure AD provides superior security and ease of use over Access Key authorization. It's recommended using Azure AD authorization with your SignalR resources when possible to assure access with minimum required privileges.
 security principal: a user/resource group, an application, or a service principal such as system-assigned identities and user-assigned identities.
Overview of Azure AD for SignalR
When a security principal attempts to access a SignalR resource, the request must be authorized. With Azure AD, access to a resource requires 2 steps.
- The security principal has to be authenticated by Azure, who will return an OAuth 2.0 token.
- The token is passed as part of a request to the SignalR resource to authorize access to the resource.
Client-side authentication while using Azure AD
When using Access Key, the key is shared between your app server (or Function App) and the SignalR resource. The SignalR service authenticates the client connection request with the shared key.
Using Azure AD there is no shared key. Instead SignalR uses a temporary access key to sign tokens for client connections. The workflow contains four steps.
- The security principal requires an OAuth 2.0 token from Azure to authenticate itself.
- The security principal calls SignalR Auth API to get a temporary access key.
- The security principal signs a client token with the temporary access key for client connections during negotiation.
- The client uses the client token to connect to Azure SignalR resources.
The temporary access key expires in 90 minutes. It's recommend getting a new one and rotate the old one once an hour.
The workflow is built in the Azure SignalR SDK for app server.
Assign Azure roles for access rights
Azure Active Directory (Azure AD) authorizes access rights to secured resources through Azure role-based access control. Azure SignalR defines a set of Azure built-in roles that encompass common sets of permissions used to access SignalR resources. You can also define custom roles for access to SignalR resources.
You may have to determine the scope of access that the security principal should have before you assign any Azure RBAC role to a security principal. It is recommended to only grant the narrowest possible scope. Azure RBAC roles defined at a broader scope are inherited by the resources beneath them.
You can scope access to Azure SignalR resources at the following levels, beginning with the narrowest scope:
|An individual resource.||Applies to only the target resource.|
|A resource group.||Applies to all of the resources in a resource group.|
|A subscription.||Applies to all of the resources in a subscription.|
|A management group.||Applies to all of the resources in the subscriptions included in a management group.|
Azure built-in roles for SignalR resources
|SignalR App Server||Access to Websocket connection creation API and Auth APIs.||Most commonly for an App Server.|
|SignalR Service Owner||Full access to all data-plane APIs, including REST APIs, WebSocket connection creation API and Auth APIs.||Use for Serverless mode for Authorization with Azure AD since it requires both REST APIs permissions and Auth API permissions.|
|SignalR REST API Owner||Full access to data-plane REST APIs.||Often used to write a tool that manages connections and groups but does NOT make connections or call Auth APIs.|
|SignalR REST API Reader||Read-only access to data-plane REST APIs.||Commonly used to write a monitoring tool that calls ONLY SignalR data-plane READONLY REST APIs.|
To learn how to create an Azure application and use Azure AD Auth, see:
To learn how to configure a managed identity and use Azure AD Auth, see:
To learn more about roles and role assignments, see:
To learn how to create custom roles, see:
Submit and view feedback for