OAuth 2.0 の概要

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 の仕組みについて図を示しながら、このフローについて詳しく説明します。この図で使用されている用語に詳しくない場合は、簡単な概要を示したこのセクションをご覧ください。

基本的な用語

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

Apigee Edge が適合するケース

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

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

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

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

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

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

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

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

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

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

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

おすすめのリソース

読みもの

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