Web PubSub: GenerateClientAccessURL generates invalid tokens

[alexg-axis]

Bug Report

• import path of package in question: github.com/Azure/azure-sdk-for-go/sdk/messaging/azwebpubsub
• SDK version: 0.1.1
• output of go version: go version go1.26.6 darwin/arm64

• What happened?

The SDK incorrectly sets the audience of the JWT to a host using the same scheme as the HTTP API (i.e. http or https). This yields JWTs that are rejected by the server. The expected scheme for the audience field is wss. This has essentially made the SDK unusable for generating client access URLs since its conception.

azure-sdk-for-go/sdk/messaging/azwebpubsub/client_custom.go

Lines 122 to 129 in 48df4ea

	audience := fmt.Sprintf("%sclient/hubs/%s", parsedURL.String(), hubPath)
	parsedURL.Scheme = strings.Replace(strings.ToLower(parsedURL.Scheme), "http", "ws", 1)
	baseURL := fmt.Sprintf("%sclient/hubs/%s", parsedURL.String(), hubPath)
	var token string
	if c.key != nil {
	token, err = c.signJwtToken(audience, options)

• What did you expect or want to happen?

The SDK should generate tokens and URLs that work with a WebSocket client without the server returning 401 Forbidden. The clients using a token or URL should be able to connect successfully.

• How can we reproduce it?

Just test using GenerateClientAccessURL. It will return a JWT with an aud set to https://... when it should be wss. This can be confirmed by connecting to a server, which will reject the request.

• Anything we should know about your environment.

Web PubSub Service SKU Premium P1, version 1.0.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

Generated by Agentic Triage for #27414 · 26.9 AIC · ⌖ 6.83 AIC · ⊞ 9.2K · ◷

[github-actions]

🎯 Agentic Issue Triage

Summary: The GenerateClientAccessURL function in sdk/messaging/azwebpubsub generates JWTs with the audience (aud) claim set to (redacted) instead of `(redacted) causing the server to reject client connections with 401 Forbidden.

📋 Issue Details

Module: github.com/Azure/azure-sdk-for-go/sdk/messaging/azwebpubsub
Affected API: GenerateClientAccessURL (in client_custom.go lines 122-129)
Scenarios:

• Calling GenerateClientAccessURL returns a JWT whose aud claim uses https:// scheme instead of `(redacted)
• WebSocket clients connecting with the generated URL/token receive 401 Forbidden from the server

Root ask: Fix the audience claim scheme in the JWT from https:// to `(redacted) so generated tokens and URLs work with WebSocket clients.

🔎 Debugging / Reproduction Notes

The author pinpointed the specific code location: client_custom.go lines 122–129. The URL construction for the JWT audience uses the HTTP scheme (http/https) rather than the WebSocket scheme (wss). This is a straightforward scheme replacement bug.

Suggested investigation steps:

1. Review client_custom.go lines 122–129 to confirm how the audience URL is constructed.
2. Change the scheme used in the audience from https:// to (redacted) (and (redacted) to `(redacted) for non-TLS endpoints if applicable).
3. Write a unit test asserting the aud claim scheme in the output of GenerateClientAccessURL.
4. Verify against the Web PubSub service that the corrected token is accepted by a WebSocket client.

🏷️ Label Confidence

• Category: Client — The issue is in the Go SDK module sdk/messaging/azwebpubsub, which is not under sdk/resourcemanager/. This is an SDK code defect.
• Service: WebPubSub — The import path explicitly references azwebpubsub; the CODEOWNERS file confirms %WebPubSub for this path.
• Confidence: High — The module path is unambiguous, the category and service labels are clearly implied.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %WebPubSub (line 147) — matched because the predicted label WebPubSub aligns with the issue's module path /sdk/messaging/azwebpubsub/.
• AzureSdkOwners: @vicancy
• ServiceOwners: @chenkennt Joel Hendrix (@jhendrixMSFT) @vicancy``
• Routing action: Assigned @vicancy (single AzureSdkOwner); added needs-team-attention label.
• Scan notes: Scanned bottom-to-top; the %WebPubSub entry (line 147) was the first match. No other entries were relevant.

Generated by Agentic Triage for #27414 · 26.9 AIC · ⌖ 6.83 AIC · ⊞ 9.2K · ◷

[vicancy]

Thanks for the detailed report and for pinpointing the exact lines — but I don't think the diagnosis is correct. The scheme of the aud claim isn't what's failing here.

The service does not validate the scheme of aud

I tested this directly against a live Web PubSub resource (Premium P1, 1.0) by sending raw WebSocket upgrade requests with hand-signed HS256 tokens that differ only in the aud claim:

aud claim	Result
https://<host>/client/hubs/chat	101 Switching Protocols
wss://<host>/client/hubs/chat	101 Switching Protocols
http://<host>/client/hubs/chat	101 Switching Protocols
https://<host>client/hubs/chat (missing /)	401
https://<host>/client/hubs/otherhub (wrong hub)	401
https://other-resource.webpubsub.azure.com/client/hubs/chat (wrong host)	401

The service normalizes the scheme and validates the host and path. An https:// audience is accepted; a wss:// audience is also accepted. So this is not a https vs wss problem.

This is also the intended, consistent design across every Azure SDK language — all of them put the HTTP(S) endpoint in aud and only switch the returned URL to ws(s):

• .NET — WebPubSubServiceClient_helpers.cs (there is even a test asserting aud == "http://localhost:8080/client/hubs/hub")
• JavaScript — hubClient.ts (const audience = endpoint + clientPath)
• Python — _operations/_patch.py (audience = endpoint + path + hub)
• Java — WebPubSubServiceAsyncClient.java

Finally, I ran the exact algorithm from client_custom.go (the connection-string path) end to end against a real resource, and the URL it produces connects successfully:

aud claim : https://<host>/client/hubs/chat
client URL: wss://<host>/client/hubs/chat
RESULT: 101 Switching Protocols

So GenerateClientAccessURL via NewClientFromConnectionString does work today.

What would actually cause your 401

A 401 on the client connection means the aud host or path doesn't match the URL being connected to. To help narrow it down, could you share:

1. The decoded aud claim from a token that gets rejected
2. The exact URL your WebSocket client connects to
3. Whether you construct the client with NewClientFromConnectionString or NewClient (Entra ID)
4. Whether a custom domain, replica, or reverse proxy is involved

Your report did surface two real bugs — thank you

Both are in the NewClient (Entra ID / TokenCredential) path, and I'm putting up a PR for them:

1. Missing trailing-slash normalization. ParseConnectionString appends a trailing / to the endpoint, but NewClient stores the endpoint as-is. So NewClient("https://<name>.webpubsub.azure.com", cred, nil) (no trailing slash — the form the portal and az show) produces a malformed result:
   wss://<name>.webpubsub.azure.comclient/hubs/<hub>
   The other SDKs normalize this inside the token method itself rather than relying on the connection-string parser.

2. Nil-pointer dereference. GenerateClientAccessURL(ctx, hub, nil) panics on the Entra ID path, because options.UserID is read without a nil check. The key-based path handles nil options correctly.

If you're using NewClient with an endpoint that has no trailing slash, bug #1 is the most likely explanation for what you're seeing.

[alexg-axis]

Thanks for taking a look!

I have already seen the issue with the non-normalized trailing slash and worked around it. Here's the decoded contents of a token that works (not generated using the SDK):

{
  "alg": "HS256",
  "typ": "JWT"
}
{
  "aud": "wss://xxx.webpubsub.azure.com/client/hubs/notifications",
  "exp": 1787214951,
  "iat": 1787214651,
  "role": [],
  "webpubsub.group": [
    // ...
  ]
}

Here's one that doesn't (generated using the SDK):

{
  "alg": "HS256",
  "kid": "s-d1e769a4-a675-49f6-80b7-000bae05eaa5",
  "typ": "JWT"
}
{
  "aud": "https://xxx.webpubsub.azure.com/client/hubs/notifications",
  "exp": 1787215140,
  "iat": 1787214840,
  "nbf": 1787214840,
  "iss": "https://webpubsub.azure.com",
  "webpubsub.group": [
    // ...
  ]
}

So the normalization of the audience is not a concern as they're both identical apart from the scheme.

The code that generates working JWTs generates them using the key from the connection strings. The SDK path we use (using a workload identity using a user-assigned managed identity) will use the generate token API of the hub. That's the big difference.

The user-assigned managed identity is granted the following actions:

Microsoft.SignalRService/WebPubSub/clientConnection/generateToken/action
Microsoft.SignalRService/SignalR/clientConnection/write

Without the generateToken action, the server will get a 403 from the service, which is expected.

We have not had any issues with the User option causing panics.