3

ケース:
デスクトップ クライアントがサーバー A と対話します。
その結果、サーバー A はサーバー B に接続する必要があります。
クライアントに oauth 要求が渡されます。
ここで、クライアントには、サーバー B のユーザー資格情報が既にあります。ユーザーにプロンプ​​トを表示したり UI を表示したりせずに、サーバー B に対して認証する方法はありますか? サーバーBが何であるかがわからないため、これを一般的な方法で行う必要があります。

私の現在の理解は、そうではないということです。何らかの方法でログイン フォームを自分で処理したとしても、ユーザーがクリックしなければならない OAuth 確認がまだ残っています。

私の現在の理解が正確であることを確認したいだけです。何か洞察があれば教えてください。

4

2 に答える 2

2

簡単な答えはNoです。

サーバー B はサーバー A と対話する必要があるため、サーバー A はサーバー B に登録する必要があります (LinkedIn、Twitter などのアプリ登録など)。ほとんどの場合、サーバー B に依存しますが、IMO サーバー B は直接アクセスを許可しません。

ただし、サーバー B に 2 つのアクセス ポイントがあり、サーバー C またはサーバー A の詳細を使用できるという別の状況が発生する可能性があります。

A =>C (Access)  
A !=>B (no access)  
C =>B (access)

ここでは、サーバー C の詳細を使用して B からデータを取得し、A の詳細を使用して C からデータを取得できます。

于 2013-02-16T05:06:45.793 に答える
1

クライアントは、HTTP リダイレクト経由でサーバー B の認証ページに送信されました。サーバー B について何も知らないので、その承認 (および/または認証) が何を伴うのかわかりません。OAuth の範囲外です。サーバー B のユーザー資格情報が何であるかがわからないため、サーバー B のユーザー資格情報を持っていることもわかりません。

通常、クライアントはユーザーが選択するブラウザであり、サーバー B は、ユーザーの操作なしで、クライアントに保存されている (通常は Cookie を使用して) 認証および/または承認資格情報を受け入れることを選択できます。ただし、これも制御できません。サーバー B がユーザーの操作を要求するのを止めることはできません。認証のみが必要な場合は、通常は ID の選択肢がないため、OpenID がこれを許可する可能性が高くなりますが、それでも確実ではありません。

後で更新するためにアクセス トークンを保存し、再認証をまったく行わずに使用できる場合があります。これもサーバー B 次第であり、一般的なサーバーではこれに頼ることはできません。

于 2009-09-10T00:12:43.660 に答える