- 16 minutes to read

Register Nodinite Applications in Azure AD (Entra ID) with OpenID

Empower your organization with secure, modern authentication and authorization using Microsoft Entra ID (Azure AD) and Nodinite. This guide provides step-by-step instructions to register and configure the webApi, webClient, and NodiniteInstallationClient applications for seamless integration, robust security, and future-proof scalability.

  • ✅ Effortlessly register Azure AD applications for Nodinite integration
  • ✅ Enable secure OpenID Connect authentication for all Nodinite services
  • ✅ Grant delegated and application permissions with admin consent for compliance
  • ✅ Streamline token and manifest configuration for reliability
  • ✅ Capture all essential IDs and secrets for ongoing management

For details on configuring OpenID Connect and OAuth 2.0 authentication in Nodinite, see the Install Nodinite v7 – OpenID Connect (OIDC) and OAuth 2.0 guide.

Prerequisites

Before you begin, ensure you have:

  • Azure AD Administrator access – You need permissions to register applications and grant admin consent in your Azure AD tenant.
  • An active Azure subscription – Required for Microsoft Entra ID (Azure AD) services.
  • A secure location to store credentials – Keep a password manager or secure note app ready to capture sensitive values.

What You Will Create

You will register three distinct applications in Microsoft Entra ID (Azure AD), each serving a critical role in your Nodinite integration. This separation of concerns enhances security, simplifies troubleshooting, and provides granular control over permissions:

  1. webApi – The backbone of your integration. This protected API exposes delegated permission scopes (for user access) and application permission app roles (for service-to-service communication). It uses App Roles for scalable, token-efficient authorization that avoids the token size limitations of group-based claims. This ensures that only authorized applications and users can interact with Nodinite resources, even when users belong to hundreds of Azure AD groups.
  2. webClient – Your users' gateway to Nodinite. This interactive web application requests delegated permission scopes, enabling users to sign in securely and access Nodinite features with their Azure AD credentials. It leverages modern authentication protocols like Authorization Code + PKCE for maximum security.
  3. NodiniteInstallationClient – Your automation powerhouse. This background/daemon client uses application permissions to perform unattended tasks like installations, updates, and system maintenance without user interaction. It enables seamless CI/CD integration and automated operations.

You complete this setup when:

  • You configure the API to expose: nodinite_webapi_all (Scope) and AppRole_WebApi_all (App Role for services) plus user roles like Nodinite.Admin and Nodinite.User (App Roles for users).
  • You assign Azure AD users or groups to the user app roles (e.g., "Nodinite Admins" group → Nodinite.Admin role).
  • You grant the webClient the delegated permission (Admin consent = Granted).
  • You grant the NodiniteInstallationClient the application permission (Admin consent = Granted).
  • You have copied all IDs, secrets, and the API Application ID URI for future reference.

Tip

Keep a secure note open to capture: Tenant (Directory) ID, each Application (client) ID, each Secret Value (shown only once), and the API Application ID URI.

1. Create the API Application – webApi

Tip

Register the webApi — the secure, manageable API that lets you control who and what accesses Nodinite services.

1.1 Register the Application

  1. Azure Portal: Microsoft Entra ID > App registrations > + New registration.
  2. Name: webApi
  3. Supported account types: Accounts in this organizational directory only (Single tenant).
  4. Redirect URI: (leave blank)
  5. Click Register.
  6. In Overview, copy Application (client) ID and Directory (tenant) ID.

webApi Overview
The Azure Portal displays the registered webApi application overview.

1.2 Set Application ID URI & Add Scope

The Application ID URI uniquely identifies your API in your organization. Client applications use this URI to request tokens for your API.

  1. Left menu: Expose an API.
  2. If prompted, click Set for Application ID URI (accept default or confirm the value). Copy this value—you'll need it later.
  3. Under Scopes defined by this API, click + Add a scope.
    • Scope name: nodinite_webapi_all
    • Who can consent: Admins only
    • Admin consent display name: Full access to Nodinite WebAPI
    • Admin consent description: Full access to Nodinite WebAPI
    • State: Enabled
    • Click Add scope.

