A token instead of a password
Before delegated-authorization frameworks were common, an application that needed to act on a user's behalf against another service typically just asked for that service's password directly — a practice that handed the application full account access, with no way to grant less and no way to revoke the application's access without changing the password for everything else too.
A delegated flow replaces that with a token, issued by the resource's own identity provider after the user approves a specific, disclosed request. The application never sees the user's actual credentials, and the token it receives can be scoped narrower than full account access and revoked independently of the user's password.
The framework doesn't decide how narrowly to scope
The flow itself is neutral about how much access gets requested — an application can ask for narrow, specific scope or broad, near-total access, and the framework accommodates either. The actual protection depends on the requesting application asking for only what its function needs, and on the user (or an administrator reviewing the request on their behalf) noticing when a request asks for more than the stated purpose justifies.
A token, once issued, is a bearer credential in most implementations — whoever holds it can use it. That makes how it's stored and transmitted by the receiving application just as consequential as how narrowly it was scoped in the first place.