Azure SignalR service rejecting client requests with 403

Question

I have an Azure SignalR service that is rejecting client connections with a 403.

The hub server (an App Service) is connecting to the Azure SignalR service authenticating with Managed Identity successfully, and is assigned "SignalR App Server" role. These server connections are successful, and i can see them active on the SignalR service metrics.

When then client connects to the messagehub endpoint on the app service, it receives an accessToken:

{     "$id": "1",     "url": "https://sgr-<redacted>.service.signalr.net/message",     "accessToken": "eyJhb...<redacted>" }

The client then sends an HTTP OPTIONS request including the Bearer token in the Authorization header to this url:
https://sgr-<redacted>.service.signalr.net/message/negotiate?negotiateVersion=1

... and receives a 403 response.

Decoding the bearer token doesn't show anything that looks incorrect (exp time is still valid...):

{
  "nbf": 1734692367,
  "exp": 1734695967,
  "iat": 1734692367,
  "aud": "https://sgr-<redacted>.service.signalr.net/client/?hub=messagehub"
}

The Azure signalR service is configured to allow public endpoint.

What else could cause a 403 response to be generated? Im not seeing anything in the SignalR service diagnostic logs for these requests. Is there anywhere else i should be checking?

Thanks

Answer 1

@Peter Cresswell It sounds like you've already done a thorough job troubleshooting your Azure SignalR service setup.

To resolve the 403 issues with your Azure SignalR service, start by ensuring that the Access Control Lists (ACLs) are correctly configured, as misconfigurations can lead to request rejections. Verify that the token's audience (aud) matches the expected URL, since even a minor mismatch can cause a 403 error. Additionally, check the Cross-Origin Resource Sharing (CORS) settings on your Azure SignalR service, as incorrect CORS settings can result in connection issues. Make sure the client is properly configured to use the access token, as problems with how the token is included in the request can lead to authentication failures. Although you mentioned not seeing anything in the SignalR service diagnostic logs, it’s worth double-checking them for any subtle clues and considering enabling more detailed logging if possible. Lastly, ensure that there are no network security groups or firewalls blocking the requests, as network configurations can sometimes inadvertently block traffic.

If these steps don’t resolve the issue, please reply here as I have one final option to look into.