OAuth 2.0 の概要

このページは Apigee と Apigee ハイブリッドに適用されます。

Apigee Edge のドキュメントを表示する。

OAuth ホーム: OAuth のガイダンスの概要については、OAuth ホームページをご覧ください。

このトピックでは、Apigee Edge での OAuth 2.0 の基本的な概要について説明します。

OAuth 2.0 とは

OAuth 2.0 に関しては、専門書、ブログ、サイトが多数存在しますが、まずは、IETF OAuth 2.0 の仕様を確認することをおすすめします。OAuth 2.0 IETF 仕様での OAuth 2.0 の定義は次のとおりです。

「OAuth 2.0 認可フレームワークは、サードパーティのアプリケーションによる HTTP サービスへの限定的なアクセスを可能にする。サードパーティ アプリケーションがアクセス権を取得する際は、リソース所有者と HTTP サービスの間の承認のためのやり取りをリソース所有者の代わりにオーケストレートして行う場合と、自らの権限においてアクセス権を取得する場合がある。」

重要な点は、OAuth 2.0 では、ユーザーがアプリにログイン認証情報を渡さずとも、ユーザーの保護対象リソース（たとえば銀行口座情報などのアプリからアクセスしたい機密情報）にアプリが限定的にアクセスできることです。

OAuth 2.0 のフロー

ここでは、OAuth 2.0 のセキュリティ フレームワークの一般的なフローを示します。このトピックでは、OAuth 2.0 の仕組みについて図を示しながら、フローについて詳しく説明します。図で使用されている用語については、このセクションで簡単に説明しています。

OAuth 2.0 セキュリティ フレームワークの一般的なフロー。

知っておくべき用語

  • クライアント: アプリとも呼ばれます。モバイル デバイス上で動作するアプリや従来のウェブアプリです。アプリは、リソースの所有者に代わって、保護されたアセットのリソース サーバーにリクエストを行います。リソース オーナーは、保護されたリソースにアクセスする権限をアプリに付与する必要があります。
  • リソース所有者: エンドユーザーとも呼ばれます。一般的に、保護されたリソースへのアクセスを許可できる人（または他のエンティティ）です。たとえば、アプリがソーシャル メディアサイトのいずれかのデータを使用する必要がある場合は、ユーザーがリソース所有者（ユーザーのデータにアプリがアクセスすることを許可できる唯一の人）となります。
  • リソース サーバー: Facebook、Google、Twitter などのサービス、イントラネット上での HR サービス、B2B エクストラネットのパートナー サービスなどです。API リクエストを処理するために OAuth トークンの検証が必要になるときは、Apigee が常にリソース サーバーになります。リソース サーバーは、保護されたリソースをアプリに提供する前に、なんらかの認可を必要とします。
  • 認可サーバー: 認可サーバーは、OAuth 2.0 の仕様に準拠して実装されます。このサーバーは、認証権限の付与を検証し、アプリがリソース サーバーのユーザーのデータにアクセスできるようにするアクセス トークンを発行します。Apigee にトークン エンドポイントを構成できます。この場合、Apigee は認可サーバーの役割を担います。
  • 認可権限の付与: エンドユーザーに代わってアクセス トークンを取得する権限をアプリに付与します。OAuth 2.0 では、4 つの「権限付与タイプ」が定義されています。OAuth 2.0 の権限付与タイプとをご覧ください。
  • アクセス トークン: 保護されたリソースへのアクセスに使用するための認証情報として機能する長い文字列。アクセス トークンとはをご覧ください。
  • 保護されたリソース: リソース オーナーが所有するデータ。たとえば、ユーザーの連絡先リスト、アカウント情報、その他の機密データなどです。

Apigee が適合するケース

Apigee でプロキシされるすべての API を OAuth 2.0 で保護できます。Apigee には認可サーバーの実装が含まれているため、アクセス トークンを生成して検証できます。デベロッパーはまず、Apigee にアプリを登録します。登録されたアプリは、4 つの権限付与タイプのインタラクションを使用してアクセス トークンをリクエストできます。

Apigee には、各権限付与タイプの詳細を実装する多面的な OAuthV2 ポリシーが用意されており、Apigee で OAuth を比較的簡単に設定できます。たとえば、アクセス トークンのリクエストを受け取り、必要なすべての認証情報を評価し、認証情報が有効な場合にアクセス トークンを返すポリシーを構成できます。

セキュリティで保護された API プロキシが呼び出すリソース サーバーは、ファイアウォールで保護されている必要があります（つまり、API プロキシやセキュリティで保護された別の API 以外の方法でリソースにアクセスできないようにする必要があります）。

