Oracle OAuth Service Oracleホワイト・ペーパー | 2015年3月

2 | Oracle OAuth Service

免責事項 下記事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定されます。

3 | Oracle OAuth Service

目次 はじめに .................................................................................................................................................... 4 OAuth 2.0の概要 ................................................................................................................................... 4 OAM OAuth 2.0 Service – 機能 ..................................................................................................... 5 モバイル・クライアントの保護 .................................................................................................. 8 その他の差別化要因 ........................................................................................................................ 11 サンプル・ユースケース .............................................................................................................. 12 結論 ........................................................................................................................................................... 15

4 | Oracle OAuth Service

はじめに Oracle Access Management 11g Release 2 PS2のOAuth 2.0 Serviceは、ユーザーがパートナー/SaaSプロバイダとリソースの安全な共有およびアクセスを行えるようにする標準ベースのソリューションを組織に提供します。

OAuthプロトコルは元々、ユーザーがパスワードを共有することなく、リソースへのアクセス権をサード・パーティに付与できるようにすると同時に、リソースへの制限付き/スコープ内のアクセス権を付与する手段を提供するように設計され、事実上の標準として広く受け入れられるようになりました。この最初の機能以降、OAuthはすぐに、あらゆるタイプのクライアント（モバイル・デバイスや他のサービスを含む）とサービス間で、トークン化された認証とアクセス制御を実行する上で優先的に使用される方法になりました。

Oracle Access Manager（OAM）OAuth 2.0 Serviceは、標準準拠のOAuth 2.0認可サービス実装で、OAuthによって定義された次のロールをサポートします。

• リソース・サーバー：保護リソースをホストするサーバーで、アクセス・トークンを使ってリソース・リクエストに対する許可と応答を実行可能。

• クライアント：リソース所有者の代わりにその認可を得て、保護リソースをリクエストするアプリケーション。クライアントという語は、特定のエンティティに固有のものではありません。たとえば、クライアントは、サーバーまたはモバイル・デバイスを実行するアプリケーションである場合があります。

• 認可サーバー：リソース所有者を認証し、認可を得た後で、クライアントにアクセス・トークンを発行するサーバー。

OAM OAuth 2.0 Serviceは、パートナー/SaaSプロバイダとリソースの安全な共有またはアクセスを可能にする標準ベースのソリューションを、新規または既存のOracle Identity And Access Management（Oracle IAM）社内顧客に提供するほか、以下の魅力的な推進要因も備えています。

• Oracle Public Cloudがホストするアプリケーションやサービスなど、サード・パーティ・サービスによる使用が可能な標準準拠トークンベースの認証サービスを提供。

• エンドユーザーの偽装にアプリケーション・クライアントが必要で、標準ベースのトークンが必然な選択肢である場合のID伝播のユースケースをサポート。

• モバイル・アプリケーション、SaaSプロバイダ、リッチ・インターネット・アプリケーションなど、さまざまなタイプのクライアント・アプリケーションに豊富なアクセス管理機能セットをサービス・モデルとして提供するOAM Mobile & Social Service用のRESTful Identity Servicesに対応する標準準拠の認証と認可を実現。

OAuth 2.0の概要 従来のクライアント/サーバー認証モデルでは、クライアントはリソース所有者の資格証明を使ってサーバーで認証を行うことで、サーバー上の保護リソースにアクセスします。保護リソースへのアクセス権をサード・パーティ・アプリケーションに付与するため、リソース所有者は自身の資格証明をサード・パーティと共有します。その結果、複数の問題と制限が発生します。

• サード・パーティ・アプリケーションは、リソース所有者の資格証明を後で使用するために保存する必要があり、通常はクリアテキストのパスワードが使用されます。

• パスワードによって脆弱性が生じるにもかかわらず、サーバーでパスワード認証をサポートする必要があります。

• サード・パーティ・アプリケーションがリソース所有者の保護リソースに対して過度に広範なアクセス権を得て、リソース所有者は、リソースの限定的サブセットに対するアクセスや期間を制限できない状態になります。

• リソース所有者は、すべてのサード・パーティへのアクセス権を取り消さないと、個別のサード・パーティへのアクセス権を取り消すことはできず、そうするにはパスワードを変更する必要があります。

5 | Oracle OAuth Service

