Adding your Microsoft OAuth credentials to Oomnitza

Prerequisites 

Authentication for all Microsoft products (Azure AD accounts and Microsoft accounts, such as 365 and Intune) is based on OAuth 2.0 authentication flow and validated against the Microsoft Identity Platform. Please follow the steps in Generating an OAuth 2.0 Authorization Token in Azure to create an OAuth 2.0 app and keep your details to be used later when Adding your OAuth credentials to the Oomnitza vault.

Adding your OAuth credentials to the Oomnitza vault

One you have obtained your OAuth details, add them to the vault in Oomnitza by completing the following steps:

1. In Oomnitza, click Configuration > Security > Credentials.
2. Click Add new credential (+).
3. Search for the integration, and then click the forward button > to select the integration.
4. Enter your client credentials and any other additional information.
5. Click Authenticate. You are prompted to log in to authorize your request.
6. Click CREATE.

Information
If the integration is not listed or you want to choose to another type of Microsoft authentication, click Advanced Mode.

1. Ensure that the INFORMATION tab contains the following:
   1. The name of the credential.
   2. The name of the owner. 
2. Ensure that OAuth 2.0 is selected as the Authorization type.
3. Ensure that the relevant option is selected from the SaaS list below.
4. Click Authenticate. You are prompted to log into Microsoft to authorize your request.
5. Click CREATE.

Microsoft OAuth 2.0 Authorization Code Grant

Requirements: Client ID, Client Secret, Scope, Tenant ID

Uses the Authorization Code grant type, which enables a client application to obtain authorized access to protected resources like web APIs.

For this authentication type, you must supply a space-separated list of scopes that you want the user to consent to. This can cover multiple resources. This value allows your app to get consent for multiple web APIs you want to call.

The {tenant} value in the path of the request can be used to control who can sign into the application. Valid values are commonfor both Microsoft accounts and work or school accounts, organizationsfor work or school accounts only, consumersfor Microsoft accounts only, and tenant identifiers such as the Tenant ID or domain name.

For information on obtaining your Client ID, Tenant ID, Client Secret, and Scopes refer to Generating an OAuth2.0 Authorization Token in Azure.

 Process for adding permissions for Microsoft Defender

Microsoft Client Credentials Grant

Requirements: Client ID, Client Secret, Scope, Tenant ID

Instead of impersonating a user to authenticate when calling another web service, the Microsoft Client Credentials Grant service allows a web service - confidential client - to use its own client credentials. 

The value passed for the scope parameter in the request should be the resource identifier - the application ID URI - of the resource followed by the .default suffix. For the Microsoft Graph example, it is https://graph.microsoft.com/.default.  

When you set up the scope for the Microsoft credential in Oomnitza, ensure that the scope is set to https://graph.microsoft.com/.default.  All the scopes that were granted for that credential in Intune will be inherited.

Dos and don'ts

 Don't add a redirect URI for the Client Credentials Grant.

Do set the scopes that are added for the app in Intune as Application type.

Do ensure that the following scopes are set:
    DeviceManagementManagedDevices.Read.All
    DeviceManagementManagedDevices.ReadWrite.All

When you add client credentials for Microsoft Defender to Oomnitza, you must enter https://api.securitycenter.microsoft.com/.default as the scope in the Scope field.

Application permissions are for service or daemon-type applications that need to access a web API independently, without user interaction for sign-in or consent. Unless you've defined application roles for your web API, this option is disabled. Learn more

Learn more about scopes

Microsoft Resource Owner Grant

Requirements: Client ID, Client Secret, Tenant ID, Resource

Use this option to define the resources required.

The {tenant} is the tenant you want to request permission from. This can be in GUID or friendly name format. If you don't know which tenant the user belongs to and you want to let them sign in with any tenant, usecommon.

The Resource should be the resource identifier (application ID URI) of the resource you want, affixed with the.defaultsuffix. For example:

• Microsoft Graph:https://graph.microsoft.com/.default
  • You can provide more detailed scopes if you wish, i.e. https://graph.microsoft.com/User.Read
• Microsoft 365 Mail API:https://outlook.office.com/.default
• Azure Key Vault:https://vault.azure.net/.default
• Microsoft Defender: https://api.securitycenter.microsoft.com/.default

For information on obtaining your Client ID, Tenant ID, and Client Secret refer to Generating an OAuth2.0 Authorization Token in Azure.

Microsoft OAuth2.0 On-Behalf-Of flow Grant

Requirements: Client ID, Client Secret, Scope

Uses the Azure DevOps Services API. See Azure DevOps Services: Authenticate with OAuth 2.0.

Related Links

Generating an OAuth2.0 Authorization Token in Azure

Microsoft Azure Documentation: OAuth 2.0 flows