第8章 マッシュアップ
セキュリティトークンとOAuth 2.0

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

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

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

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

709-01
図8-20: セキュリティトークンと引き換えに

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

OAuth 2.0の利用

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

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

アクセス権の委譲

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

708-02
図8-21: アクセス権の委譲

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

4つのグラント種別

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

(1) Authorization Codeグラント種別

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

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

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

備考:

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

(2) Implicitグラント種別

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

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

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

備考:

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

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

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

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

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

04-00
図8-24: Resource Owner Password Credentialsグラント種別
  1. ユーザ (リソース所有者) のパスワードとアクセス主体のクレデンシャルの両方を用い、アクセス主体が「認可サーバ」の認証を受ける
  2. 「アクセス主体」が直接「認可サーバ」からアクセストークンを受け取る

備考:

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

(4) Client Credentialsグラント種別

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

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

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

備考:

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

(5) その他

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

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

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

比較検討

結論

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

OAuth 2.0 におけるTLSの利用

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