OAuth 2.0は、認可レイヤーを導入して、クライアントのロールをリソース所有者のロールから分離することで、これらの問題に対処します。OAuth 2.0の場合、クライアントは、リソース所有者によって制御され、リソース・サーバーでホストされるリソースへのアクセスを要求し、リソース所有者とは異なる資格証明のセットが発行されます。保護リソースへのアクセスに対してリソース所有者の資格証明を使用する代わりに、アクセス・トークンを取得します。アクセス・トークンは、特定のスコープ、期間、およびその他のアクセス属性を示す文字列です。リソース所有者の承認を得た認可サーバーは、サード・パーティ・クライアントにアクセス・トークンを発行します。クライアントはアクセス・トークンを使って、リソース・サーバーでホストされる保護リソースにアクセスします。

上記の例は一般に、3-legged OAuthフローと呼ばれます。これは、リクエストを承認するリソース所有者が関与するためです。ただし、2-legged OAuthフロー、つまり、リソース所有者が直接関与せず、クライアントとリソース・サーバーのみのやり取りの例も、サービス間通信の市場において勢いを増しています。このユースケースの場合、基本的にリソースへのアクセスが事前承認されたOAuth Clientが使用されます。このモデルは、サービス間モデルに最適です。特に、リクエストとリソース・サービスが組織または緊密な提携関係によって接続されていて、リソース所有者の承認をすでに受けているとみなされているか、承認が不要な場合に最適です。

OAM OAuth 2.0 Serviceは、OAuth 2.0認可サーバーとして3-leggedおよび2-legged OAuth 2.0フローの両方をサポートするように設計されており、OAuth 2.0 ClientとOAuth 2.0 Resource Serverのロールを実現するための魅力的な差別化機能も複数提供します。

OAM OAuth 2.0 Service – 機能

認可サービス OAM OAuth 2.0認可サービスのエンド・ポイントは、リソース所有者とやり取りを行い、認可付与を得るために使用します。OAM OAuth 2.0認可サービスのエンド・ポイントは、認可を付与する前に、リソース所有者のIDを確認する必要があります。リソース所有者のID確認はOAuth 2.0仕様の対象範囲外であるため、OAM OAuth 2.0は、OAMとの組込みの統合を独自に利用し、OAM認証スキームのいずれかを使ってユーザー認証を実行するための機能を提供し、OAMを使ってユーザー・セッションとCookie管理に対応します。

トークン・サービスおよびサポートされている権限付与タイプ OAuth ClientがPOSTリクエストをOAM OAuth 2.0トークン・サービス・エンド・ポイントに送信すると、サービスはクライアントの資格証明を検証し（クライアント・タイプが部外秘か、クライアント資格証明が発行されたか）、リクエストされたスコープを構成とユーザーの承認に基づいて検証し、次の権限付与タイプのアクセス・トークンを返します。

• 認可コード：

• リソース所有者の資格証明

• クライアントの資格証明

• JWTトークンをサポートするための拡張権限付与タイプ

6 | Oracle OAuth Service

トークン・サービスによってこれらの権限付与タイプがサポートされるため、OAM OAuth 2.0 Serviceは部外秘クライアント用に次のOAuth 2.0フローを完全にサポートできます。

1. 認可コード・フロー：認可コード・フローは、リソース所有者のユーザーエージェント（通常はブラウ

ザ）とやり取りでき、OAuth 2.0認可サーバーからの受信リクエストを受け取れるOAuth Clientに最適で

す。つまり、このフローはWebサーバー・ベースのOAuth Clientに最適です。このフローでは、リソー

ス所有者がアクセスを承認した後、WebサーバーOAuth Clientが認可コードとともにコールバックを受

信し、その認可コードをOAuth 2.0認可サーバーに渡してアクセス・トークン応答を取得します。

2. リソース所有者のパスワード資格証明フロー：このフローは、ユーザー名/パスワード認証フローとも

呼ばれます。アクセス・トークンを取得するためのクライアント・トークン・リクエストがHTTP POST

でOAM OAuthトークン・サービス・エンド・ポイントに送信され、リクエストにリソース所有者の

ユーザー名とパスワードが含まれているためです。クライアントがリソース所有者の資格証明（ユー

ザー名とパスワード。通常は双方向形式を使用）を取得できて、リソース所有者がクライアント（デバ

イスのオペレーティング・システムや特権付きアプリケーションなど）と信頼関係を確立している場合

