Plan and Implement Workload Identities · Topic 3 of 4
App Registrations and Permissions
SC-300 app registrations: account types, redirect URIs, certificates, secrets and federated credentials, delegated and application permissions, app roles.
- 6 min
- A registration creates an application object and a service principal. Account types decide who can sign in.
- Credentials: certificate recommended, client secret limited to 24 months, federated credential with no secret. Public clients have none.
- Delegated permissions act for a user. Application permissions act as the app and always need admin consent.
What it is
When a developer builds an application that uses Microsoft Entra to sign users in or to call an API, the app must be registered. An app registration is the definition of the application: its identity, where it can receive tokens, how it proves itself and which permissions it asks for. Registering creates an application object in the home tenant and a service principal, the enterprise application, that represents it there.
How it works
Planning a registration
| Decision | Options |
|---|---|
| Supported account types | Single tenant only, multi tenant, multi tenant and personal Microsoft accounts, or personal accounts only |
| Application type and redirect URI | Web, single page application, or mobile and desktop. The redirect URI is where Entra sends the token |
| Owners | The people allowed to manage the registration |
| Publisher | A verified publisher gives users and admins more trust at consent |
A single tenant app is used only by the home tenant. A multi tenant app can be used by other tenants, and each gets its own service principal.
How an app proves its identity
An app, such as a web service, signs in with a credential. The credential types are:
| Credential | Notes |
|---|---|
| Certificate | Recommended. The app signs a JWT assertion with a private key and the public key is uploaded |
| Client secret | A shared password, shown only once when created, with a limited lifetime of up to 24 months. Use for quick tests |
| Federated credential | Trusts tokens from an external identity provider, so there is no secret to rotate |
A confidential client, such as a web app on a server, can keep a credential. A public client, such as a mobile or desktop app on a user's device, cannot protect a secret, so it has no credential and uses public client flows. Store secrets in Azure Key Vault, track their expiry, and rotate them before they lapse.
API permissions
An app asks for permission to call an API such as Microsoft Graph. There are two types.
| Permission type | Meaning | Consent |
|---|---|---|
| Delegated | The app acts on behalf of a signed in user, and gets no more than the user could do | The user consents, or an admin for sensitive scopes |
| Application | The app acts as itself with no user, such as a nightly service reading every calendar | Always needs administrator consent |
A background service that runs with no signed in user needs an application permission. A web app that reads only the mail the signed in user can see needs a delegated permission. Some delegated permissions, for example reading the full profile of all users, cannot be consented to by ordinary users and need admin consent. After adding permissions to the registration, an administrator can grant admin consent. Resource specific consent limits a permission to one team or chat, which suits Teams apps.
Exposing your own API and app roles
If your app is itself an API, Expose an API defines scopes, which are delegated permissions that other apps can request.
App roles are roles that your app defines, such as Admin or Reader. They can be assigned to users and groups, or to other applications. When a user signs in, the roles they hold appear in the token's roles claim, and the app uses them to decide what the user may do. To create one, add an app role in the registration with a display name, a value, and the allowed member types, which are users and groups, or applications. Assign the role afterwards in the enterprise application.
| Need | Feature |
|---|---|
| Your API offers permissions other apps can request | Expose an API, scopes |
| Your app has Admin and Reader roles | App roles |
| A service calls Graph with no user | Application permission with admin consent |
| A mobile app has no secret | A public client with no credential |
Controlling and monitoring registrations
- To stop ordinary users from creating registrations, set Users can register applications to No in the user settings.
- Monitor secret and certificate expiry in the registration, and review audit logs to see who added or changed credentials. Adding a client secret is a configuration change recorded in the audit logs, which show the initiator and the time.
- Remove registrations that are no longer used, since a tenant cannot be deleted while registrations exist.
A worked scenario
A company builds an orders API and a web portal. The API is registered as single tenant, exposes a scope named Orders.Read, and defines app roles Admin and Reader. The portal is registered with a redirect URI and a certificate for its credential, and requests the delegated Orders.Read permission. An administrator grants admin consent once. A nightly reporting service is registered separately, uses an application permission, and signs in with a federated credential from its pipeline, so there is no secret to expire. The team turns off "Users can register applications" so every new registration goes through them.
What to remember for the exam
- A registration creates an application object and a service principal. Account types decide who can sign in.
- Credentials: certificate recommended, client secret limited to 24 months, federated credential with no secret. Public clients have none.
- Delegated permissions act for a user. Application permissions act as the app and always need admin consent.
- App roles are defined in the registration and assigned to users, groups or apps.
- Adding a secret is recorded in audit logs.
"A service runs nightly with no signed in user" is an application permission. "On behalf of the signed in user" is delegated.
How the exam asks about this
- "A background service reads every calendar in the tenant." An application permission.
- "A mobile app cannot protect any secret." A public client, with no credential.
- "Create roles your app can check for." App roles.
- "Who added a client secret last night?" The audit logs.
Common mistakes
Storing a client secret in source code. Use a certificate, federation or Key Vault.
Forgetting admin consent for application permissions. They never work without it.
Confusing the registration with the enterprise application. One defines the app, the other is its instance and where you assign users.
Letting secrets expire silently. Track and rotate them.
Check yourself
What is the difference between delegated and application permissions?
Delegated permissions act on behalf of a signed in user. Application permissions act as the app itself with no user and need admin consent.
Which credential avoids rotating a secret?
A federated credential.
What are app roles?
Roles defined in an app registration that can be assigned to users, groups or apps and appear in the token.
Topic 3 of 4 in Plan and Implement Workload Identities
Test yourself on Plan and Implement Workload Identities
The full Microsoft SC-300 question bank has 650 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.