OAuth 2.0 の権限付与タイプとは

権限付与タイプは、アプリがアクセス トークンを取得するために利用できる、さまざまな経路やインタラクションとしてとらえることができます。各権限付与タイプは 1 つ以上のユースケースに対応しており、ユーザーは自分のニーズに基づいて使用する付与タイプを選択する必要があります。一般に、それぞれの権限タイプには長所と短所があり、ビジネス ユースケースに基づいて比較検討する必要があります。重要な考慮事項の一つは、データにアクセスするアプリの信頼性です。通常、サードパーティ製アプリは企業内で開発および使用されるアプリに比べると信頼性に欠けます。

Apigee は、次の 4 つの主要な OAuth 2.0 の権限付与タイプをサポートしています。

  • 認証コード -- 最も安全な権限付与タイプと見なされます。認可サーバーがアクセス トークンを発行する前に、アプリはまずリソース サーバーから認証コードを受け取る必要があります。アプリによってリソース サーバーのログインページへのブラウザが開かれ、実際のアカウント（Facebook や Twitter など）にログインするように誘導されるときはいつでも、このフローが見られます。

ログインに成功すると、アプリは、アクセス トークンと認可サーバーのネゴシエートに使用できる認証コードを受け取ります。通常、この権限付与タイプは、アプリがクライアントではなくサーバーにある場合に使用されます。リソース サーバーのユーザーのユーザー名とパスワードが、クライアント アプリによって処理されることも把握されることもないため（つまり、アプリが Twitter などの認証情報を把握することや処理することがない）、この権限付与タイプは非常に安全性が高いと考えられています。この権限付与タイプのフローは、3-legged OAuth とも呼ばれます。

  • 暗黙 - 簡素化された認証コードです。通常、この権限付与タイプは、アプリがクライアントにある場合に使用されます。たとえば、アプリのコードは、JavaScript や別のスクリプト言語を使用してブラウザに実装されています（別のウェブサーバー上に存在して実行されるわけではありません）。この権限付与タイプのフローでは、認証コードを最初に発行するのではなく、ユーザーが認証されたときに認可サーバーから直接アクセス トークンが返されます。暗黙的な権限付与は、アプリのレスポンスを向上させる場合もありますが、この利点は、IETF 仕様で説明されているように、セキュリティの影響を考慮して判断する必要があります。
  • リソース オーナー パスワード認証情報 - このフローでは、ユーザーのユーザー名とパスワードが認可サーバーによって検証されると、クライアントにアクセス トークンが発行されます。このフローは、信頼度の高いアプリケーションにおすすめです。このフローの（Basic 認証などと比較した）利点は、ユーザーがユーザー名とパスワードを一度しか提示しないことです。最初に提示した後はアクセス トークンが使用されます。
  • クライアント認証情報 - クライアント アプリが独自に動作する場合に使用します。つまり、クライアントがリソース所有者でもある場合です。通常、この権限付与タイプは、アプリがバックエンド データ ストレージ サービスにアクセスする必要がある場合などに使用されます。アプリが自身の作業を行うためにサービスを使用する必要があり、サービスはエンドユーザーからは見えません。この権限付与タイプを使用すると、アプリはクライアント ID とクライアント シークレット キーを認可サーバーに提示することで、アクセス トークンを受け取ることができます。これ以上のステップは必要ありません。Apigee には、あらゆる API プロキシに簡単に実装してすぐに使える、クライアント認証情報ソリューションが用意されています。

アクセス トークンとは

アクセス トークンとは、保護されたリソースへのアクセスに使用する認証情報として機能する長い文字列です。リソース トークン（署名なしトークンとも呼ばれます）は、次のように Authorization ヘッダーで渡されます。

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

リソース サーバーは、アクセス トークンがユーザー名とパスワードなどの認証情報の代わりを務めていると認識しています。また、アクセス トークンを上限付きで発行することもできます。たとえば、アプリがリソース サーバーでデータの読み取りは許可する一方で、書き込みや削除は許可しないようにできます。アプリが不正使用された場合などは、アクセス トークンを取り消すことができます。この場合、アプリを引き続き使用するには新しいアクセス トークンを取得する必要がありますが、リソース サーバーが保護されたもの（Facebook や Twitter など）であればユーザー名やパスワードを変更する必要はありません。

通常、アクセス トークンには有効期限があります（セキュリティ上の理由から）。権限付与タイプによっては、認可サーバーが更新トークンを発行できます。これにより、古いトークンが期限切れになったときに、アプリが新しいアクセス トークンを取得できます。アクセス トークンと更新トークンの詳細については、「IETF OAuth 2.0 の仕様」をご覧ください。

