The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Azure Delegated Permissions <-> ServiceNow OAuth / Outbound Rest Messages

gconway
Tera Contributor

Hi all,

 

we have a catalog item which is pre-populated with data from azure (on-demand). Here is the current flow:
0. User logs on to ServicePortal via SSO (Azure Account / OIDC Identity Provider)

1. User selects a subscription from a dropdown.

2. Catalog Client Script triggers on field change.

3. Client script invokes a Script Include.

4. Script Include runs REST messages to Azure via OAuth. (Graph API/Management API)

5. Azure returns current data (VNets, Subnets, DNS Zones, Peerings, Groups, Managed Identities etc).

6. Script Include returns data to Client Script.

7. Client Script populates form fields with returned data.

This works fine if using client credentials OAuth flow. (although this doesn't scope (full access to all resources) the queries to the users' azure permissions).

But how do I utilize Authorization Code flow, so that queries to Azure resources are scoped by the users' Azure permissions via delegated OAuth 2.0 flow? How can it be done seamlessly? Or do I have to create some kind of redirect to authenticate the user again in azure? (this would be unwanted as it would be bad user experience) 

 

Scopes of the APIs:

openid
profile
email
https://graph.microsoft.com/Application.Read.All
https://graph.microsoft.com/Group.Read.All
https://graph.microsoft.com/User.Read.All
https://graph.microsoft.com/.default

+

https://management.azure.com/.default

 


Thanks for your help in advance. 

We have the Application Registration in Azure setup and also we have received Admin consent after requesting oauth token on the rest message page. 


#yokohama

2 REPLIES 2

Abbas_5
Tera Sage
Tera Sage

Hello @gconway,

 

Azure delegated permissions are used when an application needs to act on behalf of a user, accessing resources the user has permission to, while ServiceNow OAuth and Outbound REST Messages are used for secure communication and data exchange between ServiceNow and other systemsDelegated permissions are essential when user context is required, and OAuth provides a secure way to authenticate and authorize these interactions. 
 
Azure Delegated Permissions: 
  • Purpose:
    Allow an application to access resources (like user data in Azure AD) on behalf of a signed-in user.
  • Mechanism:
    The application obtains an access token that represents the user's permissions, allowing it to interact with APIs that the user has access to.
  • Example:
    An application accessing a user's mailbox in Exchange Online or updating their profile in Azure AD. 
     
ServiceNow OAuth and Outbound REST Messages: 
  • Outbound REST Messages:
    ServiceNow's mechanism for sending requests to external web services. They can be used to interact with any RESTful API, including those in Azure. 
     
  • OAuth 2.0 in ServiceNow:
    A secure way to authenticate and authorize access to external APIs, including those exposed by Azure services. It uses access tokens to avoid transmitting user credentials directly. 
     
  • Integration:
    ServiceNow can leverage OAuth 2.0 to authenticate with Azure services via Outbound REST Messages, enabling secure data exchange. 
     
  • Example:
    ServiceNow sending incident data to an Azure DevOps project using OAuth for authentication. 
     
How they work together:
  1. 1. Authentication:
    ServiceNow can be configured to use OAuth 2.0 when making REST calls to Azure services. 
     
  2. 2. Token Acquisition:
    ServiceNow obtains an access token from Azure AD using OAuth 2.0. 
     
  3. 3. Delegated Permissions:
    If the user context is needed for the interaction (e.g., accessing user-specific data in Azure), the delegated permissions granted to the ServiceNow application in Azure AD will determine what the application can access on behalf of the user. 
     
  4. 4. REST Request:
    ServiceNow uses the access token to authenticate the Outbound REST Message to Azure, allowing it to perform actions within the scope of the granted delegated permissions. 
     
Key differences and considerations: 
  • Azure Delegated Permissions:
    Specific to Azure AD and govern access to resources within the Azure ecosystem on behalf of a user. 
     
  • ServiceNow OAuth:
    A generic authentication framework that can be used with various services and APIs, including those in Azure. 
     
  • Security:
    OAuth provides a more secure way to manage access tokens compared to passing credentials directly in REST requests. 
     
  • Flexibility:
    ServiceNow's Outbound REST Messages offer flexibility to interact with various APIs, while delegated permissions provide granular control over user access within Azure. 
     
In essence, when integrating ServiceNow with Azure services, delegated permissions are used to manage user access within Azure, and OAuth provides the secure mechanism for ServiceNow to authenticate and authorize its interactions with Azure APIs via Outbound REST Messages. 
 
If this is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in future it will be helpful to them.
 
Thanks & Regards,
Abbas Shaik

gconway
Tera Contributor

Hi @Abbas_5 , 

thank you. I'm not sure how this is supposed to resolve my problem. Essentially you are saying:

3. Delegated Permissions:
If the user context is needed for the interaction (e.g., accessing user-specific data in Azure), the delegated permissions granted to the ServiceNow application in Azure AD will determine what the application can access on behalf of the user.

4. REST Request:
ServiceNow uses the access token to authenticate the Outbound REST Message to Azure, allowing it to perform actions within the scope of the granted delegated permissions.

 

There is no access nor refresh token for the user logged in other than mine since I have clicked the Get OAuth Token link under the Rest Message related links section. By logging on with SSO there are no tokens visible in the system.  Can you elaborate further?