Authentication vs Authorization: Read the Evidence Before Explaining Access · SC-900

The direct answer is a distinction, not a diagnosis

Authentication proves an identity; authorization specifies what that party may do with particular data or resources. Successful sign-in is therefore useful evidence, but it is not a complete permission statement. To explain an access result, ask what the evidence actually establishes. If all you know is that sign-in succeeded, the permission for a particular action remains a separate question. This guide teaches conceptual reasoning from fictional evidence, rather than troubleshooting a real tenant.

The distinction also prevents the reverse error. An application refusing an action does not, by itself, prove that a password or biometric check failed. A scenario may explicitly give successful authentication and a missing permission. Another scenario may leave the cause unknown. Preserve that difference instead of supplying a familiar explanation without evidence. In a foundational question, the stated facts—not a preferred service name—must do the work.

Build a small evidence ledger

Use three columns: identity evidence, applicable access conditions, and permitted action/target. In the first column, record the verification actually described. In the second, record any stated policy conditions such as a requirement for MFA. In the third, record the action and resource covered by the permission. Leave an unsupplied cell unknown. An unknown is not automatically a denial, approval, or configuration defect; it is a limit on what you can conclude.

Conditional Access belongs to the policy-condition discussion: it combines signals and can require an action when a condition applies. A role assignment concerns permissions within its scope. These can participate in the same access story without becoming the same evidence. The diagram is a checklist of questions, not a promise that every application or protocol always executes three independent screens in that order. A real system can present several checks in one apparent user flow.

Worked evidence case: the exhibition invitation

Fictional case: an exhibition coordinator receives an invitation request from a volunteer. One note says the volunteer completed the organization’s identity check. A second note says the volunteer should help prepare exhibit descriptions. Nobody has supplied the application’s allowed-action list or a record showing permission for publishing the descriptions. The coordinator wants to approve a statement that the volunteer is already authorized to publish. First accept the identity note for what it establishes. Next separate a description of the intended job from evidence that the permission has actually been granted.

The supported conclusion is narrower than either automatic approval or an invented diagnosis: identity verification is known, while the publishing permission has not been established by the supplied notes. Ask for the applicable action/target permission evidence. Do not assert that the volunteer has no possible permission merely because it was not included in the story. Likewise, do not promote a job description into an actual grant. The ledger is useful precisely because it can represent these different kinds of uncertainty.

Now add a new fictional fact: the application record permits editing draft descriptions but does not include publishing them. The question has changed. There is now a specific action boundary to compare with the requested publication. A successful identity check still does not widen that boundary. Check the reasoning by changing the requested action from publish to edit draft: the same permission record supports a different conclusion for that narrower action. The result follows the explicit scope, not a general label such as trusted volunteer.

Stronger proof does not enlarge a permission

MFA concerns authentication factors. The documented categories include something known, something held, and a biometric characteristic. Do not infer the number of factors from the number of visible prompts. Passwordless is also not a synonym for single-factor: the retained reference describes passkeys with device biometrics or PIN as a configuration that can serve as MFA. State that configuration rather than claiming that every passwordless method is automatically multifactor.

These details change what identity-proof evidence can mean; they do not, by themselves, add a publishing action to the exhibition record. Similarly, an additional authentication challenge can be a stated access condition without being the permission record for a target. Keep both conclusions: the verification may be stronger, and the action scope still needs its own evidence. There is no need to weaken authentication or grant a broad administrator identity to explain this distinction.

Read the target behind a role name

For Microsoft administrative examples, also identify which resource a role governs. Entra directory roles and Azure-resource roles have different targets and do not span both systems by default. Evidence of a directory administration role is not enough to establish a resource-management action in an Azure scope. The purpose of this comparison is to ask for the relevant target and action, not to teach elevation steps or assume that every organization uses an identical role arrangement.

Apply the same discipline to an application’s own permission record. A permission explicitly limited to a training project cannot be used as evidence about a separate target without an additional stated grant. This is an inference from the fictional scope, not a claim that a named cloud feature silently changes permissions. Use the two application checks below before reviewing their answers. Return to the complete Conditional Access and role-scope lesson for the sequenced method, then compare your reasoning with the separate formal tasks. The article’s evidence case is a different exercise from those practice items.