Authentication and authorization

Four different questions

Identity proofing asks whether the claimed person or business is real. Authentication asks whether the person trying to sign in can present the expected proof. Authorization decides which records or actions that signed-in identity may access. Recovery decides how access is restored when the normal proof is lost.

Why the distinctions matter

A strong login does not prevent a permissions mistake from exposing another customer’s record. Correct permissions do not help when account recovery can be tricked. A rigorous identity check at enrollment does not stop session theft after login. Each layer needs its own controls and evidence.

A useful review question

When an account incident occurs, ask which boundary failed. Was the person never properly verified, was the login proof stolen, did the application grant too much access, or did recovery bypass the stronger controls? That answer points to a more useful fix than simply demanding a longer password.

Recovery is another authentication system

A service can deploy strong sign-in and still let a caller or email workflow reset the account with weaker evidence. Map recovery, device enrollment and support-assisted changes beside the main login. Ask who can approve a new authenticator, how the old one is removed and which notifications reach the account holder before a high-consequence change becomes final.

Review permission as the role changes

Authorization often drifts when a person changes teams, a vendor engagement ends or a service account gains another purpose. Periodic access review should compare the current business need with the actual permissions and retain an owner for exceptions. Authentication logs show that an identity signed in; they do not prove every action taken afterward was authorized for that identity.

Example: a valid login sees the wrong account

A customer signs in with the correct password and second factor, then changes an identifier in a request and sees another customer’s record. Authentication worked; authorization failed. Resetting the customer’s password would not repair the object-level access rule. The example shows why “the user was authenticated” is not a complete security conclusion and why the server must check permission for every sensitive object and action.

Evidence to keep distinct

Enrollment records support who was initially verified. Authentication records support which proof was presented. Session records support how access continued. Authorization and application logs support which actions were allowed. Support notes may explain recovery. Joining those sources can explain an incident, but one source should not be stretched into a claim about all four layers.