Hi Michael, Thanks for your previous responses. We've been trying OAuth for a couple of days now and so far it's working great but I do have some questions that need to be addressed before we decide to ditch ClientLogin in favor or OAuth for our installed application.
1. The scopes that we are requesting access for are: - https://apps-apis.google.com/a/feeds/domain/ (AdminSettings API) - https://apps-apis.google.com/a/feeds/ (Provisioning API) (we tried https://apps-apis.google.com/a/feeds/user/ too) Now, the web page shown after the user has authenticated displays that we are requesting access to "Unknown" products. Are we using a wrong feed? We require read-only access to AdminSettings and read/write to Provisioning. How can we make the request so that the displayed product shows "AdminSettings" , "Provisioning", or any message that presents a less sketchy feeling than "Unknown"? 2. You mentioned that 3-legged OAuth access tokens can be revoked if needed. After authenticating I couldn't find the granted permissions in the web admin panel for revocation. How can this be accomplished?. 3. Can you provide more details about what it means for 3-legged OAuth tokens to be long lived. In which situations will it be required to obtain a new access token? Will it expire after a certain amount of time? 4. One last question, we need to know to which domain the user authenticated and the account name used. I've noticed a "user email" that contains the email the user used to authenticate but since it is not mentioned in the documentation I've seen, I'm not sure if it's an experimental feature that we can't rely on. Is this user email field guaranteed to be passed back to our application? Is it part of the protocol? Thanks for your help, Jorge On Wed, May 4, 2011 at 2:56 AM, Michael Manoochehri <[email protected]>wrote: > Hi Jorge: > > 1. No, your application can request access tokens with multiple scopes, > meaning that you can authorize access to all 3 APIs at once. > > 2. In the OAuth 1.0 flow, 3 Legged OAuth access tokens are long lived, so > you could have the user authorize access once, and then store the access > token for later use. The access token can later be revoked if need be. > > 3. Unfortunately, we currently have no sandbox or test accounts for use > with the Google Apps APIs. > > If you haven't already, check out the suggested OAuth 1.0 flow for > applications that cannot launch a web browser: > > http://sites.google.com/site/oauthgoog/UXFedLogin/nobrowser/input-capable-devices > > Michael > > -- > You received this message because you are subscribed to the Google Groups > "Google Apps Domain Information and Management APIs" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-apps-mgmt-apis?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Apps Domain Information and Management APIs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-apps-mgmt-apis?hl=en.
