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

Question

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

Anonymous

Good morning everyone,

I have a question regarding the use of authorization using JWT Tokens to Event Grid Namespace.

I have an app registration for an application which should send and receive messages using MQTT. I have given the app registration the EventGrid TopicSpaces Publisher and EventGrid TopicSpaces subscriber role. The app can connect to the MQTT broker, so that is nice.

However, I previously used MQTT with self-signed certificates where we added some attributes to each client; e.g. the enterprise name and site name. This way, it was possible to ensure that each client application can only subscribe and publish to topics regarding it's own enterprise. Therefore, for the topic templates I used: ${client.attributes.enterprise}/${client.attributes.site}/+/+

Is there any method to attach the enterprise name and site name to the app registration of the client application, so that the topic templates can ensure that one enterprise cannot subscribe to topics of another enterprise? Or is there another method how this could be solved?

For some background; I am using the client-credentials flow to authenticate the application to the event grid namespace.

I hope the description is clear and someone knows how to solve this problem!

Thanks in advance!

Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-04-07T18:14:46.2966667+00:00

Hello Anouk,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

2 answers

Your answer

Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-04-07T18:14:46.2966667+00:00

Hello Anouk,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Answer 1

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:

Claims in a custom OAuth 2.0 JWT (non‑Entra ID), or
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

Configure OAuth 2.0 JWT authentication on the Event Grid namespace (Key Vault or direct upload of public keys).
Have the identity provider issue JWTs that include claims such as enterprise and site with supported types:
- string
- int32
- array of strings

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"

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:

Configure the namespace to use custom webhook authentication.
When a client connects, Event Grid calls the webhook with connection details (including Entra ID token if used).

The webhook decides whether to allow the connection and returns:

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

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:

Answer 2

Praveen Kumar Gudipudi 2,295 Microsoft External Staff Moderator

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.

Anonymous

2026-03-23T10:52:55.8166667+00:00

Thank you for your quick answer!

I have looked into topic claims, but I was not able to add custom claims to the token. I can only select the pre-configured claims. Do you know how I could add custom claims?
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-03-23T12:41:16.3166667+00:00

What you’re seeing is expected behavior in Microsoft Entra ID.

In the client credentials flow (application-to-application authentication):

Tokens are issued for a service principal (application), not a user.

The Token configuration blade only supports predefined optional claims.

There is no native way to add arbitrary custom claims (like enterprise or site) directly to the access token.

So unlike certificate-based authentication (where client.attributes are available), custom claims cannot be directly configured in Entra ID for app-only tokens.

Recommended approach: Use App Roles as claims

The most practical and supported solution is to use App Roles, which are included in the token as the roles claim.

How to implement:

In your API App Registration:

Navigate to App roles

Define roles that represent your context, for example:

enterpriseA.site1

enterpriseA.site2

enterpriseB.site1

Assign these roles to the client application's service principal.

When the client requests a token, it will include:

"roles": ["enterpriseA.site1"]

You can then use this in your Event Grid Topic Space template:

${client.claims.roles}/+/+

This approach allows you to enforce the same enterprise/site-level isolation you previously achieved using client.attributes.
Anonymous

2026-03-23T14:48:29.7833333+00:00

I have also tried the app roles, but could not get them in my token as well. Do app roles work if you you have 1 app registration or does it only work when it is delegated?

I want that AppReg A also has the app roles of appreg A. So the token contains the app roles given to that application.
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-03-26T12:36:25.4233333+00:00
What you are observing is expected behavior when using application authentication (client-credentials flow) in Microsoft Entra ID.

Why the app roles are not appearing in your token

App roles can appear in application tokens, but only when there is a resource application and a separate client application. In your current scenario, it sounds like AppReg A both defines the app roles and is also requesting the token for itself.

When an application requests a token for its own app registration, Entra ID does not emit its own app roles in the access token. This is because app roles are designed to represent permissions granted to a client application for accessing a resource application (API). Without this resource–client separation, there is no role assignment context for the token issuance.

Therefore, even if the roles are defined in the same app registration, they will not appear in the token when the same application requests the token.

Recommended approach

To have the roles included in the token, you should use two app registrations:

Resource/API App Registration (AppReg A)

Define your App Roles here (for example enterpriseA.site1, enterpriseA.site2, etc.).

Ensure the roles allow "Application" as a member type.

Client Application (AppReg B)

This is the application that authenticates using the client-credentials flow.

Assign the roles

Go to Enterprise Applications → AppReg B → App role assignments.

Assign one of the roles defined in AppReg A.

Request the token for the resource application

When requesting a token, the client should request access to AppReg A, for example:

scope=api://<AppRegA-Application-ID>/.default

grant_type=client_credentials

When the token is issued, the roles claim will then appear in the JWT, for example:

{

"roles": [

"enterpriseA.site1"

]

}

Using this with Event Grid Topic Spaces

Once the role appears in the token, it can be referenced when authorizing MQTT clients in Azure Event Grid Topic Spaces using the claim value, for example:

${client.claims.roles}/+/+

This allows you to enforce topic isolation such as:

enterpriseA.site1/device1/telemetry
Anonymous

2026-03-27T13:10:39.3233333+00:00
Thank you again for your response. I've tested your suggestion, but I'm encountering a scope conflict that's preventing the solution from working as expected.

The issue is that MQTT authentication requires the scope https://eventgrid.azure.net/.default to function properly. However, when using this scope, the resulting token doesn't include the application roles that are essential for client authorization.

To obtain app roles in the token, I need to use the scope api://<app-id>/.default instead. This creates a catch-22 situation:

Using https://eventgrid.azure.net/.default enables MQTT authentication but excludes app roles

Using api://<app-id>/.default includes app roles but breaks MQTT authentication

Since the app roles are required for authorizing clients, neither scope configuration alone provides a complete solution. Do you have any suggestions for how to obtain both MQTT authentication capability and app roles within the same token, or would an alternative authorization approach be more appropriate here?
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-04-02T15:20:25.85+00:00

Hello Anouk,

Because MQTT authentication in Azure Event Grid requires the https://eventgrid.azure.net/.default scope, custom app roles from another resource cannot be included in the same token. The recommended approach is to base authorization on existing JWT claims (such as azp / client ID) or use separate app registrations or client groups for tenant isolation.