10.2 App Registrations, API Permissions & App Roles
Key Takeaways
- App registrations define the application object: identifiers, authentication platforms and redirect URIs, credentials, API permissions, exposed scopes, and app role definitions.
- Configure authentication by platform type (web, SPA, mobile/desktop, etc.) with exact redirect URIs; prefer certificates or federated credentials over long-lived client secrets for confidential clients.
- Delegated permissions act as the signed-in user; application permissions act as the app itself (daemon/service) and almost always require admin consent.
- Admin consent grants organization-wide approval for permissions; user consent, when allowed, is narrower and governed by tenant consent policies.
- Create app roles for application-defined RBAC and expose an API with scopes (application ID URI + OAuth2 permissions) so other clients can request delegated access with least privilege.
App registrations: the application definition
Where enterprise applications are the tenant instance you assign and govern, app registrations are where you plan and create the application model itself. SC-300 expects Identity and Access Administrators to create registrations, configure authentication settings, add API permissions, define app roles, and expose APIs—not necessarily write production code, but definitely own the identity contract those apps present to Entra.
| Artifact | Purpose |
|---|---|
| Application (client) ID | Public identifier of the app |
| Directory (tenant) ID | Tenant where the registration lives |
| Object ID (app object) | Directory object id of the application |
| Redirect URIs | Where auth responses may be returned |
| Credentials | Client secrets, certificates, federated identity credentials |
| API permissions | Delegated and application permissions this client requests |
| Expose an API | Application ID URI and scopes others may request |
| App roles | Roles assignable to users, groups, or applications |
Plan and create an app registration
Planning questions before you click New registration:
- Who signs in? Workforce users in one tenant, multi-tenant customers, or personal Microsoft accounts?
- Public or confidential client? SPA/mobile public clients must not hold client secrets; web APIs and daemons are confidential.
- Interactive user or daemon? Determines delegated vs application permissions.
- Single-tenant or multi-tenant? Affects who can consent and where service principals appear.
- Does this app call Microsoft Graph / custom APIs? List least-privilege permissions up front.
- Does this app is an API? Plan application ID URI, scopes, and app roles.
Create flow (conceptual):
- Entra admin center → App registrations → New registration.
- Name the app; choose supported account types (single tenant, multitenant, etc.).
- Optionally add a first redirect URI matching the platform.
- Register; note Application (client) ID and Directory (tenant) ID.
- Configure Authentication, Certificates & secrets, API permissions, Expose an API, App roles, and Owners.
- Verify the companion enterprise application (service principal) in the home tenant for assignment and SSO properties when needed.
Owners on the registration should be real people or operational groups accountable for credentials and permissions—orphan registrations with eternal secrets are audit failures.
Configure app authentication
Platform types and redirect URIs
Under Authentication, you add platform configurations. Redirect URIs must match what the app actually uses; mismatches are a top cause of AADSTS redirect errors.
| Platform | Typical clients | Notes |
|---|---|---|
| Web | Server-side web apps | Confidential; can use secrets/certs; redirect to HTTPS endpoints |
| Single-page application | React/Angular/Vue SPAs | Public client patterns; PKCE; SPA redirect type |
| Mobile and desktop | Native / public clients | Public client; custom URI schemes or http://localhost patterns |
| Web API | Resource APIs | Often no interactive redirect; exposes scopes/roles |
Rules of thumb for SC-300:
- Register exact redirect URIs (scheme, host, port, path).
- Prefer HTTPS for production web redirects.
- Do not put client secrets in mobile or SPA code.
- Enable ID tokens / access tokens implicit settings only when a legacy architecture still requires them; modern SPAs use auth code + PKCE.
- Front-channel logout URL supports coordinated sign-out when applicable.
Certificates, secrets, and federated credentials
Confidential clients authenticate to Entra with credentials on the app registration:
| Credential | Use | Guidance |
|---|---|---|
| Client secret | Simple client credentials | Short expiry; store in Key Vault; avoid when cert/federation possible |
| Certificate | Assertion with private key | Preferred over secrets for many enterprise policies |
| Federated identity credential | GitHub, K8s, other IdPs | Preferred for CI/CD—no long-lived Azure secret in the pipeline |
Rotate before expiry; use overlapping certificates during rotation; restrict who can add credentials (owners, Application Administrator, Cloud Application Administrator). Section 9.3 already framed this for service principals—the configuration surface is the app registration’s Certificates & secrets (and federated credentials) blade.
API permissions: delegated vs application
This comparison is core SC-300 material.
| Attribute | Delegated permissions | Application permissions |
|---|---|---|
| Also called | Scopes (OAuth2 permission scopes) | App roles on the resource app (for app-only) |
| Presence of user | Requires signed-in user (or delegated flow with user context) | No user—app acts as itself |
| Authorization model | Effective permissions ≈ user ∩ granted scopes | Effective permissions = app’s granted application roles |
| Typical flows | Authorization code, device code, OBO | Client credentials |
| Consent | User and/or admin depending on permission and policy | Admin consent effectively required for org use |
| Example Graph | User.Read, Mail.Read (delegated) | User.Read.All, Mail.Read (application) |
| Good for | Apps acting for a person in My Apps / interactive APIs | Daemons, backup services, sync engines |
| Risk if over-granted | App can do what the user can do within scopes | App can act broadly without a user—high blast radius |
Exam decision tree:
- Is there an interactive user for every call? → start with delegated.
- Is it a pure background service with no user? → application permissions + admin consent.
- Can a narrower custom API scope replace
*.Read.Allon Graph? → prefer custom least privilege.
Admin consent
Grant admin consent for [tenant] on the API permissions blade approves permissions organization-wide for that client (subject to the permission type and resource). After admin consent, the enterprise application shows granted permissions, and users generally are not prompted for those consented scopes (depending on policy and new permission additions).
| Consent type | Who approves | Typical result |
|---|---|---|
| User consent | End user (if tenant allows) | Permissions granted for that user (delegated) within policy |
| Admin consent | Admin with privilege to consent | Org-wide grant for listed permissions |
| Admin consent workflow | User requests; reviewers approve | Controlled path when user consent is restricted |
Adding a new high-privilege application permission after go-live requires another admin consent. Developers who only add permissions in the registration but never obtain consent produce “works on my machine with user creds, fails as daemon” incidents.
Create app roles
App roles are application-defined roles declared on the registration (for example Orders.Admin, Orders.Reader). They can be allowed for users/groups, applications, or both:
| Allowed member types | Meaning |
|---|---|
| Users/Groups | Assign on enterprise app to people/groups; appear as roles in user tokens |
| Applications | Assign to other apps (application permissions / app-only roles) |
| Both | Role can be used in either assignment pattern |
Operational pattern:
- Define app roles on the app registration (value, display name, description, allowed member types).
- Assign users/groups to those roles on the enterprise application.
- Application code authorizes based on the
rolesclaim (or equivalent mapping for SAML).
App roles are not Entra directory roles and not Azure RBAC roles—three different authorization planes. SC-300 loves stems that mix the vocabulary.
Expose an API and scopes (SC-300 depth)
When your app is a protected API (resource), you Expose an API:
- Set an Application ID URI (unique resource identifier, often
api://{client-id}or a verified domain-based URI). - Define scopes (OAuth2 permission scopes) such as
Orders.Read,Orders.Writewith admin/user consent display strings. - Decide who can consent (admins only vs users) per scope where the model allows.
- Client apps add delegated permissions to your API by selecting those scopes under API permissions.
- At runtime, clients request tokens for your Application ID URI / scope; your API validates the access token audience and scopes/roles.
| Piece | Role in OAuth |
|---|---|
| Client app registration | Requests scopes / app roles |
| Resource app registration | Exposes scopes and/or app roles; validates tokens |
| Scope (delegated) | What a client may do on behalf of a user |
| App role (application permission) | What a client may do as itself |
Audience (aud) | Must match the resource API’s expected app ID URI / identity |
Least privilege example: instead of a single access_as_user mega-scope for everything, split Invoices.Read and Invoices.Pay so a reporting SPA never receives payment rights.
Daemon against your API: define an app role allowed for applications on the resource, grant that application permission to the daemon client, admin-consent, client-credentials token, authorize on roles.
Putting registration skills into exam answers
| Stem cue | Likely answer |
|---|---|
| Redirect URI mismatch / platform wrong | Fix Authentication platform + URI |
| SPA stores client secret | Redesign—public client, no secret |
| Nightly job needs Graph without user | Application permission + admin consent |
| App should mail as signed-in user | Delegated Mail.* + user sign-in |
| Custom roles in token for groups | App roles + enterprise app assignment |
| Second app calls your API as user | Expose an API scopes; client requests those scopes |
| Pipeline auth without secret in GitHub | Federated identity credential |
Security hygiene for registrations
- Least-privilege API permissions; avoid
Directory.ReadWrite.All“so it works.” - Prefer certs/federation; expire secrets aggressively.
- Require owners; inventory unused registrations.
- Separate dev / test / prod registrations and credentials.
- Review still-valid permissions when features are retired.
- Remember consent and over-permission risk deepen in section 10.3.
A background sync service must read every user’s basic profile in Microsoft Graph with no signed-in user present. Which permission model is correct?
Which statement correctly contrasts delegated and application permissions?
You are protecting a custom Web API and want other workforce apps to call it on behalf of signed-in users with least privilege. What should you configure on the API’s app registration?
Which authentication credential approach is preferred for a confidential client used by GitHub Actions when long-lived secrets should be avoided?