Build service principal app registrations with roles and API permissions.
Last verified: May 2026
Build service principal app registration configs with roles, API permissions, and credentials.
Required Fields
displayNamesignInAudiencerequiredResourceAccessOutput will appear here...Azure service principals are identity objects in Microsoft Entra ID that represent applications, services, and automation tools. Creating a service principal involves registering an application, configuring authentication credentials (certificates or secrets), defining API permissions (delegated or application-level), and assigning RBAC roles on Azure resources. The Service Principal Config Builder helps you configure app registrations with the correct redirect URIs, credential types, API permission grants, and role assignments for common automation and integration scenarios.
An app registration is the global definition of an application in your Entra ID tenant — it specifies the application ID, redirect URIs, API permissions, and credentials. A service principal is the local instance of that app registration in a specific tenant. When you create an app registration, a service principal is automatically created in the home tenant. For multi-tenant apps, a service principal is created in each tenant that consents to the app. RBAC role assignments are made on the service principal, not the app registration.
Certificates are more secure because the private key never leaves the client, and authentication uses asymmetric cryptography. Client secrets are simpler to set up but are effectively passwords that can be leaked. For production workloads, use certificates or — better yet — managed identities (which eliminate credentials entirely). If you must use secrets, set short expiration periods (90 days or less) and automate rotation. Note that both secrets and certificates have a maximum lifetime, and you should monitor expiration dates to prevent authentication failures.
Your team is setting up a new Terraform service principal for an external CI runner. The builder generates: an app registration with appropriate display name, a certificate-based credential (uploads the public cert from your CI's vault), and RBAC role assignments granting Contributor only on the specific resource group Terraform manages (not subscription-scoped). Output includes both the az CLI commands and a runbook entry for monthly cert rotation. Compared to hand-crafting via the Azure portal, end-to-end setup time drops from ~1 hour to ~15 minutes with consistent best practices applied.
The builder configures Azure app registrations + service principals: app registration (display name, sign-in audience: single-tenant/multi-tenant/personal-MS-account), redirect URIs (web and SPA), API permissions (Microsoft Graph or other APIs, with delegated or application permission types), credentials (client secret OR certificate with thumbprint), and service principal RBAC role assignments. Output is generated as az ad app + az ad sp + az role assignment commands and Terraform azuread_application + azuread_service_principal resources.
Always prefer managed identities over service principals for Azure-resident workloads. Service principals are for external tools (Terraform from a CI runner outside Azure, third-party SaaS integrations, on-prem agents). For anything inside Azure, managed identity is simpler, more secure, and rotation-free.
Certificate-based service principal auth is significantly more secure than client secrets. The private key never leaves the calling system; auth uses asymmetric crypto resistant to credential stuffing. Trade-off: more setup complexity. For production CI/CD systems, certificates are worth the setup effort.
Service principal client secret expiration is a common production-incident cause. Default expiry is 24 months but most teams discover them when auth starts failing in production. Set Azure Monitor alerts on 'application credential expiring within 30 days' for every production app registration — the alert is free and prevents the all-too-common 'sudden auth failure' incident.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.