に最適な権限付与タイプを使用します。

3. クライアントの資格証明付与フロー：このフローでは、クライアントが自身のクライアント資格証明の

み（またはサポートされている他の認証方法）を使ってアクセス・トークンを要求するため、2-legged

OAuthフローとも呼ばれています。また、認可サーバーで設定済みの別のリソース所有者のリソースに

対するアクセスもリクエストできます（この方法はOAuthの仕様の範囲外です）。

クライアントの登録

OAM OAuth 2.0 Serviceを使用すると、管理者はOAMコンソールを使用して、OAuth ClientをリダイレクトURIとともに登録できます。OAuth Service はクライアントごとにクライアントIDを発行します。このIDは、OAuth Client用に提供された登録情報を表す一意の文字列です。

スコープの管理

OAM OAuth 2.0 Serviceでは、リソース・サーバーの特定のスコープ定義を指定するための機能を提供し、認可サービス・エンド・ポイントのリクエストとトークン・サービス・エンド・ポイントのリクエストの両方を処理する際にスコープ・チェックを実施します。また、OAM保護リソースをOAuth 2.0リソース・スコープにシームレスにマッピングできる機能も独自に提供します。

ユーザー認証および承認管理

OAM OAuth 2.0 Serviceは、OAMが提供するすべての認証スキームを独自にサポートしてユーザー認証に対応します。また、ユーザー・セッション/Cookie管理と承認ページの保護用にもOAMを利用します。

リフレッシュ・アクセス・トークン

OAM OAuth 2.0 Serviceは、トークン応答時にアクセス・トークンとともにリフレッシュ・トークンを返します。OAuth Clientが、有効なリフレッシュ・トークンを指定したリフレッシュ・リクエストをトークン・エンド・ポイントに送信すると、OAM OAuth 2.0 Serviceは部外秘クライアント、またはクライアント資格証明が発行されたクライアントに対してクライアント認証を実行し、リフレッシュ・トークンを検証して、要求されたトークンをクライアントに発行します。

7 | Oracle OAuth Service

管理

管理者は、OAM OAuth 2.0 Serviceの使いやすい包括的な構成オプションを使用して、OAMコンソールで次のようなサービスの各種設定を構成できます。

• OAuth認可/トークン・サービス・プロファイル

• OAuthアクセス・サービス・プロバイダ

• OAuth Clientプロファイル

• リソース・サーバー構成

Mobile OAuth

モバイル・クライアント（モバイル・デバイス上のネイティブ・アプリ）は公開/非部外秘クライアントであるため、OAM OAuth2.0 Serviceのサービスを使用するには、最初にモバイル・アプリケーションをOAMに登録する必要があります。OAM OAuth 2.0 Mobile OAuthフローでは、モバイル・アプリケーション登録とデバイスIDを従来の3-legged OAuthフローに独自に組み合わせることで、モバイル・クライアントに対応する信頼済みアクセスを実現します。

8 | Oracle OAuth Service

モバイル・クライアントの保護 いくつかのOAuth Clientは、クライアントの機密情報（アプリケーションのパスワードまたは秘密鍵）を維持できないコンシューマ・アプリケーションです。これらのOAuth Clientは、公開クライアントまたは非部外秘クライアントと呼ばれます。Mobile Clientアプリケーション、つまり、モバイル・デバイス上のネイティブ・アプリケーションも公開クライアントに分類されます。ネイティブ・アプリケーションが初めてアプリ・ストアからデバイスにダウンロードされる際、デバイスには、アプリケーションに含まれるクライアント・アプリケーションを一意に識別するクライアント資格証明があるためです。ネイティブ・アプリケーションをダウンロードするすべてのユーザーにバイナリへのアクセス権があるため、悪意のあるユーザーはバイナリからクライアント資格証明を容易に逆コンパイルして、自身の資格証明を挿入することができます。現在、誰が実際にアクセス・トークンを受信し、使用しているのかを本当に識別するための確実な方法がないため、OAuthフローでアクセス・コードがアクセス・トークンと引き換えに交換される際、大きな脆弱性が生じます。したがって、信頼済みアクセスが確実に行われるように、デバイス上のモバイル・アプリケーションのセキュリティを保護するメカニズムを提供することは、特に機密データに定期的にアクセスする必要のあるエンタープライズ・モバイル・アプリケーションにとって重要な要件となります。以降のセクションでは、モバイルOAuth Client対応のセキュアなアクセスを可能にする、OAM OAuth 2.0 ServiceのMobile OAuthフローにおける主要なイノベーションについて説明します。

