How can I use client attributes when using Event Grid Topic Spaces and authorization using Entra ID (JWT)?

Hello Anouk,

When using Microsoft Entra ID (JWT-based authentication) with Event Grid Topic Spaces, the behavior is a bit different compared to certificate-based authentication. Specifically, client.attributes are not available when authenticating via JWT tokens, so you won’t be able to attach attributes (like enterprise or site) directly to the app registration and reference them in topic templates.

What can be done instead?

With JWT authentication, Event Grid evaluates claims present in the token. So the recommended approach is to move from client.attributes to token claims.

Recommended approach: Use custom JWT claims

You can include attributes such as enterprise and site as claims in the access token, and then reference them in your Topic Space templates.

High-level steps:

Configure your app registration (or token issuance process) to include custom claims such as:

enterprise

site

Ensure these claims are present in the JWT token obtained via the client credentials flow.

Update your Topic Space template to use claims instead of attributes, for example:

${client.claims.enterprise}/${client.claims.site}/+/+

This achieves the same logical isolation you had before, ensuring each client can only publish/subscribe within its own enterprise/site scope.

Alternative options (if claims are not feasible)

Per-tenant app registrations:

You could create separate app registrations per enterprise/site and structure topic templates using the client ID. This is simpler but may not scale well.

RBAC alone is not sufficient:

While roles like EventGrid TopicSpaces Publisher/Subscriber allow clients to connect, they do not restrict access to specific topics. Topic-level isolation must still be enforced via templates.

Summary

client.attributes are only available with certificate-based authentication, not with JWT.

With Entra ID, claims in the token are the correct mechanism for passing tenant-specific context.

The recommended design is to include enterprise/site as claims and use them in Topic Space templates.

Please accept as answer and do a Thumbs-up to upvote this response if you are satisfied with the community help. Your upvote will be beneficial for the community users facing similar issues.

With Microsoft Entra ID (JWT) authentication for Event Grid MQTT, client attributes are not taken from the app registration or Azure AD object. Instead, they come from either:

1. Claims in a custom OAuth 2.0 JWT (non‑Entra ID), or
2. Attributes returned by a custom webhook authenticator.

With pure Entra ID + Azure RBAC (EventGrid TopicSpaces Publisher/Subscriber roles), there is no built‑in way to attach arbitrary attributes like enterprise or site to the client identity and have them appear as client.attributes.* for topic templates.

To re‑create the behavior used with certificate‑based clients (for example, ${client.attributes.enterprise}/${client.attributes.site}/+/+), use one of the flexible authentication options instead of (or in addition to) Entra ID RBAC:

Option 1: OAuth 2.0 JWT with custom claims

1. Configure OAuth 2.0 JWT authentication on the Event Grid namespace (Key Vault or direct upload of public keys).
2. Have the identity provider issue JWTs that include claims such as enterprise and site with supported types:
   • string
   • int32
   • array of strings
3. Event Grid maps all non‑standard claims of these types to client attributes. For example, a token like:

      {
        "iss": "https://idp.example.com/",
        "sub": "client-123",
        "aud": ["<namespace-hostname>", "other-audience"],
        "exp": 1735689600,
        "nbf": 1735686000,
        "enterprise": "contoso",
        "site": "plant-01"
      }
   

   results in:
   • client.attributes.enterprise = "contoso"
   • client.attributes.site = "plant-01"
4. Topic templates can then safely use:
   • ${client.attributes.enterprise}/${client.attributes.site}/+/+

Key points from the configuration:

• Standard claims iss, sub, aud, exp, nbf are not mapped to attributes.
• All other claims with type int32, string, or array of strings are mapped to client attributes.

Option 2: Custom webhook authentication

If Entra ID must remain the primary identity source, use custom webhook authentication:

1. Configure the namespace to use custom webhook authentication.
2. When a client connects, Event Grid calls the webhook with connection details (including Entra ID token if used).
3. The webhook decides whether to allow the connection and returns:

      {
        "decision": "allow",
        "clientAuthenticationName": "client-123",
        "attributes": {
          "enterprise": "contoso",
          "site": "plant-01"
        },
        "expiration": 1735689600
      }
   

4. The attributes dictionary is turned into client attributes, again available as client.attributes.enterprise and client.attributes.site in topic templates and client group queries.

Supported attribute types are the same as for JWT claims: int32, string, array of strings.

Summary for the described scenario

• Entra ID + RBAC alone cannot provide client.attributes.enterprise / site for topic templates.
• To enforce per‑enterprise topic isolation via ${client.attributes.*}:
  • Use OAuth 2.0 JWT authentication and put enterprise/site in custom claims, or
  • Use custom webhook authentication and return attributes in the webhook response.

This preserves the same pattern used with certificate‑based clients while using token‑based or webhook‑based authentication.

References:

• Microsoft Entra JWT authentication and Azure RBAC authorization to publish or subscribe MQTT messages
• OAuth 2.0 JSON Web Token (JWT) authentication and authorization to publish or subscribe to MQTT messages
• Client authentication
• Overview of the MQTT broker feature in Azure Event Grid
• Use OAuth 2.0 JSON Web Tokens (JWT) to authenticate with namespaces
• MQTT clients
• Authenticate with the MQTT broker by using custom webhook authentication