52.3 モバイル・クライアント用のOAuthサービスの認可の理解

モバイルOAuthサービス認可シナリオでは、ブラウザで実行されるモバイル・アプリケーションと、ブラウザを使用しないかユーザー認証時にのみブラウザを使用するデバイス固有アプリケーションがサポートされています。

このシナリオでは、次のような拡張セキュリティ・サポート(OAuth 2.0仕様で定義されているベースライン・セキュリティ対策に加えて)が提供されます。

• クライアント・アプリケーションは、組織がモバイルOAuthサービス・クライアントの管理に使用するアイデンティティ・ドメインでOAuthサービスに登録する必要があります。

• モバイル・アプリケーションは、OAuthサービスを使用する前にOracle Access Managementに登録する必要があり、各登録はデバイス上のアプリケーションに固有です。アプリケーションの登録後、モバイル・アプリケーションにはクライアント・トークンが含まれます。このトークンは、アクセス・トークン・リクエストを行うためのセキュリティ資格証明として使用されます。これに対し、OAuth Webクライアントは、資格証明のようなパスワードまたはアサーションを使用して自身を識別します。

• このシナリオは、ユーザー承認管理をサポートしています。承認管理が有効な場合、クライアント・アプリケーションは、ユーザーに、Access Managerに登録するためのアプリケーションのリクエストを受け入れるか拒否するよう求めます。

  ノート:

  この承認は、「サービス・プロファイル」の「クライアント登録にはユーザー承認が必要」属性で制御されます。設定されている場合、ユーザーはアプリケーション登録を確認するように求められ、オフにした場合、ユーザーは確認を求められません。「サービス・プロファイルの構成」を参照してください。

• アクセス・トークン(およびサーバー側SSOが無効になっている場合はユーザー・トークン)を除いて、サーバーはOAAMデバイス・ハンドルやOAAMセッション・ハンドルなどのセキュリティ・マテリアルをモバイル・デバイス上のクライアントに送信せずに、サーバー側デバイス・ストアに格納します。アクセス・トークンは、クライアントに送信され、サーバー側デバイス・ストアに格納されて、検証およびライフ・サイクル管理に提供されます。

• OAMサーバー・コンポーネントは、トークンの一部をHTTPSにより送信し、他の部分をApple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)のいずれかを使用してプッシュ通知により送信することで、特定のデバイスにインストールされた特定のアプリケーションにトークンの配信を制限できます。図52-2では、これを説明しています。

  図52-2 分割リクエストを使用したクライアント検証コードの取得

  
  「図52-2 分割リクエストを使用したクライアント検証コードの取得」の説明

次のシナリオは、モバイル・クライアントによる認証時にOracle Access Managementが実行する追加の相互作用を示しています。プロセスは図52-3に示されています。

1. リソース所有者がクライアント・モバイル・アプリケーションを開きます。

   Oracle Access Management管理者は、すでにこのクライアント・アプリケーションをモバイルOAuthサービス・クライアントとして登録しています。

2. モバイル・クライアントは、OAuthサービスにクライアントIDとデバイス・トークンを送信し、クライアント検証コードをリクエストします。

3. OAuthサービスはHTTPSまたはHTTPを介してクライアント検証コードの半分を返します。

   図52-2を参照してください。この動作は、「OAuthサービス・プロファイル構成」ページの「モバイル・サービスの設定」セクションで構成できます。

   • セキュリティ・レベルが「詳細」に設定される場合、すべてのコードおよびトークンはHTTPおよびプッシュ通知の両方を使用して返されます。

   • セキュリティ・レベルが「標準」に設定される場合、すべてのコードおよびトークンはHTTPのみを介して送信されます。

   このシナリオの残りのステップ(ステップ4から開始)には、セキュリティ・レベルを「詳細」に設定した場合の詳細について説明します。

4. モバイル・クライアントが、OAuthサービスのプッシュ・エンドポイントからクライアント検証コードの残りの半分をリクエストします。

   プッシュ・エンドポイントは、モバイル・デバイスのオペレーティング・システムに応じて、リクエストをAPNSまたはGCMサービスに転送します。

5. APNSまたはGCMサービスは、クライアント・アプリケーションにクライアント検証コードの残りの半分を送信します。

6. モバイル・クライアントは、クライアント検証コードおよびデバイス・トークンを送信して、OAuthサービスに認可コードをリクエストします。

7. OAuthサービスは、リクエストをAccess Managerにリダイレクトします。

8. Access Managerは、ユーザーがログインできるように、ログイン・ページをユーザー・エージェントに送信します。

