第8章 10.セキュリティトークンとOAuth 2.0

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

OAuth 2.0は、アクセス認可の判断結果（誰々は、どこそこのリソースにアクセスしてよいということ）をネットワーク越しに安全に伝達することを目的としたプロトコル仕様である。このプロトコル仕様を公式に規定した RFC 6749,“The OAuth 2.0 Authorization Framework”（注釈）が2012年10月に発行された。

マッシュアップに使われる素材サーバ中のリソースを、資格あるユーザに対してのみ開示するように保護して制御する案件において、OAuth 2.0は有用な手段となる。

1. 注釈：
   RFC 6749,“The OAuth 2.0 Authorization Framework”

セキュリティトークンと引き換えにリソースを得る構図

マッシュアップに組み入れるゲストリソースには、有償のものや守秘性の高いものもあり得る。このようなリソースを提供する素材サーバは、通常、アクセス制限を設け、これらを保護するようにする。このような際の仕組みのひとつとして、利用資格のある存在（コンピュータ）が何らかのセキュリティトークンを提示すると、引き換えにリソースを受け取れる、という方式がある。

• 

主催者サーバは、所定のセキュリティトークンを添えて素材サーバへリソースを要求する。素材サーバは、そのセキュリティトークンが有効であることを確認した後に、主催者サーバへリソースを引き渡す。

OAuth 2.0の利用

上記の「セキュリティトークンと引き替えにリソースを得る構図」を実装するために、OAuth 2.0の「アクセストークン」 を利用することができる。

リソースの請求者からリソースの供給者へのアクセストークンの提示は、リソースを得ようとするHTTPリクエストの中にAuthorization: ヘッダを置き、そこへアクセストークンを記述することによって行われる。

アクセス権の委譲

ユーザ本人が素材サーバ内にもっているリソースを第三者（この場合はマッシュアップの「主催者サーバ」）に使わせたいケースがある。OAuth 2.0を利用して実装する際には、下図のようなフローでセキュリティトークンが発行され、主催者サーバによって行使される。

• 

上記の処理のフローは、OAuth 2.0の中で複数のフローが定義されている中の、「Authorization Code」と呼ばれるタイプのフローである。このフローを含めて、OAuth 2.0仕様には4つのフローが定義されている。また、OAuth 2.0においては、これらのフローのタイプを「グラント種別」と呼んでいるので、以降、この「グラント種別」という用語を用いる。

4つのグラント種別

4つのグラント種別（Grant Type）について、それぞれのフローを説明する。

(1) Authorization Codeグラント種別

「アクセス主体」(アクセストークンを行使し、保護されたリソースへのアクセスを行う存在) には、Webアプリケーションが想定される。

「アクセス主体」がアクセストークンの発行を受けるまでの流れ：

• 

