Google has recently added features to Google App Engine (GAE) to make it easier to use OAuth from a GAE app. These feature are only being made available at this time to get early feedback from the OAuth community. The APIs may change over time, and we may disable it at any time without notice.
Here is a summary of the new features: 1. If a GAE app wants to get a user's permission to access their data via a 3-legged-OAuth enabled API, such as GData or APIs from MySpace, Yahoo, Twitter, etc. The GAE URLFetch function now has a set of flags that offload almost all the OAuth security aspects to GAE. A similar feature<http://code.google.com/apis/gadgets/docs/oauth.html> was launched last year for gadgets. For more info see the section below on OAuth Proxy support. 2. A GAE app can also make a 2-legged-OAuth or signed-fetch called to an OAuth enabled API. Like with #1, the GAE URLFetch function how handles all the signature aspects. This feature has been available to OpenSocial gadgets since shortly after it was launched. It also works with the 2-legged-OAuth version of the Enterprise GoogleApps APIs<http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAuth>, but any Enterprise or Web2.0 developer can create their own OAuth enabled API to receive such a request and verify the source. If the GAE app is accessing the GData APIs for a Google Apps domain, the domain administrator can use the GoogleApps admin panel to specify that the GAE app can access particular GData APIs, such as Calendar but not Docs. For more info see the section below on OAuth Proxy support. 3. The reverse of #2 also works, i.e. a GAE app can expose a 2-legged-OAuth enabled API and can use a single GAE function call to verify the source of the requests. #2 & #3 can be combined to enable two GAE apps to communicate with each other while use OAuth for web-service authentication. Another option is for a Gadget to use signed-fetch to communicate with the GAE app's OAuth enabled endpoint. For more info see the section below on OAuth service-provider support. There are two related features under development which should be live very soon: 1. The reverse of #1 in the above list will also be supported, i.e. a GAE app can expose a 3-legged-OAuth enabled API. This feature and #1 above can be combined to enable two GAE apps to communicate with each other after getting the user's conent, or a Gadget could use the gadget oauth proxy<http://code.google.com/apis/gadgets/docs/oauth.html> to communicate with the GAE app. 2. The GoogleApps Provisioning API<http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_reference.html> has a list of users in a domain, as well as their group memberships. A 2-legged-OAuth version of that API is being made available, and then a GAE app could use #2 in the list above to connect to that API to perform functions like checking the group membership of the person logged into the GAE app. More information on the OAuth Proxy and and OAuth service-provider support is available at http://sites.google.com/site/oauthgoog/Home/gaeoauthproxy. We are hoping members of the OAuth community will help us test these features and provide feedback on how they should be enhanced before they are formally made available. Eric Sachs Product Manager, Google Security --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" 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/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
