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.
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.