Expose an API – Scope Added
You add a scope to the webApi application for delegated permissions.

Important

When configuring Nodinite OpenID settings: You will use this scope in the Scopes field (OAuth Web Client settings - see section "OAuth Web Client settings" in the OpenID page) in the format: api://<webApi-client-id>/nodinite_webapi_all. Example: api://d731e991-1234-5678-90ab-cdef12345678/nodinite_webapi_all. This is the full scope identifier that grants delegated access to your webApi.

1.3 Add App Roles (User and Application Permissions)

App Roles are the recommended approach for application authorization in Azure AD/Entra ID. They provide scalable, token-efficient role-based access control (RBAC) without the token size limitations of group claims.

Note

App Roles are available in ALL Azure AD pricing tiers (Free, Basic, Premium P1, Premium P2). These are application-specific roles defined in your app registration—NOT custom Azure AD directory roles (which require Premium licensing). App Roles have no additional licensing costs and work identically across all tiers.

Warning

Why App Roles instead of Groups? When users belong to many Azure AD groups (50+), including all group memberships in the JWT token can exceed HTTP header size limits (typically 16-32 KB), preventing successful login. App Roles solve this problem by:

  • Scalability – Tokens remain small regardless of the number of groups a user belongs to
  • Application-specific – Cleaner separation of concerns; roles are scoped to your application
  • Performance – Faster token generation and validation
  • Manageability – Easier to assign, audit, and maintain than group-based authorization
  • Cost-effective – Works on all Azure AD tiers including Free—no premium license required

This is the best practice for enterprise environments where users commonly have extensive group memberships.

1.3.1 Create App Role for Installation Client (Application Permission)

  1. Left menu: App roles > + Create app role:
    • Display name: AppRole_WebApi_all
    • Allowed member types: Applications (this is for service-to-service authentication)
    • Value: AppRole_WebApi_all
    • Description: Application permission for Nodinite installation and background services
    • State: Enabled
  2. Click Apply / Create.

App Roles – Application Permission
You create an app role for application-to-application (service) authentication.

Tip

When configuring Nodinite OpenID settings: You will use this app role value in the Installation Client Claims field (OAuth General settings - see section "OAuth General settings" in the OpenID page). Use KEY: http://schemas.microsoft.com/ws/2008/06/identity/claims/role, VALUE: AppRole_WebApi_all. This enables the NodiniteInstallationClient to authenticate with application permissions.

1.3.2 Create App Roles for Users (Delegated Permissions)

Create roles for different user permission levels in Nodinite. Add as many roles as needed for your organization's access control requirements.

  1. Left menu: App roles > + Create app role:

    • Display name: Nodinite.Admin
    • Allowed member types: Users/Groups (this is for user authentication)
    • Value: Nodinite.Admin
    • Description: Full administrative access to all Nodinite features
    • State: Enabled
  2. Click Apply / Create.

  3. Repeat to create additional user roles:

    • Nodinite.User

      • Display name: Nodinite.User
      • Allowed member types: Users/Groups
      • Value: Nodinite.User
      • Description: Standard user access to Nodinite monitoring and logging features
      • State: Enabled
    • Nodinite.ReadOnly (optional – if you need read-only access)

      • Display name: Nodinite.ReadOnly
      • Allowed member types: Users/Groups
      • Value: Nodinite.ReadOnly
      • Description: Read-only access to Nodinite dashboards and reports
      • State: Enabled

App Roles – User Roles
You create app roles for user authorization with different permission levels.

Tip

Customize roles to match your organization's needs. Common patterns include:

  • Nodinite.Admin – IT administrators who configure monitoring, manage users, and access all features
  • Nodinite.User – Integration developers who create monitors, view logs, and manage resources
  • Nodinite.ReadOnly – Business stakeholders who view dashboards and reports without editing
  • Nodinite.Support – Help desk users who can view incidents and logs but not change configurations

