谷歌 OAuth 2.0：刷新access_token

Question

I have a server based application that will post appointment dates on a users google calendar.

The New User goes thru a process to grant my application permission to access their calendar. I have NOT yet acquired approval from google so I'm still under the 100 user limit (I'm around 30 users).

I use HTTP and have been supplying the following as part of my initial OAuth request:

sprintf(TM.txt, "code=%s&client_id=%s&client_secret=%s&redirect_uri=%s&grant_type=authorization_code",

The last few months - the process normally redirects the user to google where they enter their email and password and then back to my server with an access token AND a refresh token. (I use the presence of refresh token to determine if the server has long-term access).

Lately the initial request is NOT being redirected to google and the server is returned an access token but NOT a refresh token.

Searching stackoverflow for past posts, I found recommendations to add the following to the request but no refresh token is returned: &access_type=offline&prompt=consent

Questions

1. Has something changed in the request process?

2. What am I missing to receive a refresh token as I had in the past?

3. I know that if a refresh token was grated in the past - a new one can not be reacquired until the user kills the original approval by going to:

   https://security.google.com/settings/security/permissions?pli=1

I have looked at these permissions for users that we have acquired permission and have a refresh token - but I do NOT see my application stated as a Third-Party App. How should my App appear so that it could be dismissed if that action was required?

Thanks

This is the code that has been working for 3 months:

sprintf(TM.txt, "code=%s&client_id=%s&client_secret=%s&redirect_uri=%s&grant_type=authorization_code",
    JSTR *Code, 
    "323191532401-fcagbr2kfmofgil2i2qch53p1whe27g9.apps.googleusercontent.com",
    "j3dIGjj-c5d17bE-HVb2d67R",
    "https://knowledgeispower.biz:8888/GoogleOuath" );

I have changed the values above so they are not the actual ones used.

Answer 1

It's unclear what you mean by "initial OAuth request". The OAuth2 process is as follows:

• you redirect your user to the authorization URL (the authorization request)
• your user is redirected by Google to your redirect URL with a code
• you make a direct HTTP request to the token URL (the token request) with the code

Assuming that what you meant by "initial OAuth request" is the authorization request , the structure of your authorization URL is incorrect:

• You should not include a code parameter in the authorization URL (the code is returned to your redirect_uri as a query parameter to be used in the token request. As a note, I'm not sure what this value even is)
• You should not include the client_secret in the authorization URL. The client secret is meant to be a secret, known only by your application. If you've been including it in the URL, you should assume it is compromised, and you'll need new credentials from Google. The client_secret should only be included in server-side requests to Google to authorize your application.
• You must include a scopes parameter. This tells Google what permissions your application is requesting
• You must include access_type=offline if you need a refresh token. Without it, Google will not return one.
• You should include prompt=consent if you may have requested access from this user before, but have not stored a refresh token for them. With prompt=consent , Google will generate and return another refresh token to your application, even if the user has previously authorized it.

If, on the other hand, what you meant by "initial OAuth request" is the token request , then the issue is likely that you are adding the prompt and access_type parameters to the token request, rather than the authorization request (where they are required).

You might also consider using a managed OAuth provider, like Xkit (where I work), for something like this. With a managed provider, you won't have to worry about Google changing their parameters, everything is handled for you. Just one request gets you an access token that always works.