Handling Authentication (OpenId) with OAuth on Google App Engine (two questions)
Having just implemented this, I have a pretty basic question about how authentication and oauth work together.  I have a sample web app client (ckclient) that accesses a REST API (commitapi) for managing their commitments.  This follows the model of having an app like LinkedIn displaying a user's Tweets (via Twitter) as described in: http://www.slideshare.net/coldfumonkeh/oauth-demystified-hopefully

In my simple app, a user goes to the web app client and asks to see their commitments.  I am using Restlet and the user is redirected to a page where they can choose their OpenId provider and login.   They are they redirected to a page where they can approve access to their commitment resources.  Everything works fine.  

But, the web app client doesn't know who the user is!   All the authentication is done with the REST API, not with the web app client.  

So my first question is... is this a bug or a feature?  

My guess at the answer is that this is a "feature" - that is the way Oauth works - you don't WANT the web app client to know the userid/email address stored with the resource server (commitkeeper in my case, Twitter in the slideshare above).  

If that is correct, then if I want the web app client to know who the user is, the web app client should provide user authentication.  Since I am using Google's UserService on the server side, I also implemented UserService based authentication on the web app client.  And now, if the user also does the web app client authentication, then the web app client has the identity of the user.  So that is all good.  

Combining these two also works - but I can't quite understand why.

1. On the web app, I login through Google's userService (technically with a GaeAuthenticator, that only uses Google accounts).  Now the web app knows who I am and can display my email address.
2. From the web app, I ask the server for my commitments.  The server responds by giving me the login page where I can pick my OpenId provider.

2a. If I pick Google, the UserService seems to know that I have already logged in through the web app and shows me my commitments.

2b. If I pick Yahoo (or something else), I have to authenticate with Yahoo and then I am shown the commitments for that Yahoo user.
This all seems fine to me - except for how does the UserService know that I already logged in?  The webclient is at x.appspot.com and the server is at y.appspot.com.  Is the answer as simple as the UserService is integrated across all of appspot.com?  

In any case, thanks to anyone who can answer these two questions - or just confirm that I am on the right path.

Thanks!
RB

(Note: I am using Google's UserService to create the login urls, my web app client and resource server are on appspot, using Federated Authentication, and all this is Java).
Handling Authentication (OpenId) with OAuth on Google App Engine (two questions)
===

Having just implemented this, I have a pretty basic question about how authentication and oauth work together.  I have a sample web app client (ckclient) that accesses a REST API (commitapi) for managing their commitments.  This follows the model of having an app like LinkedIn displaying a user's Tweets (via Twitter) as described in: http://www.slideshare.net/coldfumonkeh/oauth-demystified-hopefully

In my simple app, a user goes to the web app client and asks to see their commitments.  I am using Restlet and the user is redirected to a page where they can choose their OpenId provider and login.   They are they redirected to a page where they can approve access to their commitment resources.  Everything works fine.  

But, the web app client doesn't know who the user is!   All the authentication is done with the REST API, not with the web app client.  

So my first question is... is this a bug or a feature?  

My guess at the answer is that this is a "feature" - that is the way Oauth works - you don't WANT the web app client to know the userid/email address stored with the resource server (commitkeeper in my case, Twitter in the slideshare above).  

If that is correct, then if I want the web app client to know who the user is, the web app client should provide user authentication.  Since I am using Google's UserService on the server side, I also implemented UserService based authentication on the web app client.  And now, if the user also does the web app client authentication, then the web app client has the identity of the user.  So that is all good.  

Combining these two also works - but I can't quite understand why.

1. On the web app, I login through Google's userService (technically with a GaeAuthenticator, that only uses Google accounts).  Now the web app knows who I am and can display my email address.
2. From the web app, I ask the server for my commitments.  The server responds by giving me the login page where I can pick my OpenId provider.

2a. If I pick Google, the UserService seems to know that I have already logged in through the web app and shows me my commitments.

2b. If I pick Yahoo (or something else), I have to authenticate with Yahoo and then I am shown the commitments for that Yahoo user.
This all seems fine to me - except for how does the UserService know that I already logged in?  The webclient is at x.appspot.com and the server is at y.appspot.com.  Is the answer as simple as the UserService is integrated across all of appspot.com?  

In any case, thanks to anyone who can answer these two questions - or just confirm that I am on the right path.

Thanks!
RB

(Note: I am using Google's UserService to create the login urls, my web app client and resource server are on appspot, using Federated Authentication, and all this is Java).