You can create as many roles as needed and map them to specific Nodinite permissions during installation. App Roles are free and work identically across all Azure AD tiers—no paywall or premium licensing required.

Important

When configuring Nodinite OpenID settings: You will use these app role values in the Nodinite Claims field (OAuth Web Client settings - see section "OAuth Web Client settings" in the OpenID page). Use KEY: http://schemas.microsoft.com/ws/2008/06/identity/claims/role, VALUE: comma-separated role values like Nodinite.Admin,Nodinite.User (enter the roles users should have to access your Nodinite instance).

1.5 Assign Users and Groups to App Roles

After creating app roles, you must assign users or Azure AD groups to these roles. This determines which users can access Nodinite and what permissions they have.

Tip

Best Practice: Assign Azure AD groups to app roles instead of individual users. This simplifies management—add/remove users from the group rather than modifying app role assignments individually.

  1. In Azure Portal, navigate to Microsoft Entra ID > Enterprise applications.
  2. Search for and select webApi (you may need to change the filter to "All applications").
  3. Left menu: Users and groups > + Add user/group.

Enterprise App – Add Assignment
You initiate the process to add user/group assignments to app roles.

  1. Click None Selected under Users and groups.
  2. Select an Azure AD group (e.g., "Nodinite Admins") or individual users.

Enterprise App – Select Users
You search for and select users or groups to assign to the application.

  1. Click Select.
  2. Click None Selected under Select a role.
  3. Select the app role (e.g., Nodinite.Admin) you want to assign to the group/users.

Enterprise App – Select Role
You select the specific app role to assign to the selected users or groups.

  1. Click Select > Assign.
  2. Repeat for additional groups/users with different roles (e.g., assign "Nodinite Users" group to Nodinite.User role).

Enterprise App – Users and Groups View
The Users and groups view shows all role assignments for the webApi application.

Option 2: Assign via App Registration (Alternative)

If you prefer to assign roles directly from the app registration:

  1. Navigate to Microsoft Entra ID > App registrations > select webApi.
  2. Go to Overview and click the link under Managed application in local directory (this opens the Enterprise Application).
  3. Follow steps 3-10 from Option 1 above.

Important

Users MUST be assigned to an app role to access Nodinite. If a user is not assigned to any app role, they will be denied access even if they can authenticate with Azure AD. This assignment is what authorizes them to use the application.

Note

Role assignments appear in the user's access token as the roles claim. Nodinite reads this claim to determine the user's permissions. The token remains small because only the role values (e.g., Nodinite.Admin) are included—not all group memberships.

1.6 Set Access Token Version to 2

Version 2 tokens are more secure and include enhanced claims that Nodinite requires for proper authentication and authorization. This ensures compatibility with modern identity standards.

  1. Left menu: Manifest.
  2. Locate "requestedAccessTokenVersion": 2. If missing or different, set it to 2.
  3. Click Save.

Manifest – requestedAccessTokenVersion 2
You configure the manifest with requestedAccessTokenVersion set to 2.

Tip

When configuring Nodinite OpenID settings: You will use the webApi Application (client) ID as the Audience value in the OAuth Web API settings section (see section "OAuth Web API settings" in the OpenID page).

webApi configuration is complete. You have successfully created the core API with scalable App Roles-based authorization that protects against token size limitations and provides enterprise-grade access control.

2. Create the Interactive Client – webClient

Tip

Register the webClient — give your users secure, single-sign-on access to Nodinite using Azure AD and modern authentication.

2.1 Register webClient

  1. App registrations > + New registration.
  2. Name: webClient
  3. Supported account types: Single tenant.
  4. Redirect URI (Platform Web): Enter the URL where your Nodinite Web Client will be hosted, followed by /signin-oidc. For example: https://nodinite.yourdomain.com:50000/signin-oidc. If you're testing locally, use http://localhost:50000/signin-oidc or your local development URL.
  5. Click Register.
  6. Copy the Application (client) ID. You will need this value when configuring Nodinite.

