Auth MechanicsAUTHENTICATION & AUTHORIZATION, FROM THE WIRE UP.
LESSON 02 OF 40

Check permission for the requested action.

A signed-in person may have permission to read an order without having permission to change it. Check both the action and the specific order.

Why this lesson?

A signed-in customer may read order 1042. They must not be able to cancel it when they have only read permission.

Learning goal and prerequisites
ONE NEW IDEA A signed-in person may have permission to read an order without having permission to change it. Check both the action and the specific order.
Review the previous lesson if any of these terms are new. The link below opens that lesson.
Request sequence Authorization sequence
STEP 01

Send an access credential

The application sends an access token to an application programming interface (API), which is a service endpoint used by other software. Assume the token was issued earlier. The API validates the token before trusting any information about the caller, target resource, or granted permissions.

Inspect request, response, and claims
Traffic inspector Examples only · not real requests
Try a failure scenario

↳ Change a condition

Read the detailed explanation
Key explanation

Why it exists, how it works, and where it fits

After an application knows who a caller is, it still needs to decide what that caller may do. Real systems have many actions and many resources. A person may be allowed to read one order but not cancel it, or may be allowed to view their own file but not another customer’s file. That is the problem authorization solves.

A scope is one way to describe granted access. For example, orders:read says that reading orders is within the grant. It does not automatically mean the caller may read every order. The application programming interface (API) still has to connect the request to trusted facts such as ownership, tenant, role, or another policy rule.

A good authorization decision therefore combines the caller, the action, the resource, and the policy. The API validates the credential first, then checks whether the requested operation is allowed for this specific resource. Only after all required checks pass should it return or change protected data.

This distinction matters because a valid token can still be insufficient. A token may be genuine but have the wrong scope, belong to the wrong tenant, or target the wrong resource. Authorization is the step that turns verified identity and permissions into a concrete allow-or-deny decision.

Check your understanding
Lesson checkpoint

Pass the lesson quiz

Answer every question correctly to unlock the next lesson. Retry as often as you need.

Glossary Definitions of technical terms