スコープによるアクセス制限

OAuth 2.0 はスコープのメカニズムによって、保護されたリソースへのアプリのアクセス制限を実現しています。たとえば、アプリが特定のリソースにのみアクセスできる場合や、リソースを更新できる場合や、読み取り専用アクセスのみが許可される場合があります。いわゆる 3-legged OAuth フローでは、ユーザーは通常、同意ページを介してアクセスレベルを指定します（たとえば、ユーザーが他のメカニズムのチェックボックスでスコープを選択するウェブページなど）。

アプリの登録

すべてのクライアント（アプリ）は、アクセス トークンをリクエストする OAuth 2.0 認可サーバーに登録する必要があります。アプリを登録すると、一連の鍵が返されます。1 つはクライアント識別子と呼ばれる公開鍵で、もう 1 つはクライアント シークレットと呼ばれる秘密鍵です。これらの鍵がないと、アプリは認証コードまたはアクセス トークンのリクエストを認可サーバーに発行できません。これらの鍵は、IETF OAuth 仕様ではクライアント ID とクライアント シークレットと呼ばれますが、Apigee UI ではコンシューマー ID とコンシューマー シークレットと呼ばれます。これらは同じものです。

OAuth 2.0 のユースケースの概要

権限付与タイプの安全性はそれぞれ異なるため、実装する OAuth 2.0 権限付与タイプのフローはユースケースに応じて選択する必要があります。権限付与タイプの選択はクライアント アプリの信頼度によって異なるため、次の表に示すように十分慎重に検討してください。

ユースケース 信頼度 推奨される OAuth 2.0 認可権限付与タイプ 説明
B2B（エクストラネット）、イントラネット、その他

非常に信頼度の高いアプリ（内部デベロッパー、または API プロバイダと信頼できるビジネス関係があるデベロッパーが作成）。

アプリ自身の権限でリソースにアクセスする必要のあるアプリ。
  • クライアント認証情報
  • 通常、アプリはリソース所有者でもあります。
  • クライアント ID とクライアント シークレット キーが必要です。
  • アプリをサービス プロバイダに登録する必要があります。
イントラネット サイト、ポータル

信頼できるアプリ（内部デベロッパーまたは信頼できるサードパーティのデベロッパーが作成）。

良い例としては、自社の HR サイトにログインして、保険の選択、レビューの提出、個人情報の変更などを行うケースがあります。
  • パスワード
  • 暗黙的
  • クライアント ID とシークレット、ユーザー名とパスワードが必要です。
  • アプリをサービス プロバイダに登録する必要があります。
一般公開アプリ 信頼できないアプリ（API プロバイダと信頼できるビジネス関係のないサードパーティのデベロッパーが作成）。たとえば、公開 API プログラムに登録するデベロッパーは、一般的には信頼しないようにする必要があります。
  • 認証コード
  • サードパーティのリソース プロバイダ（Twitter、Facebook など）にユーザーがログインする必要があります。
  • アプリがユーザーのユーザー名とパスワードを見ることはありません。
  • アプリをサービス プロバイダに登録する必要があります。
B2C 関係する個々のエンドユーザー（モバイル ユーザー）が存在し、ユーザーの認証情報がモバイル デバイスに保存されます。
  • 暗黙的
  • アプリをサービス プロバイダに登録する必要があります。
  • アプリを実行しているデバイスにユーザーの認証情報が保存されます。

OAuth 2.0 と API キーのセキュリティ

API キーの検証では、アプリが Apigee にキーを送信する必要があります。このキーは、API プロキシに関連付けられている Apigee デベロッパー アプリの有効なコンシューマー キーである必要があります。なんらかの理由で、クライアント アプリのプロキシを呼び出す権限を取り消す必要がある場合は、そのコンシューマー キーを取り消す必要があります。これにより、そのキーを使用するすべてのクライアント アプリが API プロキシにアクセスできなくなります。一方、OAuth トークンは、アプリのキーを取り消すことなくいつでも取り消すことができます。アプリがユーザーに代わって新しいトークンをリクエストし、トークンが付与されれば、API プロキシを引き続き使用できます。

API キーとトークンのもう一つの違いは、トークンには後で取得して使用できるメタデータ属性を含めることができることです。たとえば、API 呼び出しを行うユーザーの ID を格納し、それを使用してバックエンド ターゲット サービスへの呼び出しをカスタマイズできます。

API キー検証の詳細については、API キーをご覧ください。OAuth トークンとともにカスタム属性を使用する方法については、トークンと認証コードのカスタマイズをご覧ください。

おすすめのリソース

参考資料

OAuth 2.0 の詳細をご覧ください。