モバイル・アプリケーションの登録およびモバイル・デバイスの識別

OAM OAuth 2.0 Serviceでは、Auth Access Serviceを使用できるように、モバイル・アプリケーションを最初にOAMに登録するメカニズムが組込みでサポートされています。モバイル・アプリケーションのセキュリティは、クライアント・プロファイルを作成し、デバイス上のアプリケーションに固有のクライアント・トークンを発行することで実施されます。ユーザーは、各モバイルOAuthアプリケーションを登録するために、明示的に認可を行います。OAM OAuth 2.0 Serviceの場合、モバイル・アプリケーションの登録は、ユーザーによる明示的な承認を必要とするスコープとしてモバイル・アプリケーションの登録がモデル化されるOAuthプロトコル・フローと同じパラダイムを使用します。モバイル・アプリケーションを登録すると、アプリケーションに対してクライアント・トークンが発行されます。モバイル・アプリケーションは、OAM OAuth 2.0 Serviceエンド・ポイントにアクセスするための入力パラメータとして、常にこのクライアント・トークンを送信します。さらに、OAM OAuth 2.0 ServiceではデバイスIDとモバイル・アプリケーションの登録を容易に結び付けることができるため、Oracle Adaptive Access Managerとの組込みの統合を使用することで、モバイル・デバイスとアプリケーションの不正やセキュリティをチェックできます。モバイル・デバイスは、OAM OAuth 2.0 Serviceエンド・ポイントにアクセスするために必要な、デバイスの要求とクライアント・トークンを渡し、OAM OAuth2.0 Serviceは、特定の要求を必須またはオプションとして指定するための構成を提供します。

セキュアなトークンの送信

現代のモバイル・オペレーティング・システムには、アプリケーションにデータが届いたことを伝え、データの受領によってアプリケーションが有効なアプリケーションであることを確認するための通知サービス・メカニズムが備わっています。ネイティブ・モバイルOSアプリケーションの通知メカニズムは、アプリケーションのIDをさらに確実なレベルで確認します。残念ながら、このレベルの確実さは、各種モバイルOSプラットフォームによって異なります。Appleプッシュ通知サービス（APNs）は現時点で、Google Cloud Messaging（GCM）よりも優れたセキュリティ特性を備えています。前者の場合、メッセージの受信者が、適切なプライベート証明書で認証された適切なクライアント・アプリケーションであり、メッセージを復号してもよいこと、およびアプリケーションが（エミュレータではなく）実際のデバイス上で実行されていることを確認できます。ただし、GCMの場合、メッセージが、OAuthプロトコル・リクエストを開始する同じデバイス上の同じアプリケーションにルーティングされることは保証できても、メッセージの受信者が実際

9 | Oracle OAuth Service

の物理デバイス上で実行されていることは確認できず、クライアント・アプリケーションが本物であることを適切に確認することはできません。つまりGCMでは、不正アプリケーションは本物のアプリケーションの送信者IDとサーバー登録インタフェースを作り込んで、本物のアプリケーションに向けられた通知を受信できます。

OAM OAuth 2.0 Serviceでは、ネイティブ・モバイルOS通知サービス・メカニズム（APNS/GCM）の利用をサポートすることで、モバイル・アプリケーションIDの確認を確実なレベルで行うことができます。また、これらのモバイルOS通知サービスを構成オプションで拡張して標準、ハイブリッド、および詳細モードで使用すれば、Mobile OAuthフローのクライアント登録とトークン/コード・リクエストの間、HTTP（S）とプッシュ・メカニズムの組合せを基に、さまざまなレベルのセキュリティでトークン/コードを送信できます。また、クライアント・アプリケーションに送信される認可コード/クライアント・トークンに対して分離ロジック・メカニズムを提供することで、コードがHTTPリクエストの応答とOS固有の通知メカニズムにそれぞれ部分的に送信されるようにします。クライアントは、通知メカニズムおよびHTTPの応答を介して送信されたデータを組み合わせて認可コード/トークンを取得する必要があります。

事前認可コードの使用

従来のOAuthの使用例では、認可コードの作成中、認可エンド・ポイントはセキュリティ資格証明によって保護されません。Mobile OAuthの使用例では、デバイス・プロファイルがMobile OAuthのリクエスト中