Web Client Overview
The Azure Portal displays the registered webClient application overview.

Tip

When configuring Nodinite OpenID settings: You will use the webClient Application (client) ID in the Client ID field (OAuth Web Client settings - see section "OAuth Web Client settings" in the OpenID page).

2.2 Configure Authentication

Secure your authentication flow by using modern protocols. The Authorization Code + PKCE flow provides superior security compared to legacy implicit grant flows.

  1. Left menu: Authentication.
  2. Confirm the redirect URI is listed.
  3. Leave Implicit grant checkboxes unchecked (modern auth uses Authorization Code + PKCE for enhanced security).
  4. Ensure Allow public client flows is No (unless specifically required for mobile/desktop scenarios).
  5. Click Save if you made any changes.

Web Client Authentication
You configure authentication settings for the webClient application.

Tip

When configuring Nodinite OpenID settings: The redirect URI you configured here must match the Callback Path field in the OAuth Web Client settings (see section "OAuth Web Client settings" in the OpenID page). The default callback path is /signin-oidc, so your full redirect URI should be https://your-nodinite-url:port/signin-oidc.

2.3 Add API Permissions (Delegated)

  1. Left menu: API permissions > + Add a permission.
  2. Choose My APIs > select webApi.
  3. Choose Delegated permissions and tick nodinite_webapi_all.
  4. Click Add permissions.
  5. Click Grant admin consent for [Your Tenant Name] and confirm. The status should change to Granted. This step is crucial—it authorizes the webClient to access the webApi on behalf of your users.

Web Client API Permissions
You configure API permissions for delegated access to webApi.

Important

When configuring Nodinite OpenID settings: This delegated permission corresponds to the custom API scope you must add in the Scopes field (OAuth Web Client settings - see section "OAuth Web Client settings" in the OpenID page). You'll enter it as: api://<webApi-client-id>/nodinite_webapi_all along with the default scopes (openid, profile, email, offline_access).

2.4 Create Client Secret (Confidential Web App)

  1. Left menu: Certificates & secrets > + New client secret.
  2. Add a description and expiry per policy.
  3. Click Add.
  4. Copy the Value immediately (you cannot view it again); store securely.

web Client Client Secret
You create a client secret for the webClient application.

Warning

Store this secret value securely! You will need it during Nodinite installation, but Azure AD only displays it once. If lost, you must generate a new secret. This secret is not entered in the OpenID configuration page—it's used internally by the Nodinite installation process.

Web Client configuration is complete. Your users can now sign in to Nodinite securely using their Azure AD credentials, enabling centralized identity management and single sign-on (SSO) capabilities.

3. Create the Installation / Daemon Client – NodiniteInstallationClient

3.1 Register

Tip

Register the NodiniteInstallationClient — enable secure, unattended automation for installs, updates, and maintenance to streamline your DevOps workflows.

  1. App registrations > + New registration.
  2. Name: NodiniteInstallationClient
  3. Supported account types: Single tenant.
  4. Redirect URI: leave blank.
  5. Register.
  6. Copy Application (client) ID.

Installation Client Overview
The Azure Portal displays the registered NodiniteInstallationClient application overview.

Tip

When configuring Nodinite OpenID settings: You will use this Application (client) ID in the Installation Client ID field (OAuth General settings - see section "OAuth General settings" in the OpenID page).

3.2 Add Application Permission

Application permissions enable service-to-service authentication without user interaction—essential for automated deployments and background tasks.

  1. Left menu: API permissions > + Add a permission.
  2. My APIs > select webApi.
  3. Choose Application permissions (not Delegated).
  4. Tick AppRole_WebApi_all.
  5. Click Add permissions.
  6. Click Grant admin consent and confirm. The status should change to Granted. This authorizes the installation client to act independently without requiring a signed-in user.

Installation Client – API Permissions (Application)
You configure API permissions for the NodiniteInstallationClient application.

Important

