The purpose of this lab is to intentionally construct and understand the minimum tenant infrastructure required to support real interactive user sign-in flows, so that future labs can examine:
- Delegated permission consent behavior
- User-issued access tokens
- Token claims and scopes
- Enterprise Application visibility and assignment
- Real sign-in logs and enforcement paths
- Conditional Access and authorization mechanics
This lab exists to enable all subsequent identity labs by creating a stable, inspectable, interactive identity surface inside the tenant.
No application code is required because Microsoft Entra ID governs identity, not application execution.
Microsoft Entra ID does not manage applications.
Microsoft Entra ID manages identity contracts that applications may use.
This lab builds and validates an interactive identity contract:
- a user can authenticate,
- a token can be issued,
- permissions can be evaluated,
- and enforcement can occur — even when no application code exists.
By the end of Lab 10, the tenant now contains:
-
An Application Registration
- Defines who the application is (identity paperwork)
- Declares redirect behavior for interactive sign-in
- Requests baseline delegated permissions
-
A Corresponding Enterprise Application (Service Principal)
- Represents the tenant-local instance of that identity
- Acts as the enforcement and assignment boundary
- Is what users are actually assigned to
An interactive sign-in contract defines whether and how a human user is allowed to authenticate interactively to an application using Microsoft Entra ID.
This contract is established entirely through Authentication configuration on the application registration.
No application code is required for the contract to exist.
SPA stands for Single-Page Application.
Declaring an SPA platform tells Microsoft Entra ID:
“This application will authenticate users directly from a browser-based client using OAuth 2.0 / OpenID Connect.”
Key implications:
- The client is browser-based
- Tokens are requested directly by the client
- No backend server is required to complete authentication
- The application is eligible for interactive OAuth flows
This declaration is about client behavior, not about whether an app actually exists.
The redirect URI defines:
“Where Microsoft Entra ID is allowed to send the user after successful authentication.”
Important characteristics:
- Must match exactly
- Is a hard security boundary
- Prevents tokens or authorization codes from being sent to untrusted locations
In this lab:
- A localhost redirect URI was used
- This simulates a browser receiving authentication responses
- The presence of the URI enables interactive sign-in, even without app code
Without a redirect URI:
- Interactive authentication is blocked
- Users cannot complete sign-in
- Tokens cannot be issued
By configuring an SPA platform, Microsoft Entra ID enables:
- Authorization Code Flow with PKCE (Proof Key for Code Exchange)
- The modern, secure OAuth flow for browser applications
- Uses short-lived authorization codes
- Prevents interception and replay attacks
This tells Entra ID:
“This application is allowed to participate in interactive OAuth authorization flows.”
Without OAuth flow enablement:
- The app may exist
- Users may be assigned
- Permissions may be defined
- But no interactive sign-in can occur
Before this configuration:
- You had an application identity (App Registration)
- You had a tenant-local instance (Enterprise Application)
- You had permissions and assignments
But you did not yet have permission for users to authenticate interactively.
This step converts the application from:
“An identity object with metadata”
into
“A valid OAuth client capable of real user sign-in”
No redirect URI and no OAuth flow means no interactive sign-in — regardless of permissions or assignments.
With the interactive sign-in contract in place, the tenant can now:
- Perform real user sign-ins
- Generate meaningful sign-in logs
- Enforce Conditional Access
- Issue delegated tokens with user context
This is why Lab 10 was required before moving forward.
-
Explicit User Assignment
- User 4 assigned to the Enterprise Application
- Visibility enabled so the app appears in MyApps
- Confirms the difference between:
- “app exists”
- “user can see and launch app”
-
User-Facing Evidence of Configuration
- Application appears in User 4’s MyApps portal
- Launch attempt fails (expected — no app code)
- Identity path succeeds (this is the point)
Before this lab:
- You could configure permissions abstractly
- You could define APIs and requests
- You could reason about tokens theoretically
But you could not:
- Observe real interactive sign-in behavior
- Validate user assignment visibility
- See how delegated permissions become real
- Inspect identity outcomes from a user’s perspective
After this lab:
- The tenant can issue real interactive user tokens
- Consent paths are now observable
- User-based authorization labs are unblocked
- Identity behavior can be tested without guesswork
This lab converts Entra ID from a static configuration exercise into a living identity system.
- App Registration = global identity definition
- Enterprise Application = tenant enforcement object
- Users are assigned only to Enterprise Applications
- Assignment alone does not guarantee MyApps visibility
- “Visible to users” must be explicitly enabled
- This is why User 4 initially saw nothing
- Redirect URIs do not require application code
- They define where Entra ID is allowed to return tokens
- Without them, interactive sign-in cannot complete
- The app fails to launch because no software exists
- The identity system worked correctly
- This confirms separation of identity from application runtime
This lab is the keystone for everything that follows:
- Delegated vs application permissions
- Consent prompts and storage
- Token inspection
- Conditional Access evaluation
- Graph access behavior
- Sign-in and audit logs
Without Lab 10, all of those topics remain abstract.
With Lab 10, they become observable, testable, and falsifiable.
Lab 10 was about building capability, not proving trivia.
You now own:
- an interactive identity surface,
- a user-visible enforcement boundary,
- and a tenant ready for real identity experimentation.
Only now does it make sense to proceed to Lab 11.