The hip bone is connected to the thigh bone ....

The graphic below represents the 'chain of secrets' for OAuth - showing how it is the logical combination of a client & a user (as represented by their secrets) that are combined into OAuth tokens for use on API calls.

After authenticating to an OAuth Authorization Server with it's password (green 'Pwd'), a User grants to a given Client an authorization grant, as manifested in an authorization code (green 'Code').

An OAuth Client exchanges that code for a Refresh Token (Green 'Rt'), using its client secret (red 'Cs') on the request.

The OAuth Client can exchange the refresh token for Access Token (green 'At'), also using its client secret on the request.

The Access Token is then presented by the Client to the REST endpoint (yellow 'API') , as proof that the User has previously made the grant (ie gave their consent).

For native clients, it's unrealistic to expect that the app could be distributed (through an app store) with a secret (such as 'Cs') so instead the app can be distributed with a global Application Secret (red 'As'), this subsequently exchanged for a unique Cs (as in the dynamic registration spec).