6

OAuth2 のみをサポートする API と対話する必要があります。

問題は、GUI が毎日 API をポーリングせずに、純粋にサーバー側のアプリケーションを作成したいということです。

API を使用すると、アプリケーション トークンをプログラムで取得できますが、後続のアクセス トークンを取得するには、GUI フロー全体を実装する必要があるようです。これは、アプリケーション プロバイダーの Web ベースのログイン画面からログインする必要があるためです。

次に、そのアクセストークンを取得し、これをサーバー側の資格情報としてコピーして、再作成する必要があるようです。有効期限が切れたり、問題が発生した場合は、GUI フローを介して戻って、サーバー側のアクセス トークンを取得する必要があります。

これは非常にぎこちなく感じるので、ここでの私の理解は正しいですか?

具体的には:

アプリケーション プロバイダーのログイン フォームにリンクするプロセスの実装を避けることはできますか?

これを行った後、アクセス トークンを選択解除し、これをサーバー側アプリケーション内に保存する必要があります。有効期限が切れるかどうかを制御できないようです。

たとえば、Facebook は特にサーバー側とクライアント側のフローをサポートしていることがわかります。OAuth 2 のこの特定の実装で制限に直面しているのでしょうか?

4

2 に答える 2

2

この質問で尋ねた問題の典型的な解決策は、XAuth を使用することであることがわかりました。

Twitter や私が現在取り組んでいるアプリケーションなどの多くのプロバイダーは、XAuth をサポートして、ユーザー インターフェイス ベースの認証なしで簡素化されたフローを提供します。

BasicAuth、OAuth、XAuthの違いは何ですか?

于 2013-05-15T12:31:24.327 に答える