Re: OAuth2 in the new Java client library
The refresh token is the long-lived token you are looking for, so there should be no need to use ClientLogin. When your access token expires, use the refresh token to get a new access token. More details at: http://code.google.com/p/google-api-java-client/wiki/OAuth2 -- Yaniv On Thursday, September 27, 2012 2:24:50 PM UTC-4, j.e.frank wrote: > > I'm looking at migrating to the new Java client library as part of the > upgrade from v201109. One thing I thought was going to be a benefit of > this migration was long-lived access tokens, to enable long-running > services to use the API without having to worry about refreshing the > ClientLogin token. Now that I've done some more digging, it appears that > OAuth2 doesn't have long-lived tokens. Instead, you get an access token > and a refresh token, and there is some way that an expired access token > gets refreshed behind the scenes. > > I'm unclear on the implications of this for how I can deploy multiple > services that use the API without any user interaction. I have > successfully followed the OAuth2 example to get an authorization code using > a browser, and then I can take that code and get a credential with an > access and refresh token. Subsequently, I can create an OAuth2 credential > from these 2 tokens, without using the browser to get a new authorization > code. However, this doesn't work after some period of time -- I have to > start over and get a new authorization code using the browser. I've seen > reference to the CredentialsStore where you keep track of new > access/refresh tokens as they change, which would be fine for a single > service to manage. But with multiple services, would I need a centralized > CredentialsStore that they would all share, so that each one gets the > latest token? That's a non-starter for me. Is there something I'm missing > about how I can use OAuth2 with multiple long-lived services? Otherwise I > am going to continue with ClientLogin, and give up on my dream of > non-expiring tokens. Or is there some way of re-obtaining an authorization > token without user interaction? > -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
Re: OAuth2 in the new Java client library
Does anyone know of an example using a Service Account to access the AdWords API? On Thursday, September 27, 2012 4:06:50 PM UTC-4, j.e.frank wrote: > > Most services do have a shared database, but not all of them. > > I continued investigating this issue, and I've also tried the Service > Account approach which uses a private key instead of getting an > authorization through a browser URL. However, this keeps giving me a "bad > grant" exception if I try to actually use the credential, so I am not sure > what I am doing wrong there. > > On Thursday, September 27, 2012 3:34:38 PM UTC-4, Oliver wrote: >> >> Excellent questions, and I hope someone can answer them soon. >> >> Do your servcies not access a shared database to store a common token to >> be used by all services? >> >> Oliver >> >> On Thursday, September 27, 2012 7:24:50 PM UTC+1, j.e.frank wrote: >>> >>> I'm looking at migrating to the new Java client library as part of the >>> upgrade from v201109. One thing I thought was going to be a benefit of >>> this migration was long-lived access tokens, to enable long-running >>> services to use the API without having to worry about refreshing the >>> ClientLogin token. Now that I've done some more digging, it appears that >>> OAuth2 doesn't have long-lived tokens. Instead, you get an access token >>> and a refresh token, and there is some way that an expired access token >>> gets refreshed behind the scenes. >>> >>> I'm unclear on the implications of this for how I can deploy multiple >>> services that use the API without any user interaction. I have >>> successfully followed the OAuth2 example to get an authorization code using >>> a browser, and then I can take that code and get a credential with an >>> access and refresh token. Subsequently, I can create an OAuth2 credential >>> from these 2 tokens, without using the browser to get a new authorization >>> code. However, this doesn't work after some period of time -- I have to >>> start over and get a new authorization code using the browser. I've seen >>> reference to the CredentialsStore where you keep track of new >>> access/refresh tokens as they change, which would be fine for a single >>> service to manage. But with multiple services, would I need a centralized >>> CredentialsStore that they would all share, so that each one gets the >>> latest token? That's a non-starter for me. Is there something I'm missing >>> about how I can use OAuth2 with multiple long-lived services? Otherwise I >>> am going to continue with ClientLogin, and give up on my dream of >>> non-expiring tokens. Or is there some way of re-obtaining an authorization >>> token without user interaction? >>> >> -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
Re: OAuth2 in the new Java client library
Most services do have a shared database, but not all of them. I continued investigating this issue, and I've also tried the Service Account approach which uses a private key instead of getting an authorization through a browser URL. However, this keeps giving me a "bad grant" exception if I try to actually use the credential, so I am not sure what I am doing wrong there. On Thursday, September 27, 2012 3:34:38 PM UTC-4, Oliver wrote: > > Excellent questions, and I hope someone can answer them soon. > > Do your servcies not access a shared database to store a common token to > be used by all services? > > Oliver > > On Thursday, September 27, 2012 7:24:50 PM UTC+1, j.e.frank wrote: >> >> I'm looking at migrating to the new Java client library as part of the >> upgrade from v201109. One thing I thought was going to be a benefit of >> this migration was long-lived access tokens, to enable long-running >> services to use the API without having to worry about refreshing the >> ClientLogin token. Now that I've done some more digging, it appears that >> OAuth2 doesn't have long-lived tokens. Instead, you get an access token >> and a refresh token, and there is some way that an expired access token >> gets refreshed behind the scenes. >> >> I'm unclear on the implications of this for how I can deploy multiple >> services that use the API without any user interaction. I have >> successfully followed the OAuth2 example to get an authorization code using >> a browser, and then I can take that code and get a credential with an >> access and refresh token. Subsequently, I can create an OAuth2 credential >> from these 2 tokens, without using the browser to get a new authorization >> code. However, this doesn't work after some period of time -- I have to >> start over and get a new authorization code using the browser. I've seen >> reference to the CredentialsStore where you keep track of new >> access/refresh tokens as they change, which would be fine for a single >> service to manage. But with multiple services, would I need a centralized >> CredentialsStore that they would all share, so that each one gets the >> latest token? That's a non-starter for me. Is there something I'm missing >> about how I can use OAuth2 with multiple long-lived services? Otherwise I >> am going to continue with ClientLogin, and give up on my dream of >> non-expiring tokens. Or is there some way of re-obtaining an authorization >> token without user interaction? >> > -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
Re: OAuth2 in the new Java client library
Excellent questions, and I hope someone can answer them soon. Do your servcies not access a shared database to store a common token to be used by all services? Oliver On Thursday, September 27, 2012 7:24:50 PM UTC+1, j.e.frank wrote: > > I'm looking at migrating to the new Java client library as part of the > upgrade from v201109. One thing I thought was going to be a benefit of > this migration was long-lived access tokens, to enable long-running > services to use the API without having to worry about refreshing the > ClientLogin token. Now that I've done some more digging, it appears that > OAuth2 doesn't have long-lived tokens. Instead, you get an access token > and a refresh token, and there is some way that an expired access token > gets refreshed behind the scenes. > > I'm unclear on the implications of this for how I can deploy multiple > services that use the API without any user interaction. I have > successfully followed the OAuth2 example to get an authorization code using > a browser, and then I can take that code and get a credential with an > access and refresh token. Subsequently, I can create an OAuth2 credential > from these 2 tokens, without using the browser to get a new authorization > code. However, this doesn't work after some period of time -- I have to > start over and get a new authorization code using the browser. I've seen > reference to the CredentialsStore where you keep track of new > access/refresh tokens as they change, which would be fine for a single > service to manage. But with multiple services, would I need a centralized > CredentialsStore that they would all share, so that each one gets the > latest token? That's a non-starter for me. Is there something I'm missing > about how I can use OAuth2 with multiple long-lived services? Otherwise I > am going to continue with ClientLogin, and give up on my dream of > non-expiring tokens. Or is there some way of re-obtaining an authorization > token without user interaction? > -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
OAuth2 in the new Java client library
I'm looking at migrating to the new Java client library as part of the upgrade from v201109. One thing I thought was going to be a benefit of this migration was long-lived access tokens, to enable long-running services to use the API without having to worry about refreshing the ClientLogin token. Now that I've done some more digging, it appears that OAuth2 doesn't have long-lived tokens. Instead, you get an access token and a refresh token, and there is some way that an expired access token gets refreshed behind the scenes. I'm unclear on the implications of this for how I can deploy multiple services that use the API without any user interaction. I have successfully followed the OAuth2 example to get an authorization code using a browser, and then I can take that code and get a credential with an access and refresh token. Subsequently, I can create an OAuth2 credential from these 2 tokens, without using the browser to get a new authorization code. However, this doesn't work after some period of time -- I have to start over and get a new authorization code using the browser. I've seen reference to the CredentialsStore where you keep track of new access/refresh tokens as they change, which would be fine for a single service to manage. But with multiple services, would I need a centralized CredentialsStore that they would all share, so that each one gets the latest token? That's a non-starter for me. Is there something I'm missing about how I can use OAuth2 with multiple long-lived services? Otherwise I am going to continue with ClientLogin, and give up on my dream of non-expiring tokens. Or is there some way of re-obtaining an authorization token without user interaction? -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
