Browsing through various APIs to interact with Google OAuth, all of them require client credentials (i.e. id and secret) along with a refresh token in order to obtain a fresh access token.

What exactly is the point of the refresh token in this case? Since the client credentials along with various grant metadata (e.g. scope) in themselves are sufficient to obtain an access token, a refresh token seems to add very little.

EDIT: This was a misconception, the client credentials here identify the OAuth2 application while the refresh token is that of the user granting permissions to that user; see obtaining OAuth2.0 access tokens.

CodePudding user response：

IdPs differ in whether they treat OAuth clients as principals or not. Some IdPs allow OAuth clients to act on their own behalf: With AD FS, for example, you can let a client authenticate using a client ID, secret, and the OAuth client credentials grant and obtain an access token that identifies the OAuth client. No users involved.

Google doesn't support client credential grants, and there's no way to obtain an access token for a client. Instead, you use OAuth clients to authenticate a user or a service account. The resulting access token then identifies the user or service account, not the client.

Since the client credentials along with various grant metadata (e.g. scope) in themselves are sufficient to obtain an access token, a refresh token seems to add very little.

The refresh token is critical -- it's a form of credential that's issued after a user has successfully completed a (browser-based) OAuth authorization flow. The refresh token is issued to the user, but bound to the client. That means:

• Authenticating using a refresh token results in an access token (and maybe an ID token) that identifies the user, not the client.
• You can only use the refresh token in combination with the client ID that was used to obtain the refresh token. A refresh token is useless if you don't know which client ID to use it with.