🧩 Application Registration

An Application Registration defines the blueprint of an application in Microsoft Entra ID. It contains the global configuration that all Service Principals are created from and provides the client identity used for OAuth2 authentication in the homelab.

This page explains what an Application Registration is and how to configure one correctly for internal apps, OAuth2 Proxy, and automation roles.

🎯 Purpose in the Homelab

Application Registrations are used to:

• Issue client IDs for OAuth2 Proxy and internal apps
• Define redirect URIs for the reverse proxy
• Configure API permissions for automation
• Generate client secrets or certificates for secure authentication
• Serve as the source object for the Service Principal that receives RBAC roles

In short:

Application Registration = identity definition
Service Principal = identity instance used by automation

🛠️ How to Configure an Application Registration

Below is the contributor‑friendly, step‑by‑step configuration process used across the homelab.

1️⃣ Create the Application Registration

Azure Portal → Microsoft Entra ID → App registrations → New registration

Fill out:

• Name:
  Use a clear, homelab‑consistent naming pattern (e.g., homelab-oauth2-proxy, ansible-automation, grafana-internal)

• Supported account types:
  Single tenant (default and recommended)

• Redirect URI:
  For OAuth2 Proxy or web apps behind Nginx:

  https://<your-domain>/oauth2/callback
  

  Add additional URIs as needed for multi‑app setups.

Click Register.

2️⃣ Record the Application (Client) ID

After creation, copy:

• Application (client) ID
• Directory (tenant) ID

These values are required by:

• OAuth2 Proxy
• Internal apps
• Ansible provisioning roles
• CI/CD pipelines

Store them in your secrets workflow or Ansible Vault.

3️⃣ Configure Redirect URIs

Navigate to:

Authentication → Redirect URIs

Add all callback URLs used by your reverse proxy or internal apps.

Examples:

https://auth.refol.us/oauth2/callback
https://grafana.refol.us/oauth2/callback
https://proxmox.refol.us/oauth2/callback

Enable:

• ✔️ Access tokens
• ✔️ ID tokens

These are required for OAuth2 Proxy.

4️⃣ Assign Required API Permissions

Most homelab apps only need:

• Microsoft Graph → User.Read

For automation roles (Ansible, CI/CD), permissions are typically handled through RBAC, not Graph API scopes.

If an app requires additional Graph scopes, document them explicitly in the related service page.

5️⃣ Generate Credentials (Secret or Certificate)

Option A — Client Secret (simple, short‑lived)

Certificates & secrets → New client secret

• Description: ansible-automation, oauth2-proxy, etc.
• Expiry: Choose based on your rotation policy
• Store securely in Ansible Vault or your secret‑management workflow

Option B — Certificate (preferred for automation)

Upload a public certificate generated by your automation role.

Certificates provide:

• Longer lifetime
• Stronger security
• Resistance to exfiltration

6️⃣ Verify the Service Principal

Entra ID automatically creates a Service Principal for the Application Registration.

Find it under:

Enterprise applications → All applications

This is the identity you assign RBAC roles to.

7️⃣ Assign RBAC Roles (If Needed)

For automation or API access:

Azure Portal → Subscriptions / Resource Groups → Access control (IAM)

Assign roles to the Service Principal, not the Application Registration.

Common homelab roles:

• Reader
• Contributor
• Storage Blob Data Contributor (for backup workflows)

Use least‑privilege principles.

📘 Example: OAuth2 Proxy Application Registration

A typical OAuth2 Proxy registration includes:

• Redirect URI:

  https://<app-domain>/oauth2/callback
  

• Token types: Access + ID tokens
• Permission: Microsoft Graph → User.Read
• Secret: 6–12 month rotation
• No RBAC roles required
• Used by Nginx reverse proxy for login enforcement

🔧 Example: Automation (Ansible) Application Registration

• No redirect URIs required
• No Graph permissions required
• Certificate‑based authentication recommended
• RBAC roles assigned at subscription/resource‑group level
• Used by Ansible to provision Entra ID apps, secrets, and SPs

🔗 Related Pages

• Service Principal — Identity instance created from the Application Registration
• Entra ID OAuth2 Provisioning Ansible Role — Automates creation of apps, secrets, and permissions
• OAuth2 Proxy Integration with Entra ID — Using Entra ID as the identity provider for OAuth2 Proxy
• Microsoft Learn - Register an application in Microsoft Entra ID - A Microsoft Learn how-to guide on how to register an application in Microsoft Entra ID.