（認可コードをリクエストしている間のクライアント登録時または登録後）に送信された場合、またはモバイル・アプリケーションの登録時に使われるユーザー・パスワードが漏えいした場合、認可コードまたはクライアント・トークンが生成されるエンド・ポイント上の操作に異常が生じることがあります。

OAM OAuth 2.0 Serviceでは事前認可コードを導入することで、Mobile OAuthの使用例における認可エンド・ポイントに対し、さらに保護レイヤーを提供します。Mobile Clientは、OAuth認可エンド・ポイントとやり取りする前提条件として、事前認可コードを取得する必要があります。この事前認可コード、認可コードとまったく同じように使用できます。さらに、元のクライアント・アプリケーション（認可リクエストの送信元）のみが事前認可コードを取得できるようにするため、分離ロジックを適用し、元のクライアント・アプリケーションのみがモバイルOS固有の通信チャネル（APNS/GCM）を介して、これらのセキュリティ・コード/トークンの2番目の部分を要求します。

モバイル・アプリケーション用のサーバー側デバイス・ストアおよびサーバー側SSO

前述したように、OAM OAuth 2.0 Serviceは、Mobile OAuthフローの間、モバイル・アプリケーションの登録とモバイル・デバイスの識別を実行して、最初にデバイス上のモバイル・アプリケーションをセキュリティ保護することで、Mobile OAuth Clientからの信頼済みアクセスが確実に行われるようにします。ただし、この中核機能には高い代償が伴います。つまり、登録デバイスに対応するデータ・ハンドルとアプリケーション・セッションごとの情報を保存し、更新する必要があります。

上記の問題を効果的に解決するため、OAM OAuth 2.0 Serviceでは、サーバー側デバイス・ストア機能を導入しています。サーバー側デバイス・ストアに保存されたセキュリティ・マテリアルの例には、ユーザー・トークン（JWTまたはOAM）、およびモバイル・アプリケーション用のOracle Adaptive Access Manager固有のハンドル（"oaam.device"ハンドルや"oaam.session"ハンドルなど）があります。組込みのサーバー側ストアを使用することには次の利点があります。

• セキュアなトークンの共有：トークンやセキュリティ・マテリアルの一部（ユーザー・トークンや"oaam.device"ハンドルなど）は、複数のクライアント・アプリケーション間で共有する必要があります。これらのアプリケーションが複数のアプリケーション・ベンダー/パブリッシャのものである場合、そのトークンを共有し、これらのモバイル・アプリケーション内で同期し続ける効果的で安全な方法はありません。

• より優れたセキュリティ：デバイスまたはクライアント・アプリケーションのセキュリティが侵害された場合でも、これらのトークンはクライアントに戻されないので、トークン値が漏れることは絶対にありません。

10 | Oracle OAuth Service

• モバイル・アプリケーションへの負担を大幅に軽減：モバイル・クライアント・アプリケーションにこれらすべてのセキュリティ・マテリアルを管理させ、そのライフ・サイクルを同期させ続ける代わりに、このロジックをサーバー側で一元的かつ安全に処理します。

OAM OAuth 2.0 Serviceのサーバー側デバイス・ストアの使用によってもたらされる重要な革新性がMobile OAuth Clientアプリケーションのシングル・サインオン（SSO）に組み込まれています。モバイル・アプリケーションの登録中に取得されたクライアント・トークンには、サーバー側ストア・エントリへの"インデックス・キー"として機能するデバイス・ハードウェアIDが含まれており、クライアント・トークン自体は、その特定のサーバー側デバイス・ストア・エントリ内のセキュリティ保護されたデータにアクセスするための"セキュリティ・キー"として機能します。サーバー側デバイス・ストアのロジックは、サーバー側デバイス・ストア・エントリをデバイス・プロファイルのハードウェアIDで識別した後、セキュリティ・データをサーバー側ストアから取得し、OAuthリクエストのコンテキストにおいて有効なユーザー・セッションの存在を検出できるため、ユーザーの複数のクライアント・アプリケーションに対してセキュアなSSOを実行することを可能にします。

11 | Oracle OAuth Service

その他の差別化要因 OAM OAuth 2.0 Serviceは、OAMとの組込みの統合を利用して、より高いレベルのセキュリティと柔軟性をエンタープライズでの用途にもたらします。OAM OAuth 2.0 Serviceのその他の主要機能は次のとおりです。

