DFA Reporting - OAuth: Refresh Token and Access Token - will these tokens expire?

[Mediaocean]

Hi -

 

Once these tokens are generated for a client secret, these token will never expire. Right?

 

Could you please confirm?

 

Thanks!

Kumaran Sivapunniyam

Mediaocean

 

 

[Joseph DiLallo (DFA API Team)]

Hey Kumaran,

Access tokens are short-lived tokens, lasting only an hour. Users are expected to generate new ones as necessary using their refresh tokens. Refresh tokens last forever UNLESS one of two things happens:

1. You explicitly revoke a refresh token, using either the OAuth 2.0 API or accounts.google.com
2. You generate too many refresh tokens for the same client ID. The exact limit is not shared but you should currently be safe generating on the order of 10s of refresh tokens. Just don't have an integration test generate a new refresh token every time your run your test suite. :-) If you do generate too many tokens, we will start to automatically revoke the old ones.

You can also have many access tokens active per refresh token. If you've got separate systems accessing the DFA API but not talking to each other, it's totally fine to share the same refresh token across them but have each one use its own access token. You probably don't want to go too crazy with this though; I wouldn't recommend having 1 access token per thread or anything like that.

Cheers,

- Joseph DiLallo, the DFA API Team

[Mediaocean]

Hi Joseph,

Thanks for the response!

We persist refresh and access tokens in to DB and  we are using .setCredentialStore() to pass them to Google for auth process.

I realized that access token gets refreshed automatically if I pass expired access token. So I modified my code to capture the new access token and use it for further calls. The blow code really works well. But the only thing is, .setCredentialStore() is deprecated in the current release. I did some research to replace it with latest code. no success. Could you pass me an alternate code snippet that could replace the below code.

Given the nature of our environment, we don't want to store the tokens  in file store.

flow = new GoogleAuthorizationCodeFlow.Builder(TRANSPORT, JSON_FACTORY, clientSecrets, SCOPES).setCredentialStore(new CredentialStore() {

public void store(String arg0, Credential credential) throws IOException {

//Reset the access token with this new access token and use it for further calls

moCredentialObjectFromDB.setAccessToken(credential.getAccessToken());

}

public boolean load(String arg0, Credential credential) throws IOException {

credential.setAccessToken(moCredentialObjectFromDB.getAccessToken());

credential.setRefreshToken(moCredentialObjectFromDB.getRefreshToken());

return true;

}

public void delete(String arg0, Credential arg1) throws IOException {

}

}).build();

Thanks!

Kumaran Sivapunniyam

Mediaocean

On Wednesday, August 14, 2013 2:32:33 PM UTC-4, Mediaocean wrote:

[Joseph DiLallo (DFA API Team)]

Hey Kumaran,

I'm not very familiar with this new API yet, sadly. I'm looking at what the AuthorizationCodeFlow is doing with the credentialDataStore (here) and it seems like your custom DataStore just needs to return a StoredCredential wrapping the credential you're retrieving from the database.

Wish I could help more,

- Joseph DiLallo, the DFA API Team