Who is the app when nobody is signed in?
At nine in the morning, Ada signs in and the product images load. At nine that evening, her laptop is shut and customers still expect the shop to work. “Whose password is the website using now?” asks the new developer. The app needs its own identity. Think of a staff badge issued to the application: the badge identifies it, while a separate permission decides which stockroom it may enter. Azure can manage the badge’s credentials on a supported host. The badge alone still does not open the door.
Class Eight gave Ada, a person, Storage Blob Data Reader on one account. We can give a software identity a role at a scope too. A workload is software doing work: an app, scheduled job or deployment pipeline. A workload identity lets Azure recognize that software. The identity answers “which app is asking?”; its assigned role answers “what may this app do?”
- Credential
- Proof used to authenticate. A client secret is a password-like credential that an application owner must store and rotate. A short-lived access token is different: software presents it to a target service after authentication. A token can still be stolen while valid, so do not log or expose it.
Imagine a storage account key pasted into the storefront's config file and committed to a public repository. Deleting that line in a later commit does not revoke the key or erase its earlier appearance. Treat it as exposed: disable or rotate it through an approved response, remove it from the application's configuration, and inspect what it could access.1
What is a service principal?
A service principal is an application identity in an Entra tenant. It can receive Azure roles. An app registration stores an application's identity configuration; the associated service principal is the tenant-local identity you see as an enterprise application. For a single-tenant registration, the portal commonly creates both together. An app used by several tenants can have a service principal in each tenant that uses it.
One way for software to authenticate as an application is with a client secret; another is a certificate. Both require protection and a renewal plan. A service principal can also use a federated credential instead of a stored secret. Do not define “service principal” as “an app with a password.” The identity and its authentication method are separate choices.2
| Question | Storefront answer | What to check |
|---|---|---|
| Who is asking? | The storefront's workload identity | Which Azure host may use it? |
| How does it prove that? | Managed identity on a supported Azure host | Who can run code on that host or request tokens? |
| What may it read? | Storage Blob Data Reader on one account | Are there additional direct or inherited grants? |
How does the app work without a stored password?
A managed identity is a special service principal whose credentials Azure manages. A supported Azure host, such as App Service, lets its running workload request an Entra access token for a target service. The application uses that token with Azure Storage. The team does not put a long-lived client secret or storage key in the app's config.
- System-assigned
- Tied to one supported Azure resource. It is created when enabled and removed with that resource. Use it when that lifecycle fits and the host supports it.
- User-assigned
- A separate Azure resource that can be attached to more than one supported host and has its own lifecycle. Useful when identity must exist before a workload, be shared deliberately, or survive one host's replacement. Remove it when no longer needed.
Neither choice creates permission by itself. Give the identity a narrowly scoped role, such as Storage Blob Data Reader on the image account, then test the actual read. A managed identity removes a long-lived credential from application configuration; it does not make the host or token invulnerable. Someone who can run code in the workload may be able to request tokens under its identity. Limit who can deploy code and keep the identity's roles small.3
Respond to the exposed key
This simulation starts after a key appeared in a public config file. Retire the usable key, remove it from the app's configuration, choose a short-lived token, and see why the identity still needs a limited data role. The game timer is compressed for teaching; real token lifetimes vary. On a phone, swipe the board sideways or use the destination buttons.
Which method fits where the workload runs?
Do not rank all methods as one universal ladder. The host determines which credential-free option is available. For a supported workload on Azure, consider managed identity. For a GitHub Actions workflow outside the Azure host, consider workload identity federation. If a secret or certificate is necessary, store it securely, restrict access, monitor it and plan renewal. Never put it in source code.
- Federation
- A configured trust that lets an external workload present a short-lived identity token from its own platform to Entra ID. Entra validates that token and issues an Azure access token for a permitted identity. No long-lived client secret has to be stored in the workflow.
For GitHub Actions, the trust should identify the intended issuer, audience and subject—for example, a specific repository and protected environment or branch. A broad trust can let the wrong workflow ask for tokens. Federation also does not replace Azure RBAC: the identity used by the workflow still needs an appropriately scoped deployment role.4
Two workloads, two suitable methods
The storefront uses a managed identity to read product images from one storage account and, if required, a separate narrow permission to retrieve its own Key Vault secrets. The GitHub deployment workflow uses a federated trust to obtain Azure tokens without a stored client secret. Each identity gets only the roles and scopes its task needs. The team controls who can change the App Service code and who can trigger the trusted workflow.
Class Twenty-Three builds the GitHub federation path in detail. Here, retain the distinction: identity names the software, authentication proves it, and authorization limits what it may do.
Check the official explanations
Read managed identities, federation, and application objects and service principals. Compare the source's supported hosts and credential choices with the fictional design above.
Find a workload identity
Use a training App Service or VM that you are allowed to inspect. If you lack one, use the official diagrams and sketch the expected steps instead.
Open the resource's Identity page. Record whether it has a system-assigned identity, user-assigned identity, both or neither. Do not enable one in a shared environment without the owner's approval.
Open the identity's Azure role assignments. Identify the exact storage account or resource group scope and the role, if one exists. An enabled identity with no useful role cannot read the images just because it exists.
Locate the team's code path that requests the token, such as an Azure SDK credential. Confirm that no account key or client secret is embedded in the source or config. Do not print tokens into logs.
Choose system-assigned or user-assigned
One test App Service will be deleted after a week. Describe whether a system-assigned identity tied to that host fits and what role it would need.
Three replaceable App Services need one deliberately shared identity. Explain why a separately managed user-assigned identity might fit, and who will remove it and its grants when the project ends.
For both cases, explain what someone who can run code on the host might do with the identity. Name one way to limit that risk.
Inspect the trust without creating a secret
Find a training workflow's federated credential configuration, or read a sample from Microsoft Learn. Identify issuer, audience and subject. Which repository, branch or environment can present a matching token?
Find the Azure role assignment for the identity used by that workflow. Would its scope permit only the intended deployment? What happens if someone can modify the trusted workflow?
Do not generate a demo client secret to “compare” approaches. The comparison is whether a long-lived credential must be stored and rotated, not how it looks when printed.
Three places to check after removing a secret
The risk moves; it does not vanish.
Who can deploy or run code where the managed identity is available?
Could a valid access token appear in logs, traces or an exposed process?
What direct or inherited roles can the identity use, and at what scope?
A secure design checks all three and records who owns cleanup.
The repository contained a storage key
Do not stop at deleting a line. Tell the account owner, rotate or disable the exposed key through the incident process, find where it was used, review logs for misuse and replace the application's authentication path. Removing a file does not retract an already copied key or erase repository history.
Continue with a supplied build
Build an app with its own badge. In the identity lab, create the disposable host, enable its identity, grant a vault data role and deploy the supplied app. Expect HTTP 200 with referenceResolved true, without a secret in the response. Then explain each arrow using the identity, token and permission vocabulary above.
Check your understanding
Four graded drills and two unscored situations. Multi-select options shuffle; choose by meaning. Practice preserves your first-attempt score.
B. Managed identity gives the workload a way to authenticate without a stored client secret. Storage still checks authorization. Give it only the data role and scope needed, then test the read.
Think back to the badge: Azure issued it, but the stockroom has not been told to accept it. A successful token request and a failed blob read can both be true. Check the identity that the app actually used, its data role, scope and network route. Do not prove access by signing in as yourself instead of running the application.
C. A user-assigned identity has its own lifecycle and can be attached to multiple supported resources. That sharing is deliberate: review all hosts that can use it, the role scope, and who will retire it.
Each system-assigned identity belongs to its own host; it is not one identity you copy to three machines. A shared user-assigned identity can fit the stated replacement requirement, but every attached host becomes another place capable of using it. Sharing should be a reasoned design decision, with an owner for its grants and retirement.
The correct ideas are no stored app secret with managed identity, a separate authorization role, and secret-free federation for a trusted external workflow. An exposed key remains dangerous until rotated or disabled. A valid token can be misused during its lifetime, so protect the host and logs.
The repository leak and the authentication redesign are separate tasks. First retire the exposed key through the incident process; then prove the safer path works. An expiry time limits how long a stolen token remains useful, but does not make the current token harmless. Keep both tokens and long-lived credentials out of logs.
EXPOSED STORAGE KEY — RESPONSE PLAN
1. Tell the account owner and start the incident process.
2. Remove the key from the current config and deploy a safer path.
3. Leave the old key active; the new commit removed the leak.
4. Rotate or disable the exposed key and review for misuse.Line three. Earlier commits, forks, caches or copies may still contain the key. Removing the current line cannot revoke it. Rotate or disable it through the incident process, examine possible misuse and migrate the app to an identity-based path.
A teammate may say, “But the file is clean now.” Agree about the current file, then explain the copied value: a stranger does not need your latest commit to keep using a key they already saved. Coordinate rotation with the account owner and dependent applications. Review the possible use of the key as well as its removal.
Concede the confusion. “We enabled the identity, so why can’t the website read an image?” Enabling it gives the app an identity and a supported way to obtain a token. It does not assign a storage data role.
Walk one request. The app requests a token for Storage through its supported host. It presents the token with the image request. Storage checks who is asking and whether that identity has the necessary data permission. Choose the identity lifecycle deliberately and grant Blob Data Reader at the intended scope.
Offer a proof. Read the harmless training image as the application, not as your signed-in account. Check existing grants and confirm that its configuration has no storage key. Limit who may deploy code to the host: that code can use its identity.
Concede what a stored secret solves. A secret can let the workflow authenticate, but someone must protect and renew it. A service principal is the identity; the secret is only one possible credential.
Name the alternative. Review GitHub OIDC federation to an app registration or user-assigned managed identity. Match issuer, audience and subject to the intended repository and branch or protected environment. A token from another workflow should not satisfy that trust.
Offer a bounded deployment. Grant only the necessary Azure role at the intended scope. Control workflow changes and environment access, then run a successful deployment and a negative trust check. Federation removes the stored client secret; it does not remove the workflow’s privileges.
Five checks to carry into Class Ten
- A workload identity names software; the assigned role limits what it may do.
- App registrations, service principals and authentication credentials are related but different.
- Managed identity removes a long-lived app secret from config, not the need to protect tokens, hosts or role scope.
- System-assigned and user-assigned identities differ in lifecycle and sharing.
- Federation can replace a stored secret for a trusted external workflow; restrict the trust and its Azure role.
- If a key reaches a repository, treat copies and history as potentially exposed. See GitHub's sensitive-data removal guidance and the storage account owner's rotation procedure. ↩
- Microsoft distinguishes application objects and service principals and documents federated credentials. ↩
- The managed-identity overview explains the two lifecycles and token use. Security still depends on the host and assigned roles. ↩
- Microsoft's federation concepts explain the external issuer, token exchange and trust restrictions. ↩
Explain an application’s identity, token and permission separately, and choose a suitable managed-identity or federation path.
Play the lesson above to stamp this class.
Next, where everything you build actually lives — the network.
Next · Virtual Networks & Subnets →