You can't imagine how overjoyed I was to finally stumble on this post. I have a GAE/J app under development which is intended to be exclusively accessed by a Google Gadget. I've got everything working apart from the authentication. The standard GAE authentication by redirecting to a login page just doesn't play nice with gadgets from a user experience and UI perspective.
My ideal scenario is that the signup/registration process be as invisible as possible. If a user has logged in to google.com/ig and installed my gadget, there should ideally be no further authentication or authorisation required for him to start using my service. All I need to be able to do is reliably associate any request with a user. Ideally I will have access to the user's email address, but if the price of doing that is a user experience, then I can settle for prompting the user for his email address which I can store in Gadget prefs. Having tried all the alternatives, I figured that OAuth is probably the answer, but I am really struggling to get a toe hold on the technology. In particular I really can't figure out what the different roles of the actors are, and eg. is my requirement a 2-legged or 3- legged one. Do I need to care about SSO/OpenID. All the blueprints I can find deal with the use case of accessing Gdata APIs, which isn't quite what I'm after. Any dummy's guide hints would be gratefully received as to what OAuth steps I need to implement in my GAE. I've successfully got my gadget accessing Gdata docs list via Oauth, so I'm kinda OK with the client (consumer?) aspect. I've installed the provided OAuth servlet and configured that into my GAE app. So far so good. But what next? kind regards Roy On Nov 3, 8:09 pm, Eric Sachs <[email protected]> wrote: > 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_referenc...> > 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 athttp://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 -~----------~----~----~----~------~----~------~--~---