1. 「アクセス主体」(アクセストークンを行使しようとしているWebサーバ、プロトコル上は「Client」と呼ばれる) は、「認可サーバ」 (アクセストークンを発行するサービス、Authorization Server) の画面がブラウザにロードされるよう仕向ける
2. 「ユーザ」(リソース所有者）が、「アクセス主体」を経由せずに直接「認可サーバ」と会話し、認証を受ける
3. 続いて「ユーザ」は、自分が所有するリソースへ「アクセス主体」がアクセスすることを許諾する旨、「認可サーバ」に向けて意思表示する。許諾の意思表示後、「アクセス主体」のWebコンテンツの新たなリクエストがブラウザから投入されるよう仕向けられる。（その際、呼び出しのURIに添えられたパラメータを通じて「認可コード」(Authorization Code) と呼ばれる中間段階のコードが「アクセス主体」へ伝達される。）
4. 「アクセス主体」は、ブラウザを経由せず直接「認可サーバ」と通信し、「認可コード」および自身のクレデンシャルと引き換えに、アクセストークンを受け取る

備考：リソース所有者は、ブラウザがやりとりするネットワーク通信が記録されるよう細工することによって、認可コードの値を知り得る。しかし、アクセストークンの値を知ることはできない。

(2) Implicitグラント種別

「アクセス主体」には、JavaScriptコードを主な内容とするWebアプリケーションが想定される。

「アクセス主体」がアクセストークンの発行を受けるまでの流れ：

• 

1. 「アクセス主体」のWebサーバからブラウザへロードされているJavaScriptコードが、「認可サーバ」の画面をロードするようブラウザに仕向ける
2. ユーザが、「アクセス主体」のクライアント側コードやWebアプリケーションを経由せずに、直接「認可サーバ」と会話し、認証を受ける
3. 続いて「ユーザ」は、自分が所有するリソースへ「アクセス主体」がアクセスすることを許諾する旨、「認可サーバ」に向けて意思表示する。許諾の意思表示後、「アクセス主体」のWebサーバからのコンテンツの新たなロードが行われる。（その際、ロードされたコンテンツ中のJavaScriptコードにURI中のフラグメント部分を通じてアクセストークンが伝達され、JavaScriptコードはその部分を読み出す。）

備考：ユーザ (リソース所有者) は、ブラウザがやりとりするネットワーク通信を記録することによってアクセストークンの値を知り得るという難がある。

Ajaxプログラミングの考察：

• このImplicit Grantグラントのフローを開始するJavaScriptコードと、アクセストークンを行使するJavaScriptコードとの間では、実行の文脈が連続していない。すなわち、両者の間でJavaScriptプログラミングにおける変数が引き継がれない
• Implicit GrantグラントをAjaxの中で用いる場合、作動し続ける親コンテンツの下位にiframeを用いて短命な子コンテンツを置き、そこでアクセストークンの取得処理を行う形が主に考えられる
• iframeの中でAuthorization Serverへのリダイレクト、ユーザによる使用許諾操作、元のサーバへのリダイレクトが行われる。取得されたアクセストークンを親コンテンツが受け取り、XMLHttpRequest level 2を用いたリソース取得において行使する。
• 子コンテンツと親コンテンツの間の連携は、直接の関数呼び出しもしくはpostMessageを用いる

(3) Resource Owner Password Credentialsグラント種別

「アクセス主体」には、ブラウザを用いないアプリケーションプログラムが想定される。

「アクセス主体」がアクセストークンの発行を受けるまでの流れ：

• 

1. ユーザ (リソース所有者) のパスワードとアクセス主体のクレデンシャルの両方を用い、アクセス主体が「認可サーバ」の認証を受ける
2. 「アクセス主体」が直接「認可サーバ」からアクセストークンを受け取る

備考：「アクセス主体」はユーザのパスワードを知ってしまうという難がある。

(4) Client Credentialsグラント種別

「アクセス主体」には、ブラウザを用いないアプリケーションプログラムが想定される。

「アクセス主体」がアクセストークンの発行を受けるまでの流れ：

• 

1. 「アクセス主体」のクレデンシャルのみを用い、「アクセス主体」が「認可サーバ」の認証を受ける。リソース所有者のパスワードは用いられない。
2. 「アクセス主体」が直接「認可サーバ」からアクセストークンを受け取る

備考：このClient Credentialsグラントは、ユーザ (リソース所有者) を認証しなくてもよい状況においてしかて使用できないという難がある。

(5) その他

上記以外のグラント種別を追加してもよいことが示唆されている。（RFC 6749, 「4.5 Extention Grants」）

どのグラント種別を使うか

4つのグラント種別のうち、どれを選択すべきであろうか？

比較検討

• Authorization Code以外のフローには何かしら難がある
• Implicitグラント種別では、アクセストークンが「ユーザ」 (リソース所有者) に容易に傍受されうる
• Implicitグラント種別では、「アクセス主体」のクレデンシャルの「認可サーバ」への提示が求められていない。（他のグラント種別では求められている。）
• Resource Owner Password CredentialsおよびClient Credentialsグラント種別においても、実装の仕方によってはアクセストークンが「ユーザ」 (リソース所有者) に傍受されうる
• Resource Owner Password Credentialsグラント種別では、「アクセス主体」が 「ユーザ」（リソース所有者）のパスワードを知ってしまう。（他のグラント種別ではそのようなことが起きにくい工夫が施されている。）
• Client Credentialsグラント種別が使えるのは、「ユーザ」(リソース所有者) を認証する必要がないときに限られる

結論

結局のところ、Authorization Codeグラント種別を用いるのが最も無難である。

クライアントマシンで動作する独立アプリケーションであっても、Resource Owner Password Credentialsグラント種別ではなく、Authorization Codeグラント種別を用いている例がある。そこでは、プログラム中からブラウザを起動し、リソース所有者が直接Authorization Serverから認証を受けられるようにしている。

OAuth 2.0 におけるTLSの利用

OAuth 2.0 のフローを構成するHTTPの各通信においてはTLS（SSL）を用いる必要がある。それは、次のような情報を第三者に傍受されないようにするためである。：

• ユーザ認証クレデンシャル
• 認可コード
• アクセストークン
• 保護されたリソースそのもの