1. クラウド環境におけるマルチテナント・サポート

2. 単一のOAuth Serviceエンド・ポイントを介して複数のターゲット・アプリケーションをサポート

3. 各ターゲット・アプリケーションの要件に基づく、トークン有効期限のカスタマイズ

4. OAuthアクセス・トークンにおける静的および動的なユーザー・プロファイル属性

5. 拡張サポート

6. SAMLベアラーおよびJWTトークン用のOAuthアサーション仕様をサポート

7. リソース所有者の認証と承認時のOAMとの組込みの統合により、以下を実現します。

8. サポート対象のOAM認証スキームを利用

9. 不正検出と厳密認証

10. シングル・サインオンとセッション管理

11. OAMリソース保護

12. OAuthトークンでOAM WebGateリソースを保護することが可能

13. 共通のOAM構成、展開、およびインフラストラクチャ

12 | Oracle OAuth Service

サンプル・ユースケース

使用例の説明 Avitek Retailは、大手マルチブランド小売企業です。他の複数の商品に加えて、さまざまな競合ブランドの靴とアクセサリも自社小売店で販売しています。Avitek Retailの倉庫マネージャーは、顧客の需要を満たすために適切な在庫レベルを確実に維持する必要があり、通常、在庫を補充するためにサプライヤ・カタログにアクセスする必要があります。

Oracle Access Managerのお客様であるAvitek Retailは、倉庫マネージャーが使う独自の在庫補充アプリケーションを構築しています。Avitek Retailは当初、独自の在庫補充アプリケーションをWebベースのアプリケーションとして構築しましたが、最近になって、iTunesまたはGoogle Playアプリ・ストアからダウンロード可能な、iOSプラットフォームとAndroidプラットフォーム双方に対応するモバイル・ネイティブ・アプリケーションとして利用できるようにしました。

この使用例では、ABC Designer Shoe Incはデザイナー・シューズのカタログを、有効なOAuth 2.0アクセス・トークンが必要なRESTサービスとして提供します。このカタログには、Avitek Retailの在庫補充アプリケーションがアクセスする必要があります。OAuthの観点から見た使用例は次のようになります。

• OAuth 2.0 Server：Avitek Retailで展開されたOracle Access Manager 11g Release 2 PS2

• OAuth 2.0 Client：Avitek Retailの在庫補充アプリケーション

• OAuth Resource Server：ABC Designer Shoe Catalog

• リソース所有者：Tom Dole - ABC Designer Shoe IncからAvitek Retailに提供された靴のカタログを所有する倉庫マネージャー

3- legged OAuthフローと認可コード付与タイプ

13 | Oracle OAuth Service

1. Tom Dole（ABC Shoe Incのカタログ・リソース所有者およびAvitek Retailの倉庫マネージャー）が、在

庫補充アプリケーション（OAuth Client）へのアクセスを試み、クライアントによる別サイト（ABC

Designer Shoe Incのカタログ・リソース・サーバー）のリソースへのアクセスを要求します。

2. 在庫補充アプリケーション（OAuth Client）により、Avitek RetailのOAM OAuth 2.0認可サーバー上の認

可サーバー・エンド・ポイントが起動します。

3. Avitek RetailのOAM OAuth 2.0認可サーバーは、ユーザー認証のため、在庫補充アプリケーション

（OAuth Client）をユーザーエージェント・リダイレクション経由でリダイレクトし、認証の成功に必

要な承認ページをTom Doleに送信します。

4. Avitek RetailのOAM OAuth 2.0認可サーバーはTom Doleの承認を得ると、認可コードを在庫補充アプリ

ケーション（OAuth Client）に送信します。

5. 在庫補充アプリケーション（OAuth Client）は認可コードを使用して、Avitek RetailのOAM OAuth 2.0認

可サーバー・トークン・エンド・ポイントに対しPOSTを実行することで、OAM OAuth 2.0認可サーバー

からOAuthアクセス・トークンを取得します。

6. 在庫補充アプリケーション（OAuth Client）は、アクセス・トークンをABC Designer Incの靴カタログ

（OAuthリソース・サーバー）に送信します。

7. ABC Designer Shoe Incのカタログ（リソース・サーバー）は、Avitek RetailのOAM OAuth 2.0認可サー