9. リソース所有者(ユーザー)は、ユーザーIDとパスワードを入力します。

10. Access Managerは、ログインを検証し、OAuthサービスにリダイレクトします。

11. OAuthサービスは、デバイスを登録するためユーザーの承認を得るように構成されます。(「OAuthサービス・プロファイル構成」ページで「クライアント登録にはユーザー承認が必要」が無効である場合、ユーザーに登録の承認を求めません。)

12. 承認ページがリソース所有者に送信されます。

13. リソース所有者は承認を提供(または拒否)します。

14. OAuthサービスは、Oracle Adaptive Access Manager (OAAM)プラグインを確認して、追加の認証ステップが必要かどうかを判断します。

15. プラグインは、追加のチャレンジ質問が必要であると判断します。

16. OAAMチャレンジ質問がリソース所有者に送信されます。

17. リソース所有者は、チャレンジ質問の回答を提供し、その回答はOAAMプラグインに転送されます。

18. OAAMプラグインはチャレンジ質問の回答を検証します。

19. OAuthサービスは、モバイル・リダイレクトURIを使用して、モバイル・アプリケーションがクライアント・トークンをリクエストする必要がある認可コードの半分を返します。

20. モバイルOAuthサービス・クライアントは、OAuthサービスのプッシュ・エンドポイントに認可コードの残りの半分をリクエストします。

    プッシュ・エンドポイントは、APNSまたはGCMサービスにリクエストを送信します。

21. モバイル・クライアント・アプリケーションは、APNSまたはGCMサービスから認可コードの残りの半分を受け取ります。

    モバイル・クライアント・アプリケーションは、クライアント・トークンをリクエストする準備として認可コードをアセンブルします。

22. 認可コードを検証した後で、モバイルOAuthクライアントはそのコードを使用して、OAuthサービスのトークン・エンドポイントにクライアント・トークンの最初の半分をリクエストします。

23. トークン・エンドポイントは、モバイル・クライアントにクライアント・トークンの最初の半分を返します。

24. モバイル・クライアントは、OAuthサービスのプッシュ・エンドポイントにクライアント・トークンの残りの半分をリクエストします。

25. APNSまたはGCMサービスは、モバイル・クライアント・アプリケーションにクライアント・トークンの残りの半分を送信します。

    モバイル・クライアントは、クライアント・トークンをリフレッシュ・トークンとともにアセンブルします。クライアントは、リフレッシュ・トークンを使用して、新しいクライアント・トークンをリクエストできます。

26. モバイル・クライアントは、次のステップを完了して、アクセス・トークンをリクエストする準備をします。

    • クライアントは、OAuthサービスにクライアント検証コードをリクエストし、受信します。

    • クライアントは、OAuthサービスに認可コードの最初の半分をリクエストし、受信します。

    • リソース所有者は、ユーザー・セッションが有効なままである場合は、ログインする必要はありません。

    • ユーザーの承認は、クライアントがアクセスをリクエストしているリソース・サーバー・スコープに基づいて要求される場合があります。

    • OAAMプラグインはそのチャレンジを繰り返しません。

    • クライアントは認可コードの残りの部分をリクエストします。

27. APNSまたはGCMサービスは、アクセス・トークンの認可コードの残りの半分を返します。

    クライアントは、アクセス・トークン・リクエストの準備として認可コードをアセンブルします。

28. モバイル・クライアントは、クライアント・トークンおよびアクセス・トークン認可コードを送信して、アクセス・トークンをリクエストします。

29. トークン・エンドポイントは、クライアントにアクセス・トークンを送信します。この動作は、「OAuthサービス・プロファイル構成」ページの「モバイル・サービスの設定」セクションで「セキュリティ・レベル」設定が「詳細設定」または「標準」のどちらに設定されているかによって異なります。

30. モバイルOAuthサービス・クライアントは、リソース・サーバーにアクセス・トークンを送信して、保護されているリソースへのアクセスをリクエストします。

31. リソース・サーバーは、OAuthサービス・トークン・サービスを使用してアクセス・トークンを検証します。リソース・サーバーはトークンをローカルに検証することもできます。証明書が正しく構成されている場合は、JWTトークン署名がリソース・サーバーで検証されます。

32. OAuthサービス・トークン・サービスは、リソース・サーバーにレスポンスを送信します。

33. リソース・サーバーはモバイル・クライアントにリクエストされたリソースを送信します。

図52-3 完全なモバイル・アプリケーション認可リクエスト・フロー

「図52-3 完全なモバイル・アプリケーション認可リクエスト・フロー」の説明