When configuring Nodinite OpenID settings: This application permission corresponds to two configuration fields in the OAuth General settings (see section "OAuth General settings" in the OpenID page):

  1. Installation Client Scopes: Enter api://<webApi-client-id>/.default (the .default scope requests all application permissions granted to this client)
  2. Installation Client Claims: Use KEY: http://schemas.microsoft.com/ws/2008/06/identity/claims/role, VALUE: AppRole_WebApi_all (this matches the app role value from section 1.3)

3.3 Create Client Secret

  1. Left menu: Certificates & secrets > + New client secret.
  2. Add description + expiry.
  3. Click Add and copy the Value immediately; store securely.

Installation Client – Client Secret
You create a client secret for the NodiniteInstallationClient application.

Warning

Store this secret value securely! You will need it during Nodinite installation, but Azure AD only displays it once. If lost, you must generate a new secret. This secret is used by the installation process to authenticate the NodiniteInstallationClient.

NodiniteInstallationClient configuration is complete. You now have a robust automation client that can perform unattended installations, updates, and maintenance tasks—perfect for DevOps workflows and CI/CD pipelines.

What You've Accomplished

Congratulations! You have successfully registered three Azure AD applications that form the security foundation of your Nodinite integration:

  • Enhanced Security – Leveraged Azure AD's enterprise-grade authentication with multi-factor authentication (MFA) support, conditional access policies, and audit logging.
  • Centralized Identity Management – Eliminated the need for separate credentials by integrating with your existing Azure AD user directory.
  • Granular Access Control – Configured delegated and application permissions that ensure users and services only access what they need.
  • Scalable Authorization with App Roles – Implemented Microsoft's recommended authorization pattern that prevents token size issues and supports users with extensive group memberships (hundreds of groups). Your authentication will remain reliable regardless of organizational complexity.
  • Token Efficiency – Avoided the "HTTP header too large" errors that plague group-based authorization in enterprises where users belong to many groups.
  • Cost-Effective – App Roles work on ALL Azure AD pricing tiers including the free tier—no Premium P1/P2 license required for this authorization model.
  • Compliance Ready – Aligned with industry best practices for authentication and authorization, supporting compliance frameworks like ISO 27001, SOC 2, and GDPR.
  • Automation Enabled – Set up a dedicated installation client that streamlines deployments and reduces manual configuration errors.

Next Step

Now that you've registered your Azure AD applications, you're ready to configure Nodinite to use them:

Quick Reference: What Goes Where

  • Discovery URL (OAuth General settings): https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration
  • Installation Client ID (OAuth General settings): NodiniteInstallationClient Application (client) ID from section 3.1
  • Installation Client Scopes (OAuth General settings): api://<webApi-client-id>/.default using webApi client ID from section 1.1
  • Installation Client Claims (OAuth General settings): KEY: http://schemas.microsoft.com/ws/2008/06/identity/claims/role, VALUE: AppRole_WebApi_all from section 1.3.1
  • Client ID (OAuth Web Client settings): webClient Application (client) ID from section 2.1
  • Scopes (OAuth Web Client settings): openid, profile, email, offline_access, and api://<webApi-client-id>/nodinite_webapi_all from section 1.2
  • Nodinite Claims (OAuth Web Client settings): KEY: http://schemas.microsoft.com/ws/2008/06/identity/claims/role, VALUE: comma-separated app role values (e.g., Nodinite.Admin,Nodinite.User) from section 1.3.2 and assigned in section 1.5
  • Audiences (OAuth Web API settings): webApi Application (client) ID from section 1.1

Important

App Roles vs Groups: This configuration uses App Roles (via the roles claim) instead of group memberships. App Roles provide:

  • Scalability – Tokens remain small even when users belong to hundreds of Azure AD groups
  • Reliability – Eliminates "HTTP header too large" errors that occur with group claims
  • Best Practice – Microsoft-recommended approach for application authorization

Users receive their assigned app roles in the roles claim after you assign them or their groups to roles in section 1.5.

Install Nodinite v7
Updating Nodinite v7