問題タブ [oauth-provider]

サンプル ( https://code.google.com/p/oauth/ ) をダウンロードしてコンパイルし、プロバイダーとコンシューマーの WAR ファイルを Apache Tomcat にロードしました。

Consumer_key=mysecret (これをキーとして設定できるかどうかわかりません) Consumer_key.description=GPS 位置を取得 Consumer_key.callbackURL=http://localhost:8081/oauthC/OAuth / Callback

sample.serviceProvider.baseURL: http://localhost:8081/oauthP/ sample.serviceProvider.requestTokenURL : request_token sample.serviceProvider.userAuthorizationURL: 認可 sample.serviceProvider.accessTokenURL: access_token sample.consumerKey: mysecret sample.consumerSecret : mysecret (この属性に何を設定すればよいか、かなり混乱しています)

そしてサーバーを起動します。http://localhost:8081/oauthC/ (消費者サイト) にアクセスしてサンプルに移動すると、次のように返されました。

OAuthProblemException: oauth_problem: token_rejected

HTTP request: GET /oauthP/request_token?oauth_callback=http%3A%2F%2Flocalhost%3A8081%2FoauthC%2FOAuth%2FCallback%3Fconsumer%3Dsample%26returnTo%3D%252FoauthC%252FSampleProvider&oauth_consumer_key=mysecret&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1298329818&oauth_nonce=13474056411695&oauth_version=1.0 &oauth_signature=JwuEr0jprO8G3bKRhXHdqpeuuxI%3D ユーザーエージェント: Jakarta Commons-HttpClient/3.1 ホスト: localhost:8081

HTTP ステータス: 401

HTTP 応答: HTTP/1.1 401 Unauthorized サーバー: Apache-Coyote/1.1 WWW-Authenticate: OAuth realm="http%3A%2F%2Flocalhost.localdomain", oauth_problem="token_rejected" Content-Type: application/x-www-form -urlencoded;charset=UTF-8 Content-Length: 28 Date: Mon, 21 Feb 2011 23:10:18 GMT oauth_problem=token_rejected

oauth_signature base string: GET&http%3A%2F%2Flocalhost%3A8081%2FoauthP%2Frequest_token&oauth_callback%3Dhttp%253A%252F%252Flocalhost%253A8081%252FoauthC%252FOAuth%252FCallback%253Fconsumer%253Dsample%2526returnTo%253D%25252FoauthC%25252FSampleProvider%26oauth_consumer_key%3Dmysecret% 26oauth_nonce%3D13474056411695%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1298329818%26oauth_version%3D1.0

URL: http://localhost:8081/oauthP/request_token?oauth_callback=http%3A%2F%2Flocalhost%3A8081%2FoauthC%2FOAuth%2FCallback%3Fconsumer%3Dsample%26returnTo%3D%252FoauthC%252FSampleProvider&oauth_consumer_key=mysecret&oauth_signaturetimes_method=HMAC-SHA1&o 1298329818&oauth_nonce=13474056411695&oauth_version=1.0&oauth_signature=JwuEr0jprO8G3bKRhXHdqpeuuxI%3D

私はこれで立ち往生しています。誰でもアドバイスできますか？または、このライブラリのドキュメントを見せてください。何も見つからない...

あなたの時間のためのthx

こんにちは、私の英語でごめんなさい。私は oauth 0.4.4 と oauth-plugin 0.4.0.pre4 gem を使用しています。OAuth プロバイダーとしてアプリにアクセスしようとすると

このリクエストのRailsログは

curl を使用してこのリクエストをシミュレートしようとすると、次のようになります

私のデータベースには 1 つの ClientApplication が含まれています

oauth と oauth-plugin の多くのバージョンを試しましたが、成功した結果は得られませんでした。「 oauthテスト」でググった 2 つのテスト コンシューマーは、同じ結果を示してい ます。

私はdevise 1.2.rcを使用していますがskip_before_filter :authenticate_user!、アプリケーションとOauthコントローラーの両方で無効にしています。

OAuthサーバーの実装を可能にしたオープンソースプロジェクトはありますか？Apache Foundationのもの？

サーバー (Web) アプリケーションがあり、RESTful Web サービスを公開して、サードパーティ企業がその上にモバイル アプリケーションを開発できるようにしました。認証に oAuth が必要です。

サード パーティの Web サイトで oAuth がどのように機能するかは理解していますが、モバイル アプリケーションに関しては、リダイレクトとコールバック、およびシークレットの共有がどのように機能するかわかりません。

OAuth プロバイダーでもある API を作成しています。rspec テストを作成するための推奨される方法はありますか?

oauth を有効にしてすべてのエンドポイントを保護した後、認証ステップを通過する rspec テストをどのように作成しますか?

oauth クライアント トークン (認証されたユーザーなし) を使用してクライアントによってヒットされる可能性があるコントローラー アクション、またはアクセス トークン (特定のユーザー用) を使用して承認されたクライアントによってヒットされる可能性があるコントローラー アクションがあります。これに対応するために、フィルタの前にちょっといいものを設定したいと思います。私は試した：

アクセス トークン リクエストでこのアクションを実行しようとすると、OauthNonce を 2 回記憶しようとするため、エラーが発生します。私の ClientApplication.verify_request メソッドは次のようになります。

これを見ると、この動作は驚くべきことではありません。oauth10_request_token メソッドを実行し、問題なく nonce を記憶しますが、トークンはリクエスト トークンではないため、失敗します。次に、oauth10_access_token を実行しようとし、verify_request を 2 回目に呼び出すときに、すでに覚えているナンスを思い出そうとします。

私が思いつく最善の解決策は、ノンス記憶を残りのリクエスト検証から分離することです。言い換えれば、サーバーは最初に nonce を検証してから、署名の検証 (または verify_request が実行したいその他の処理) を何度でも実行します。

Pelle の application_controller_methods ファイルをフォークせずにこれを行う明確な方法はわかりませんが、あなたの 1 人が提案する明らかな修正が欠けていることを願っています! ご協力いただきありがとうございます！興味がある方のために、私は rails3 を pelle の oauth-plugin と彼の oauth のフォークで使用しています:

私たちが開発している API では、アクセス トークンは一意です。つまり、アプリケーションとユーザーごとに 1 つのアクセス トークンしか存在できないということです。

この結果、ユーザーが 2 台のコンピューターで同じサード パーティのデスクトップ アプリケーションを認証すると、2 番目のコンピューターのみが有効なアクセス トークンを持ち、最初のコンピューターは再度認証プロセスを実行する必要があります (最初のアクセス トークンは無効になります)。 ）。

ユーザー エクスペリエンスの観点からは、これは最適ではありません。セキュリティの観点からは、マイナーな利点があります。

他の人が API にアクセス トークンをどのように実装したか知りたいです。ユーザーとアプリごとに 1 つですか、それとも複数ですか?

しばらくの間、Facebook Graph API (認証に oauth 2.0 を使用) を正常に使用しています。ここで、開発者が同様の方法で API に接続できるようにする独自の API を作成する必要があります。私はさまざまなライブラリを調べましたが、もう少し無駄のないものが欲しいので、自分で作成することにしました。Facebookでユーザーを認証する必要があるコードを見ると、比較的単純に見えますが、軌道に乗っていない場合は修正してください。

まず、消費者がリダイレクトする必要がある安全なページを提供する必要があります。例: https://api.mydomain.com/oauth/authorize?client_id=CONSUMER_KEY&redirect_url=CALLBACK_URL。ユーザーはアプリケーションを確認し、クエリ文字列に oauth_token を使用して、コールバック URL で提供された URL にリダイレクトします。ここでoauth_token用にランダムな一意の文字列を生成し、この特定の消費者のユーザーに対して保存できると思います（編集：以下の回答を参照してください。これは、ユーザーではなく各消費者アプリケーションに固有でなければなりません）。

これがステップ 1 です。ここで、消費者が Web リクエストをトリガーする 2 つ目の安全なページを提供する必要があります。例: https://api.mydomain.com/oauth/access_token?client_id=CONSUMER_KEY&client_secret=CONSUMER_SECRET&oauth_token=OAUTH_TOKEN_RETURNED_ABOVE。これにより、コンシューマーは上記で返された oauth_token をアクセス トークンと交換できます。ここでも、単純にランダムな一意の文字列を生成し、この特定のコンシューマーのユーザーに対して保存します。

これで、私の API は、それを使用しているユーザーに固有の情報を取得しようとするメソッドの access_token を受け入れるようになります。

物事を正しく理解しているかどうか知りたいです。そうであれば、OAuth 2.0 仕様は非常に些細なことのように思えます。また、なぜ oauth_token を access_token と交換する必要があるのでしょうか? 私は自分の考えを持っていますが、誰かがこれを明確にするのを助けることができれば幸いです。

完全に間違っている場合に、先に進んで時間を無駄にしたくないので、フィードバックをいただければ幸いです。

ありがとう

PECL OAuth 拡張機能を必要とせずに OAuth のプロバイダー サポートを実装する (できれば BSD または同様のライセンスの下で) コードはありますか? Zend Framework の Zend_Oauth は非常に優れていますが、これはコンシューマー側にすぎません。だから、反対側（つまり、OAuthサーバーの作成）を行うため以外に、そのようなものがあるのではないかと思います。

pecl/oauth でそれを行う方法を探しているわけではないことに注意してください-これは既に持っています。たとえば、PHP OAuth プロバイダーのセットアップを参照してください-しかし、残念ながらすべての人が PECL 拡張機能をインストールできるわけではないので、いくつか探しています要件を軽減するソリューション。

OAuth1.0aを使用してアプリケーションを認証するAPIがあります。これは、非推奨になっているカスタムビルドおよびhodge-podge呼び出しの数を使用していた古いAPIを置き換えています。

OAuth 1.0aは、コンシューマーシークレットが秘密に保たれていることに依存しているため、（クライアント側の）Javascriptでは安全ではないことはよく知られています。ソースは常に表示可能であるため、これは不可能です。

Chrome、Firefox、IE、Safari用のブラウザ拡張機能があり、将来このAPIを使用する必要があります。これらの拡張機能はすべてJavascriptで大部分または完全に記述されているため、セキュリティの問題があります。

これらの拡張機能は社内にあるため、アクセストークンを取得するためのカスタム認証方法を使用できます。

私が実装を計画しているのは次のとおりです。

• ユーザーはブラウザでWebサイトにログインします。
• Webサイトは、セッションキーを使用してCookieを発行します。
• 次に、拡張機能はそのCookieを取得し、それをAPIに渡します。
• APIは、それが有効でアクティブなセッションであることを検証し、拡張機能にアクセストークンを発行します。
• これらのトークンは、有効期限が切れる前に最大1時間持続します。
• また、JavaScriptで発行されたCookieにはレート制限が低くなります。

次の前提で動作します。

• 別のアプリケーションがあなたのCookieにアクセスできる場合、それらはとにかくWebサイトであなたになりすますことができるため、APIへのアクセスも同じです。
• すべての認証方法は、引き続き当社の管理下にあります。
• トークンの定期的な有効期限は、トークンが危険にさらされた場合、悪用される時間が限られていることを意味します。

私の質問は、これはAPIへのアクセスを制限する安全な方法ですか？より良いものはありますか？

いくつかのメモ。 Chrome拡張機能は、特定のサイトのCookieにアクセスするための許可を求めることができるという事実を知っています。Firefoxの拡張機能でもそうできると思います。

明らかに、どのページでもjavascriptを介してCookieにアクセスすることは望ましくありません。そうしないと、XSS攻撃にさらされるため、拡張機能を介してのみアクセスする必要があります。