1

私は OAuth2 仕様と多くのサポート資料を研究してきましたが、私のユース ケースにどのアプローチ/フローを使用するのが最適かを判断できません。

ユーザーが SSO メカニズムを介してアクセスできる Web アプリケーションがあります。これは十分に基本的なメカニズムですが、ユーザーが自分のネットワークで自分自身を承認し、ユーザー情報を含む暗号化されたトークンを私に送信する必要があります。これを処理し、Web アプリでセッションをセットアップします。

これで、モバイル Web クライアント (現在は Android) が Web アプリからデータを取得できるようにする REST API のセットができました。この SSO メカニズムを再利用して、モバイル クライアントが残りのリクエストごとに自分自身を識別するために使用する OAuth トークンを生成したいと考えています。フローがシームレスであることが理想的です。つまり、ユーザーが自分の電話でブラウザーを開き、自分のシステムで認証を行い、OAuth トークンを使用してモバイル Web クライアントのホーム URL に誘導されます。

私が読んだことから、すべての OAuth2 フローは逆に機能しているように見えます。つまり、ユーザーは最初に認証サーバーに話しかけ、次に自分の認証システムにリダイレクトされ、次に認証サーバーにリダイレクトされ、トークンが発行されます。 . 私の心配は、この方法では、ユーザーがローカルで自分自身を承認する方法を変更する必要があるかもしれないということです.

ここで何か不足していますか？

4

1 に答える 1

1

あなたの問題を正しく理解していれば、それほど複雑ではありません。シナリオでは、モバイル アプリケーション用に設計された暗黙的な許可メッセージ フロー ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.2 ) を使用する必要があります。したがって、メッセージ フローは次のようになります。

  1. モバイル アプリケーションが開始されると、OAuth サーバーにトークン要求が送信されます。サーバーは Web アプリケーションへのリダイレクトで応答します。結果ページがユーザーに表示されます。
  2. ユーザーは (手動または SSO を使用して) サインインし、認証要求の詳細を読み、うまくいけばそれを承認します。承認は OAuth サーバーに送信されます。
  3. OAuth サーバーはトークンを生成し、URL フラグメントにトークン情報を含むリダイレクトを返します。
  4. モバイル アプリケーションはフラグメントからトークンを抽出し、それを使用して保護されたリソースにアクセスします。

これを実現するには、シナリオをサポートするために、モバイル用の OAuth クライアント、OAuth サーバー Web アプリケーション、および Web アプリケーションの承認ページの両方が必要です。OAuth サーバーが Web アプリケーションに緊密に統合されている場合、サーバーとアプリケーション間のリダイレクトは必要ない場合があります。

于 2012-05-30T11:35:58.437 に答える