「OAuth 2.0」の基本動作を知る：デジタルID最新動向（1）（1/4 ページ）

SNSなど複数のWebサービスが連携して動くサービスが広く使われている。連携に必要不可欠なのが、アクセス権限をセキュアに受け渡すための仕組みだ。本連載ではこのような仕組みのうち、「OAuth 2.0」や「OpenID Connect」「SCIM」の最新動向と技術の内容を紹介する。

[ritou（OpenID Foundation Japan），＠IT]

　OpenID Foundation Japan Evangelistのritouです。

　本連載では、Webサービスの連携に必要不可欠なアクセス権限の受け渡しを可能にする技術として、「OAuth」や「OpenID」「SCIM」の最新動向と技術の内容を紹介していきます。第1回と第2回はOAuth 2.0を扱います。

　OAuth 2.0の仕様を定めた「RFC 6749」「RFC 6750」が、2012年10月に公開されてから、約5年が経過しました^＊1）。OAuth 2.0は幅広く使われる技術に育っています。第1回はユースケースを通じて、OAuth 2.0を取り巻く環境の変化と現状を紹介します。

＊1） 2012年に公開した「『OAuth』の基本動作を知る」はこちら。

4つの要素が役割を分担するOAuth 2.0

　まず、OAuthが必要な理由をおさらいしておきましょう。

　例えばSNSのようなサービスAがあり、エンドユーザーが所有するリソースやエンドユーザーのみがアクセス権限を持つ各種機能がAPIで提供されていたとします。

　サービスAと同じエンドユーザーのリソース（例えばプロフィール情報）を扱う別のアプリケーションがあるとき、サービスAと連動できる仕組みがあると便利でしょう。エンドユーザーが複数のサービスを個別に操作する必要がなくなります。

　そのためには、エンドユーザーがアプリケーションに対してアクセス許可を与える仕組みが必要です。さらにアプリケーションがサービスAの提供するAPIにアクセスする際に許可を受けていることを証明する仕組みも別に必要です。

　こうした一連のフローをセキュアに実現する「アクセス権限の付与」のためのプロトコルがOAuth 2.0なのです。以上の例を一般化すると、OAuth 2.0に登場する要素は4つになります（図1）。

図1　OAuth 2.0に登場する4つの要素の関係

役割	実体
Resource Owner	エンドユーザー
Client	エンドユーザーに代わり、エンドユーザーにひも付くデータにアクセスするアプリケーション
Resource Server	Clientをエンドユーザーにひも付くデータにアクセスさせるためのAPIを提供するサーバ
Authorization Server	Clientをエンドユーザーにひも付くデータにアクセスさせるための許可を与えるサーバ

　OAuth 2.0では、これら4要素が関係した振る舞いについて、「登録」「許可」「アクセス」という3つの動作を定義しています。後ほど紹介するユースケースでは、遷移の中でこの3つの定義がどの範囲に当たるのかを示しています。それぞれのユースケースで以下の定義を振り返ってください。

• 定義1　Client Registration：ClientがAuthorization ServerやResource Serverへリクエストを送るために、自身の情報などを「登録」する（囲み記事参照）
• 定義2　Obtaining Authorization：ClientがAuthorization Serverに対してResource Ownerに代わり、Resource Serverへアクセスすることについての「許可」を求める
• 定義3　Accessing Protected Resources：ClientがResource Ownerに代わってResource Serverへ「アクセス」する

RFCが扱う範囲はどこまで？

　「RFC 6749 The OAuth 2.0 Authorization Framework」は、本文で触れた3つの定義のうち、定義1のClient Registrationから、定義2のObtaining Authorizationまで一連の処理を扱っています。

　RFC 6749はさまざまなユースケースに対応できる汎用的な内容になっています。このため、想定するClientの形態（Webアプリケーション、ネイティブアプリケーションなど）によって求められる実装が変わります。

　言い換えると、当時から多様性を意識していため、現在ではさまざまな企業やサービスがAPIを用いてビジネスを展開していく、いわゆる「APIエコノミー」を支える技術として幅広く利用されるようになりました。

　もう一方の「RFC 6750 The OAuth 2.0 Authorization Framework：Bearer Token Usage」は、本文中の定義3を定めています。Bearer Tokenという種類のアクセストークンを用いたAccessing Protected Resourcesの処理を扱っています。

RFC化されたOAuth 2.0の関連仕様

　RFC 6749やRFC 6750に続き、この5年の間にOAuth 2.0に関連する仕様が幾つかRFCとなりました（図A-1）。

図A-1　OAuth 2.0に関係したRFCの一覧

　詳細はIETF OAuth WGのページから参照できます。OAuth 2.0に関するセキュリティの脅威と対策をまとめたものや、ネイティブアプリケーションなどのOAuth 2.0を適用するユースケースに対して「こういう機能が標準化されているとより安全、便利になる」という拡張仕様などが定義されています。

OAuth 2.0に向き合う開発者層が変わった

　OAuth 2.0の仕様を参照する開発者の幅がこの5年間で広がったと、私はとらえています。OAuth 2.0に準拠したAPIを提供する側の開発者ではなく、APIを利用する側の開発者に注目します。

　「われわれのプラットフォームが提供するAPIは、OAuth 2.0の仕様に準拠している」と、あるサービス企業が発表したとしましょう。誰がOAuth 2.0の仕様を参照して、何を実装したのでしょうか。3つの場合が考えられます。

1. プラットフォーム利用側の開発者が自社プロダクトに実装
2. プラットフォーム利用側、または提供側の開発者が汎用的なライブラリとして実装
3. プラットフォーム提供側の開発者がSDKとして実装

　OAuth 2.0がRFC化された時点では、「OAuth 2.0の仕様に準拠することでAPI利用者もハッピーになれる」つまり、「1」の割合が多かったでしょう。

　その後、OAuth 2.0準拠のAPIが増えるにつれて「2」の割合が増え、さらに利用側の開発速度を高めるために「3」の割合も増えたと考えられます。OAuth 2.0を適用することが「当たり前」となったことで、仕様の詳細に触れずにOAuth 2.0が適用された仕組みを利用している開発者もいるでしょう。