Permissions relate subjects, objects and operations
A user may be permitted to read one file without modifying or deleting it. Authorization needs the operation and object, not just an unscoped approved flag. A service acting for an organization can also be a subject.
Authentication supplies account or claimant evidence; authorization combines relevant information with policy. Attribute-based rules need not name every person individually. Permission for the present request follows those rules rather than the mere fact that login succeeded.
References: [1]
Delegation need not disclose full account credentials
OAuth separates resource owner, client, authorization server and resource server. A client obtains an access token through authorization, and the resource server validates its use. Delegating limited access can thereby differ from handing the client the account password.
Requested scope is not necessarily granted scope. RFC 6749 lets the authorization server restrict it according to policy or owner instructions and requires reporting a changed scope. Requesting read and write does not establish that the issued token has both.
References: [2]
A decision must be enforced at the resource
Permission decisions need enforcement on the actual operation. NIST distinguishes policy decision and enforcement functions, which may reside in separate components. A decision generated at one entry point does not protect another entry point that ignores it.
OAuth security practice also restricts target servers, resources and actions, with resource servers checking applicability for each request. A correctly signed token meant for another service, or restricted to reading, does not thereby authorize a local write.