Lab 02 - Controlled OAuth Consent Checkpoint
Goal
Understand how OAuth consent changes the authorization surface without teaching students to run phishing against real users or external tenants.
Preconditions
- Use only the instructor-provided training tenant.
- Use only the instructor-provided controlled application.
- Do not send consent links to anyone outside the class environment.
- Do not request application permissions or tenant-wide admin consent as a
student exercise.
Scenario
The instructor provides a controlled application that requests low-risk delegated Microsoft Graph permissions. Students inspect the consent experience, note the requested access, and map the resulting authorization path.
Steps
- Open the instructor-provided sign-in URL.
- Before accepting anything, record:
- Application name
- Publisher information
- Requested delegated permissions
- Whether admin consent is required
- Compare the requested permissions against the source map.
- If the instructor authorizes the class to proceed, complete the sign-in in
the training tenant.
- Discuss what a defender should review:
- Enterprise application / service principal
- OAuth permission grant
- Sign-in record
- Consent or admin-consent request state
Learning Observations
Students should be able to explain:
- Why OAuth consent can create access without stealing a password.
- Why delegated permissions are still constrained by the signed-in user's
privileges.
- Why application permissions require stricter review than delegated
permissions.
- Which tenant settings can restrict or route user consent for review.
No flag, screenshot upload, log export, or tool output submission is required. The learning target is whether students can explain the consent and permission boundary.
Cleanup
The instructor revokes grants and removes the controlled application after the exercise. Students do not perform tenant cleanup unless explicitly assigned.
Sources
MS-CONSENTMS-USER-CONSENTMS-ADMIN-CONSENT-WORKFLOWMS-GRAPH-APPROLE
Original Markdown source
# Lab 02 - Controlled OAuth Consent Checkpoint
## Goal
Understand how OAuth consent changes the authorization surface without teaching
students to run phishing against real users or external tenants.
## Preconditions
- Use only the instructor-provided training tenant.
- Use only the instructor-provided controlled application.
- Do not send consent links to anyone outside the class environment.
- Do not request application permissions or tenant-wide admin consent as a
student exercise.
## Scenario
The instructor provides a controlled application that requests low-risk
delegated Microsoft Graph permissions. Students inspect the consent experience,
note the requested access, and map the resulting authorization path.
## Steps
1. Open the instructor-provided sign-in URL.
2. Before accepting anything, record:
- Application name
- Publisher information
- Requested delegated permissions
- Whether admin consent is required
3. Compare the requested permissions against the source map.
4. If the instructor authorizes the class to proceed, complete the sign-in in
the training tenant.
5. Discuss what a defender should review:
- Enterprise application / service principal
- OAuth permission grant
- Sign-in record
- Consent or admin-consent request state
## Learning Observations
Students should be able to explain:
- Why OAuth consent can create access without stealing a password.
- Why delegated permissions are still constrained by the signed-in user's
privileges.
- Why application permissions require stricter review than delegated
permissions.
- Which tenant settings can restrict or route user consent for review.
No flag, screenshot upload, log export, or tool output submission is required.
The learning target is whether students can explain the consent and permission
boundary.
## Cleanup
The instructor revokes grants and removes the controlled application after the
exercise. Students do not perform tenant cleanup unless explicitly assigned.
## Sources
- `MS-CONSENT`
- `MS-USER-CONSENT`
- `MS-ADMIN-CONSENT-WORKFLOW`
- `MS-GRAPH-APPROLE`