What's changed: Created SC-300 Chapter 4 (Domain 3: workload identity selection/managed identities (system/user-assigned)/service principals/gMSA; enterprise apps (SSO/Application Proxy/app-role assignment/consent policies/admin consent workflow); app registrations (redirect URIs/secret-certificate-federated credentials/delegated-application permissions/app roles); Defender for Cloud Apps (cloud discovery/Cloud app catalog/OAuth app policies/CA app control/access-session policies)).
4.3App registrations
Understand app registrations for your own apps, app authentication (redirect URIs, secrets/certificates, federated credentials), API permissions (delegated/application), and app roles.
Apps you develop are defined in Entra via an app registration. This is the app’s "blueprint," instantiated as a service principal in each tenant.
4.3.1App authentication and credentials
In an app registration you set redirect URIs (where to return after auth) and supported account types. Credentials to authenticate the app itself are a client secret, a certificate, or the most secure federated credentials (workload identity federation). Federated credentials trust tokens from an external IdP like GitHub Actions, authenticating without storing a secret. For "authenticate from a CI/CD pipeline without keys," federated credentials are best.
4.3.2API permissions and app roles
To access an API (e.g., Microsoft Graph), configure API permissions. Delegated permissions act "on behalf of the signed-in user" and never exceed the user’s rights. Application permissions act "as the app, without a user," are powerful, and require admin consent. Background daemons/services use application permissions. Roles the app exposes are defined as app roles and assigned to calling users/apps. For "a user-less backend reading Graph," use application permissions + admin consent.
Cues: "authenticate the app from CI/CD etc. without keys" = federated credentials. "act on behalf of the user" = delegated permissions. "act as the app without a user, needs admin consent" = application permissions. "roles the app exposes" = app roles. App blueprint = app registration; tenant instance = service principal.
Watch the mix-ups: (1) Delegated (on behalf of user, never exceeds user rights) vs application permissions (as the app, powerful, needs admin consent). (2) Client secrets are a leak source—prefer federated credentials/certificates. (3) App registration (blueprint) vs enterprise app/service principal (tenant instance) are different views.
4.3.3Section summary
- App registration = your app’s blueprint; credentials = secret/certificate/federated credentials (keyless, most secure)
- API permissions = delegated (on behalf of user) and application (as app, needs admin consent); app roles expose roles
- Keyless auth from CI/CD = federated credentials
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want a GitHub Actions pipeline to authenticate an Entra app without storing a client secret. Which is best?
Q2. A user-less background service must read mailboxes via Microsoft Graph. Which API permission type fits?
Q3. You want to call Graph on behalf of the signed-in user, only within that user’s rights. Which API permission type fits?
Q4. Which correctly relates app registrations and service principals?
Q5. Which is the most appropriate design regarding client secrets?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.