OAuth isn't really focused on use cases like yours. Normally, the authenticating client (in your case, the backend service) does not ever see, much less store, the password. For example, if I got to site https://oauth_sso.example.com/ and it offers me to sign in with Google, when I click that button the page into which I'm entering my Google credentials is a Google page, not an oauth_sso.example.com page (at least, it is supposed to be; watch for phishing attempts!). Google (the "identity provider") then confirms that I want to give oauth_sso.example.com (the "service provider") access to my Google identity (and possibly also other stuff, like contacts) and directs my browser back to https://oauth_sso.example.com with a token that the site can use to get my identity from Google.
It would be very inconvenient for the user to be re-prompted for their password all the time in a scenario like this, but it would also be a bad idea for the identity provider (Google) to need to look up whether the user has granted the service provider access to their account on every request (too many DB hits, makes scaling and using distributed systems really hard). As a compromise, the site gets a short-lived Access token (usually sent in a cookie or Bearer HTTP header) that can be used without any database hits but contains a signed timestamp so the server will reject it after a few minutes, and a refresh token that does cause a database hit (and will be rejected if the user has decided to revoke the service provider's access to their identity) but that is long-lived.