Oauth 2.0 authenticated Azure Monitor to ITOM Health (Event Management) Integration

[RemcoLengers]

This post describes OAUTH 2.0 authentication method to integrate Azure Monitor into ServiceNow ITOM Event Management. 

In <this> blog I explained the simplest method to integrated Azure Monitor. However using Oauth 2.0 is considered to be more secure as the credentials are not transmitted with each REST call, only the temporary token which gets regularly renewed. The official documentation can be found <here>.

The high level steps are:

1. Configure an "App Registration" in Azure

2. Create an Integration User in ServiceNow

3. Configure "Azure OAuth Config" in ServiceNow

4. Setup an Azure Event integration in the "Service Operations Workspace", "Integration Launch pad"

5. Configure the "Action Group" in Azure Monitor and test the integration

Oauth 2.0 can use v1 and v2  tokens so depending on which one you need to use the procedure is the same but the data entered has slight variations.

The screenshots are with v1 tokens, the changes needed for v2 tokens are pointed out in the text but are summarised below for clarity.

There are 4 places in the configuration process where there are differences 

- Manifest file "accessTokenAcceptedVersion" (null, 1 (v1) or 2 (v2))

- Application string to use  "Application ID URI" (v1)  or  "Application (client) ID" (v2)

- Remove "v2.0" from the  "OIDC Metadata URL" when using v1 tokens

- Claim name to use appid (v1) or azp (v2)

Configure an "App Registration" in Azure

Create a new App in "App registrations"

Add an "Application ID URI" 

Add and Save

This will have the following result:

For V1 tokens copy the "Application ID URI" field.

For V2 tokens copy the "Application (client) ID" field. 

From the "Endpoints" copy the "OpenID Connect metadata document" :

In the "App registration" "Manifest" file the "accessTokenAcceptedVersion": null," or 1 is correct for v1 tokens. For v2 tokens use 2. 

UDPATE: There seems to be a recent change in the Manifest file. Here is an example of the parameter "

"requestedAccessTokenVersion": 2," that need to be changed (In this case 2 for v2 tokens)

You may need to add yourself as the owner of the App registration so it will show up in the Action Group at the end later.

Create an Integration User in ServiceNow

Go to "User Administration - Users" and

1. create a new user and

2 assign the "evt_mgmt_integration" role.

3. Add the "Source" Field to the form and copy the V1 "Application ID URI". For v2 tokens use  "Application (client) ID" 

So the result looks like

Config "Azure OAuth Config" in ServiceNow

In the ServiceNow instance goto "Azure Oauth Config"

And edit the existing "Azure OAuth OIDC Entity"

Step 1 Update the "Client ID" with  the V1 "Application ID URI" and Save.  For V2 tokens use the "Application (client) ID" in the "Client ID" field.

Step 2 Open the record with the label "OAuth OIDC Provider Configuration" and edit the record to enter the "OpenID Connect metadata document" data in the "OIDC Metadata URL" field. Note for v1 tokens remove the "v2.0" part from the URL:

And Save.

Final configuration on the same record is the "JWT Claim Validations". for V1 tokens the claim name needs to be "appid" and for v2 tokens it needs to be "azp" which is the default.

Setup an Azure Event integration in the "Service Operations Workspace", "Integration Launch pad".

Give the integration a name

Save and activate and copy the URL.

Configure the "Action Group" in Azure Monitor and test the integration

Goto Monitor, Alerts and then "Action Groups". Edit and existing action group or create a new one.

And "Edit"

In "Actions" add a line with a "Secure Webhook". Use the correct Object ID (App registration) and the URI needs to be the URL you collected from the Integration Launch Pad -  Azure Event Integration. 

Then select "Test action group"

And if all is well:

See the Event show up in the Event Management Integration. Nice!

If you think this is helpful and it is worth investing time in writing these blog posts click the "ThumbsUp" button.

[Harshal16]

Great documentation and very helpful. 

I missed the point of where and how sys user is being used in the authentication flow.  Can someone please share the authentication flow to understand this?  

Thanks

[RemcoLengers]

In general this link explains the cycle well @Harshal16 

https://learn.microsoft.com/en-us/entra/architecture/auth-oauth2

[AllenZ83]

In the section "Create an Integration User in ServiceNow" we created a new user for the integration with a "source" field with value of the "Application ID URI" (we use V1).

But how does the ActionGroup's secure webhook call link to this user? Or how is this new user linked to this integration? At the moment it just looks like a new user that links to nothing.

[AllenZ83]

Also where does the "claim value" 461exxx come from?

[RemcoLengers]

@AllenZ83 I toyed around with an LLM to generate readable answer Oauth can be a bit hard to wrap your head around (it took me a while):

When you use Azure Monitor Action Groups → Secure Webhook, the POST that lands on your ServiceNow Azure-events endpoint carries a Microsoft Entra (Azure AD)-issued JWT access token. ServiceNow doesn’t “bind” the Action Group to a user by name; instead it derives the user at request time from the token:

1. Token audience → pick the OIDC config

• Azure issues the token with aud = your Application ID URI (V1) or the Application (client) ID (V2).

• In ServiceNow, your OAuth OIDC Entity has “Client ID” set to that same value. That’s how ServiceNow knows which verifier to use to validate the token.

2. Token claim → resolve the “integration user”

• After validation, ServiceNow uses a claim (V1: appid, V2: azp, per current guidance) to locate the correct sys_user and run the endpoint in that user context.

• That’s why you populated the Source field on the integration user with the Application ID URI (V1) or App (client) ID (V2). The inbound Azure-events logic/verification uses that value to resolve the user. In other words, the “link” is indirect via the JWT claims, not a hardcoded username/password.

3. Once the user is resolved, Event Management ingests the payload and attributes the events to that source/user (and enforces roles like evt_mgmt_integration).

So it’s expected that the user you created “looks like it links to nothing” in the UI—the binding happens dynamically when the secure webhook hits the endpoint with a valid token whose aud matches your OIDC entity and whose appid/azp maps to the user via the Source value.

Quick checklist (V1 token path)

• Azure App Registration has an Application ID URI defined; the Action Group’s Secure Webhook uses that app.

• In ServiceNow OAuth OIDC Entity:

  • Client ID = the Application ID URI (V1).

  • OIDC metadata URL points to the Entra tenant (without /v2.0 for V1).

  • JWT claim validation includes appid (V1).

• sys_user (integration user): roles assigned (e.g., evt_mgmt_integration), Web service access only checked, and Source = Application ID URI
  
  On your second question:
  
  

  The claim value comes from your Azure App Registration. It’s the Application (client) ID (or Application ID URI in v1) of your registered app. That’s a fixed identifier at the tenant level.

  • Whether Microsoft Entra emits it under appid (v1 style) or azp (v2 style) depends on which endpoint you’re using and how ServiceNow is configured.

  • But the underlying GUID stays the same because it’s always referring to your app registration.

  That’s why in ServiceNow you only update the claim name if you switch to v2 tokens — the claim value stays the same because your app registration hasn’t changed.
  
  
  

[Harshal16]

Thanks @RemcoLengers , this is a clear and concise explanation of the authentication flow.  Much appreciated!