バーでトークンを検証します。

8. ABC Designer Shoe Incのカタログ（リソース・サーバー）は、要求されたコンテンツを在庫補充アプリ

ケーション（OAuth Client）に提供します。

Mobile OAuthフロー

14 | Oracle OAuth Service

1. Tom Dole（ABC Shoe Incのカタログ・リソース所有者およびAvitek Retailの倉庫マネージャー）が、在

庫補充アプリケーション（Mobile OAuth Client）へのアクセスを試みます。

2. 在庫補充アプリケーション（Mobile OAuth Client）は、OAM OAuth 2.0 Serverからのデバイス・トーク

ンでコードの事前認可を要求します。

3. OAM OAuth 2.0 Serverは、APNS（iOS）/GCM（Android）経由で事前認可コードを返します。

4. 在庫補充アプリケーション（Mobile OAuth Client）は、登録リクエストとデバイスの要求、および事前

認可コードををOAM OAuth 2.0 Serverに送信します。

5. OAM OAuth 2.0 Serverはユーザーエージェント・リダイレクションを使ってユーザーを認証し、デバイ

ス・セキュリティを確認し、Mobile OAuth Client登録に対するユーザーの承認を得て（Tom Doleがモ

バイル・デバイス上のこのアプリに初めてアクセスする場合）、クライアント・トークンをAPNS/GCM

経由でMobile OAuth Clientに返します。

6. 従来のOAuthフローが開始します。OAuth Serverはデバイス・セキュリティを確認し、構成に応じて

ABC Shoe Designer Incのカタログにアクセスするための承認ページをユーザーに送信します。

7. OAM OAuth 2.0認可サーバーは認可コードを在庫補充アプリケーション（Mobile OAuth Client）に送信

します。

8. 在庫補充アプリケーション（Mobile OAuth Client）は、認可コード、クライアント・トークン、および

デバイスの要求を送信して、OAuth認可サーバーからのアクセス・トークンを要求します。

9. OAM OAuth 2.0 Serverはアクセス・トークンとオプションの更新トークンを在庫補充アプリケーション

（Mobile OAuth Client）に返します。

10. 在庫補充アプリケーション（OAuth Client）は、アクセス・トークンをABC Shoe Designer Incのカタロ

グ（OAuth 2.0リソース・サーバー）に送信します。

11. ABC Shoe Designer Incのカタログ（OAuth 2.0リソース・サーバー）は、OAM OAuth 2.0認可サーバー

でトークンを検証します。

12. ABC Shoe Designer Incのカタログ（OAuth 2.0リソース・サーバー）は、要求されたコンテンツを在庫

補充アプリケーション（Mobile OAuth Client）に提供します。

15 | Oracle OAuth Service

結論 Oracle Access Manager OAuth 2.0 Serviceは、標準に完全準拠のOAuth 2.0認可サーバーを提供し、3-leggedと2-leggedの両方のOAuthフローをサポートし、OAuth 2.0 ClientとOAuth 2.0リソース・サーバーのロールを有効にします。また、Mobile OAuth 2.0 Client（モバイル・デバイス上のネイティブ・アプリケーションなど）向け、特にエンタープライズ使用例におけるエクストラネット・アクセス向けに複数の魅力的な差別化機能と革新性を独自にもたらします。そのような機能や革新性には、OAM OAuth 2.0モバイル・フロー時のモバイル・アプリケーション登録とデバイス識別への組込みのサポートが含まれ、モバイル・デバイスからの信頼済みアクセスと、組込みのサーバー側シングル・サインオンがMobile OAuth Clientに対して確実に行われるようにします。OAuthフロー時により高いレベルのセキュリティを必要とし、OAM OAuth 2.0 Serviceが提供する組込みのOAM統合から利点を得られるエンタープライズ使用例に最適です。

Oracle OAuth Serviceの著者：Kanishk Mahajan、 2015年3月：

Copyright © 2015, Oracle and/or its affiliates.All rights reserved.

本文書は情報提供のみを目的として提供されており、ここに記載されている内容は予告なく変更されることがあります。本文書は、その内容に誤

りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示

的保証および条件などのいかなる保証および条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認

し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることな

く、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。。

IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International,

Inc.の商標または登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。

UNIXは、Open Group.0115の登録商標です。

海外からのお問い合わせ窓口： 電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200