これを実装したばかりなので、認証と oauth がどのように連携するかについて、かなり基本的な質問があります。コミットメントを管理するために REST API (commitapi) にアクセスするサンプル Web アプリ クライアント (ckclient) があります。これは、LinkedIn のようなアプリで (Twitter 経由で) ユーザーのツイートを表示するモデルに従います。
私の単純なアプリでは、ユーザーが Web アプリ クライアントに移動し、コミットメントを確認するよう求めます。Restlet を使用していますが、ユーザーは OpenId プロバイダーを選択してログインできるページにリダイレクトされます。コミットメント リソースへのアクセスを承認できるページにリダイレクトされます。すべて正常に動作します。
しかし、Web アプリ クライアントはユーザーが誰であるかを知りません。すべての認証は、Web アプリ クライアントではなく、REST API で行われます。
だから私の最初の質問は...これはバグですか、それとも機能ですか?
私の推測では、これは「機能」であり、それが Oauth の仕組みです。リソース サーバーに保存されているユーザー ID/メール アドレスを Web アプリ クライアントに知られたくありません (私の場合はコミットキーパー、Twitter は上記のスライドシェア）。
それが正しければ、Web アプリ クライアントにユーザーを認識させたい場合、Web アプリ クライアントはユーザー認証を提供する必要があります。サーバー側で Google の UserService を使用しているため、Web アプリ クライアントにも UserService ベースの認証を実装しました。ここで、ユーザーが Web アプリ クライアント認証も行う場合、Web アプリ クライアントはユーザーの ID を持ちます。それで、それはすべて良いことです。
これら 2 つを組み合わせても機能しますが、その理由はよくわかりません。
- Web アプリでは、Google の userService を介してログインします (技術的には、Google アカウントのみを使用する GaeAuthenticator を使用します)。これで、Web アプリは私が誰であるかを認識し、私のメール アドレスを表示できるようになりました。
- Web アプリから、サーバーにコミットメントを要求します。サーバーは、OpenId プロバイダーを選択できるログイン ページを表示して応答します。
2a. Google を選択すると、UserService は、私が Web アプリから既にログインしていることを認識しているようで、私のコミットメントを表示します。
2b. Yahoo (またはその他) を選択した場合、Yahoo で認証する必要があり、その Yahoo ユーザーのコミットメントが表示されます。これはすべて問題ないように思えますが、UserService は私が既にログインしていることをどのように認識しているのでしょうか? Web クライアントは x.appspot.com にあり、サーバーは y.appspot.com にあります。答えは、UserService が appspot.com 全体に統合されているのと同じくらい簡単ですか?
いずれにせよ、これら 2 つの質問に答えることができる人、または私が正しい道を進んでいることを確認できる人に感謝します。
(注: Google の UserService を使用してログイン URL を作成しています。Web アプリ クライアントとリソース サーバーはアプリスポット上にあり、Federated Authentication を使用しています。これはすべて Java です)。