Try to check if you follow the steps/process here in this documentation.
1. Register your application as an installed application
2. Request an access token
3. User consent decision
- In this step, the user decides whether to grant your application the ability to make API requests that are authorized as the user. Google's authorization server displays the name of your application and the Google API services that it is requesting permission to access with the user's authorization credentials. The user can then consent or refuse to grant access to your application.
4. Handle response from Google
5. Exchange authorization code for refresh and access tokens
6. Process response and store tokens
Here, Google will respond to your POST request by returning a JSON object that contains a short-lived access token and a refresh token.
{
"access_token" : "ya29.AHES6ZTtm7SuokEB-RGtbBty9IIlNiP9-eNMMQKtXdMP3sfjL1Fc",
"token_type" : "Bearer",
"expires_in" : 3600,
"refresh_token" : "1/HKSmLFXzqP0leUihZp2xUt3-5wkU7Gmu2Os_eBnzw74"
}
NOte: Your application should store both values in a secure,
long-lived location that is accessible between different invocations
of your application. The refresh token enables your application to
obtain a new access token if the one that you have expires. As such,
if your application loses the refresh token, the user will need to
repeat the OAuth 2.0 consent flow so that your application can obtain
a new refresh token.
Access tokens periodically expire, so it need to be refreshed. When an access token expires, your application may be able to use a refresh token to obtain a new, valid access token. Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process.
Note that tokens might stop, no longer work or
expire
if:
The user has revoked access.
The token has not been used for six months.
The user account has exceeded a certain number of token requests.