0

API（Restlet、GAE）を作成し、認証用のOpenIdとAPIへのアクセスを保護するためのOAuth2を実装しています。私が作成したクライアントWebアプリからこれをテストすると、すべて問題ありません。ユーザーがAPIへのアクセスを希望するWebアプリの一部にアクセスすると、ユーザーはOpenIdを介してログインするように求められ、次にAPIからリソースを取得するためにWebアプリへのアクセスを許可するように求められます。

しかし、Webアプリはユーザーが誰であるかを知らないことに気づきました（！）。Webアプリにあるのは認証トークンだけです。したがって、Webアプリはユーザーが誰であるかを知らないため、「こんにちは、ユーザー名」とは言えません。

Restletテクノロジーでは、認証は基本的に次のようになります。//認証コードOpenIdVerifier verifier = new OpenIdVerifier（OpenIdVerifier.PROVIDER_YAHOO）; verifier.addRequiredAttribute（AttributeExchange.EMAIL）;
オーセンティケーターau=new MyRedirectAuthenticator（getContext（）、verifier、null）;

以下は認証とOAuth2認証の両方を処理しますが：//認証+ OAuthコード：OAuthParameters params = new OAuthParameters（ "2345678901"、 "secret2"、 "http：// localhost：8888 / v3 /"、roles）; OAuthProxy local = new OAuthProxy（params、getContext（））;

最初は、Webアプリで「Authentication + OAuth」のみを使用していて、認証は「目に見えない」状態で行われていました（前述のとおり）。

「問題」を回避する1つの方法は、Webアプリが認証を「視覚的に」処理する場合です。そこで、認証コードをWebアプリに追加しました。フローはユーザーにはまったく同じように見えますが、Webアプリはユーザー情報（電子メール）をキャプチャでき、すべて問題ありません。「両方」のコードとも競合はないようです。

この問題を回避するもう1つの方法は、authToken（Twitterのverify_credentials）に関連付けられたユーザー情報を返す何かをAPIに追加することです。

私の質問：私が取ったアプローチは合理的ですか？代わりにTwitterのアプローチを使用する必要がありますか？それとも完全に違うものですか？（私はこれらすべてにかなり慣れていないので、うまくいくように見えるソリューションを選択しているかどうかを判断するのは難しいですが、後でレンガの壁にぶつかるだけです）。

4

1 に答える 1

0

簡単に言えば、クライアント Web アプリがユーザーに代わって OAuth リソースにアクセスする許可を取得する場合、クライアント Web アプリはユーザー (ログイン、パスワードなど) について何も知らないはずです。クライアント Web アプリは、ユーザーが誰であるかを知りたい場合、認証を提供できます。

上記のスキームを Restlet と Google アプリ エンジンで実装し、ユーザーが OpenId を介してリソース サーバーに対して認証できるようにし、Web クライアント アプリに Google 認証を追加できるようにしました ("hello" メッセージを表示できるようにするためだけに)。すべて問題ないようです。

于 2012-07-06T02:30:18.020 に答える