Build app registration API permission configs with delegated scopes, application roles, and consent settings.
Build app registration API permission configs with delegated scopes, application roles, and consent settings for Microsoft Graph and other APIs.
Required Fields
appRegistration.displayNameappRegistration.signInAudiencerequiredResourceAccessrequiredResourceAccess[0].resourceAppIdrequiredResourceAccess[0].resourceAccessOutput will appear here...The builder validates that appRegistration.displayName, appRegistration.signInAudience, requiredResourceAccess, and the first resource's resourceAppId/resourceAccess all resolve before accepting the JSON as a valid app registration permission manifest; it can't verify the listed permission id GUIDs actually correspond to the named value/description for the target resource API, or that a tenant admin has actually granted consent, those are only confirmed against the live Microsoft Graph API and portal consent state.
Build an Entra ID app registration's requiredResourceAccess block, listing delegated (Scope) and application (Role) permissions per resource API by GUID, since Microsoft Graph permission IDs are opaque GUIDs, not human-readable strings, the value field is a display convenience only, the actual permission granted is determined entirely by the id GUID. Application permissions (type: Role) grant standing access usable without any signed-in user context (suitable for a daemon/background service), while delegated permissions (type: Scope) only grant access when acting on behalf of a signed-in user and are bounded by that user's own actual permissions, mixing the two types in the same resourceAccess array is normal, but conflating what each actually authorizes is a common and consequential mistake.
Always verify permission GUIDs (id) against Microsoft's official Graph permissions reference rather than trusting a value label alone, a mismatched id/value pair silently grants a different permission than what the readable name suggests.
Prefer delegated (Scope) permissions over application (Role) permissions whenever the workload genuinely operates in a signed-in-user context, application permissions carry standing, tenant-wide access that's harder to reason about and audit than permissions bounded by an actual user's own access.
Periodically audit an app registration's actual permission usage against what's requested in requiredResourceAccess, an app accumulating broad application permissions it no longer (or never did) actually use is unnecessary standing privilege that widens the blast radius if the app's credentials are ever compromised.
A delegated permission only works in the context of a signed-in user and is bounded by what that specific user can already access, the app essentially acts as that user. An application permission grants the app standing access on its own behalf, usable in a background service with no signed-in user at all, and its access isn't bounded by any particular user's permissions, it's whatever the permission itself grants tenant-wide. Application permissions are inherently higher-risk since they don't inherit any per-user access boundary.
value is a human-readable label matching the id GUID for a given permission, useful for review and documentation, but Microsoft Graph and Entra ID resolve the actual granted permission from the id GUID, not the value string. If value and id are mismatched (a copy-paste error listing the wrong GUID for a given label), the app actually gets whatever permission the id GUID represents, not what the value text claims, always verify the GUID against Microsoft's published permission reference, not just the readable label.
No, it means a tenant administrator must explicitly grant consent for the permissions (typically via the Azure portal's 'Grant admin consent' action or an equivalent API call) before the app can actually use them, individual users can't self-consent to admin-required permissions the way they might for a low-risk delegated scope like User.Read. This is the correct gate for high-privilege application permissions, requiring deliberate admin review rather than allowing broad access to be silently granted through routine end-user consent.
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.