Lab 09 — Custom API Permissions: Resource vs Client Separation (Summary)

What This Lab Actually Accomplished

This lab demonstrated the most important architectural rule in Microsoft Entra ID permissions:

Permissions are defined on the resource.
Permissions are requested by the client.

Everything we did reinforced this separation.

---

1. Resource-Side Authority (The API)

We created a custom API (Lab09 API Resource) and exposed it through Microsoft Entra ID.

Key points:

• The API defines its own permissions (for example: "Access as user").
• These permissions describe what the resource allows, not who can use them.
• Permission definitions live with the resource, not in the client and not in the tenant as free-floating objects.
• The resource exists independently of any client that may later request access.

This answers the question: “What actions does this resource support?”

---

2. Client-Side Intent (The Application)

We then configured an existing application (Lab08 AppCore) to request access to the API.

Key points:

• The application does not define permissions.
• It selects from permissions already defined by the resource.
• What the UI calls “Configured permissions” are actually configured permission requests.
• These requests can exist even when no consent has been granted.
• At this stage, nothing is enforceable and nothing runs.

This answers the question: “What does this client want to do?”

---

3. Consent, Tokens, and Why Nothing ‘Happened’ Yet

We intentionally stopped before runtime behavior.

Key points:

• No redirect URIs, no sign-in flow, no tokens were issued.
• Because no user signed in, no delegated consent occurred.
• Because no admin consent was applied, no application permissions were activated.
• This is expected and correct.
• Configuration alone does not produce access.

This reinforces a critical rule: Configuration defines capability and intent, not execution.

---

4. Why This Lab Is Complete (Even Without a Running App)

This lab was about structure, not execution.

It proved:

• Permissions exist before clients.
• Clients request permissions; they do not create them.
• “Configured permissions” ≠ “Granted permissions”.
• UI terminology can be misleading and must be interpreted architecturally.
• Runtime OAuth flows are a separate concern and belong in a separate lab.

Stopping here avoided unnecessary complexity and preserved conceptual clarity.

---

5. The Core Mental Model (Exam and Real-World)

When analyzing any Entra ID permission scenario:

1. Identify the resource and its defined permissions.
2. Identify the client and what it is requesting.
3. Determine whether consent has occurred (user or admin).
4. Determine whether tokens have been issued.
5. Only then consider runtime enforcement.

If any step is missing, access does not exist.

---

Final Verdict

This lab successfully established the foundational separation between:

• Resource authority
• Client intent
• Tenant consent state
• Runtime execution

That separation is the backbone of OAuth, Entra ID, and the SC-300 exam.

This was a strong, well-scoped lab.