Refresh tokens granted for a DFP account apparently expire after a couple of days

[Edward D'Souza]

My application is acquiring an access and refresh token for a user's DFP account (using OAuth 2.0 flow with access_type='offline'). The refresh token is being used with the googleads python library (https://github.com/googleads/googleads-python-lib).

The problem is that the refresh token stops working after about 48 hours (and maybe sooner), and I get back the following response when trying to acquire a new access token using the saved refresh token:

Status code: 400
{
 "error": "invalid_grant",
 "error_description": "Bad Request"
}

Initially, up to a period of at least 3 hours, the refresh token works as expected, and I get back the following response:

{
 "access_token": "[-ed: actual token removed]",
 "token_type": "Bearer",
 "expires_in": 3600
}

I'm using the following python code to test acquiring a new access token using the refresh token:

import requests

token_url = "https://www.googleapis.com/oauth2/v3/token"

refresh_token = "xxx"
client_id = "xxx"
client_secret = "xxx"
grant_type = "refresh_token"

response = requests.post(token_url, dict(
    refresh_token=refresh_token,
    client_id=client_id,
    client_secret=client_secret,
    grant_type=grant_type,
    ))

print response.content

Why does the refresh token apparently expire after a couple of days?

[Nicholas Chen (DFP API Team)]

Hi,

My first question is - how many people do you have generating refresh tokens (as there is a limit to the number of concurrent tokens you can have for a user account)?

It sounds like you might be running over that limit - which sounds like an implementation issue - rather quickly if it's happening in 3 hours.

Best,
Nicholas Chen, DFP API Team

[Edward D'Souza]

There could easily be 10 concurrent refresh tokens being generated. The DFP account in question is a general account we use for testing our application in various environments. Do you know what the concurrent token limit is, or where it's documented?

[Nicholas Chen (DFP API Team)]

https://developers.google.com/accounts/docs/OAuth2

This actually falls on the OAuth2 team's implementation of how many refresh tokens you can maintain, but there are some best practice guidelines listed there.

Note, this is talk about refresh tokens (not access tokens).

Best,

Nicholas Chen, DFP API Team

[Mark Brady]

To avoid many users generating refresh tokens you could try my suggestion.

When creating a credential for a DFP network account go through the motions of getting a refresh token.

Once you get it you should save it along with the network id in some database table. you can store anything you want in a JSON field. That way any user wanted to use that network can programatically load that credential record and they will have access to the things they require.

A refresh token is only valid for 3600 however the DFP API automatically updates the token if it has expired - which kind of defeats the purpose of a refresh token but is great for us.

I have never used an access token when using the API. I don't even save it anywhere. I only ever use the refresh token in my communications.

Hope this helps

Mark

On Monday, January 12, 2015 at 1:57:08 PM UTC-5, Edward D'Souza wrote:

[Nicholas Chen (DFP API Team)]

Hi,

Just wanted to clear a few misconceptions up:

When creating a credential for a DFP network account go through the motions of getting a refresh token.

Correct! When first using our client libs, you'll want to go through the OAuth2 dance to get a refresh token for your client id / secret

Once you get it you should save it along with the network id in some database table. you can store anything you want in a JSON field. That way any user wanted to use that network can programatically load that credential record and they will have access to the things they require.

Sure, we don't really have any restrictions on where you store your creds as long as they stay a secret :) 

A refresh token is only valid for 3600 however the DFP API automatically updates the token if it has expired - which kind of defeats the purpose of a refresh token but is great for us.

Not quite. An access token is only valid for 3600 seconds, the refresh token shouldn't be replaced unless it's been invalidated because the client has generated too many refresh tokens. DFP doesn't automatically update the refresh token, we use the refresh token to request a new access token which is within spec. 

I have never used an access token when using the API. I don't even save it anywhere. I only ever use the refresh token in my communications.

If you're using one of our client libs, you're always using the access token, it's just taken care of in the background, which is why you might think you're only using the refresh token :)

Best,

Nicholas Chen, DFP API Team