みんな知るべきクラウド技術「OAuth」ってナニ？

ビールサーバも、Web サーバも、OAuth （おーおーす）サーバも似たようなものだ！大切な事は、「リクエスト」（依頼）と「レスポンス」（返答）で通信されている、と言う事実！

0. 進化する Web 技術

時代の流れは非情だ。

『HTTPS』、『OpenID』、『OAuth』。。。一般ユーザもキチンと理解しておいた方が良い「基礎技術」が、日々、高度化・複雑化しているのだ。

情報通信技術の進化の早さの中にあっては、俗に「ITベンチャー」と呼ばれる会社に勤めているプロ達(？)ですら、理解する時間を取れずに居る人も少なくない。例えば、今や非常に多くのサイト/アプリで活用されている「パスワード不要の連携技術」（OAuth）も、その概要が深く理解されていないのが実情だ。

今回は、「最新の Web 技術」の概要を、一般のビジネスユーザにも何となく理解してもらえるように、平易に解説してみようと思う。「サーバとは何か？」から始めて「OAuth とは何か？」まで。。。

「ナンデ？」

動機は若干不純だが、我が社（クエステトラ社）のワークフロー製品『Questetra BPM Suite』の「他システム連携機能」がパワーアップし、ますます最先端の技術用語を説明する機会が増えたからだ。。。(??!)

※ クエステトラ：クラウド型ワークフロー、マッシュアップ機能を強化
～Force.com 等の OAuth 2.0 リソースにもアクセス可能に～ (2014-01-20)
http://www.questetra.com/ja/info/oauth-connection-20140120/

1. Web 技術理解に重要な2つの用語

サーバとは何か？ API とは何か？

1-1. 「サービス」するから『サーバ』！

サーバとは何か？

『Web サーバ』と聞けば、どうしてもメマイがするが、『ビールサーバ』と聞けば、ニコヤカになる。。。（まーそんなモンだ）

しかし良く考えれば、サービスする機械だから「サーバ」なのだ。この両者に大した違いはない。確かに『Web サーバ』(実物)を目にする機会はほとんど無いが、恐れることはない(？)。「インターネットの中で、何かサービスをしてくれる機械」と言うだけの話だ。

ここで大切な事は、インターネット（≒HTTP/HTTPS）の世界では「リクエスト」（依頼）と「レスポンス」（返答）で成り立っている、と言う事実だ。意外とココを忘れてしまっている人が多い。しかしコレを認識していないと、Web 技術（Web の仕組み）の理解は進まない。当然だが「依頼に応える側」が『サーバ』だ。（そして依頼する側は『クライアント』と呼ばれる）

1-2. 誰かに向いてるから『インターフェース』？

一度は聞いた事がある「ゆーあい」（UI）と言う言葉。。。『USER インターフェース』の略だ。

ゲームに代表される「スマホアプリ」（「ネイティブアプリ」とも）の場合は、サーバから情報を受け取った「スマホアプリ」自身が「インターフェース」を表示する。また「汎用ソフト」（ブラウザ）の活用を前提とするシステムの場合は、『Web サーバ』自身が情報のレイアウトを配慮した上でデータを送信している。いずれにせよ UI とは、USER （人間）に対する情報提供の仕組みであり、人間と近い機械が「情報のレイアウト」を行ってくれている。

＃「ウチのシステムは UI にコダワッテまして、是非この洗練された UI を…」などと、ユーザが見える部分だけを説明されると、個人的には「中の仕組みは洗練されてないのん？」とか「システム全体の仕組みを説明してよん？」とか思ってしまう。が、そんな話はどうでもイイ。

一方、ちまたでウワサ（？）の「えーぴーあい」（API）は、『PROGRAM インターフェース』だ。

ナンてことは無い、「ゆーあい」（UI）の相手は『USER』だったが、「えーぴーあい」（API）の相手は『PROGRAM』だ。つまりプログラム（ソフト）に対する情報提供機構を指している。この場合、人間にとって理解しやすい情報レイアウトにする必要が無い。むしろ「人間にとって心地よいデザイン要素」なんて無用だ。（※ Application Programming Interface ）

さて、、、ここで大切な事は、

コンピュータは「人に対して情報を提供する」以外にも
コンピュータは「機械同士で情報を提供しあっている」

と言う現実だ。実際、「(1)スマホ (2)サーバ (3)他のサーバ」と言った連鎖的な通信はガンガン行われているし、人間（USER）が寝ている時間帯ですら、サーバ同士で様々な通信が行われている。意外と忘れがちなのだがこの「機械同士で情報を提供しあっている」と言う事実を認識していないと、Web 技術（Web の仕組み）の理解が進まない。

2. 『リクエスト』と『レスポンス』

目を閉じる。。。

インターネット上に無数の『リクエスト』が飛んでいる。。。

「サーバの存在」(1-1)と「サーバのインターフェース」(1-2)について認識すると、その様子がイメージできる。。。（ん？デキルか？デキルのか？？）

2-1. 『リクエスト』（依頼）の種類

まずはその発信、つまり『リクエスト』について、掘り下げてみたい。。。

A. リクエストの際に、何も渡さない
B. リクエストの際に、何かを一緒に渡す

まずもって『リクエスト』には2種類ある。（ホントはもっとある）

マッコウ真正面から説明しても認知しづらいので、ビールサーバをイメージしてもらいたい。「ハンドルだけのビールサーバ」と「自販機っぽいビールサーバ」をイメージする。なるほど、同じリクエストでも「お金」が必要なサーバと、そうでないサーバが存在するのだ。(!!?)

インターネット上に飛び交っている『リクエスト』にも「a.簡単なリクエスト」と「b.中身のあるリクエスト」の２種の依頼方法がある。(!!)

a. 葉書っぽい『リクエスト』
b. 封筒/小包っぽい『リクエスト』

両者の違いは「中身」のアルナシだ。

「a.簡単なリクエスト」の場合、いわゆる URL だけで良い。例えば「 http://www.questetra.com/ja/blog/ 」と書けば、それは「ブログを表示して」と依頼している事になるのだ。この方法をクロウト達は『GETメソッド』と呼んでいる。「プロ達」は「あー、そのデータは GET で受け渡しするんだよ」とかワケの分からん表現をするのだが、要は「a.簡単なリクエスト」と言う事だ。

一方「中身のあるリクエスト」は URL だけでは済まない。アンケートフォームに答えたり、画像情報をアップロードしたりする際には、『封筒』や『小包』にして「リクエスト」を渡さなければならない。この方法を『POSTメソッド』と呼んでいるのだ。

ん。待てよ。『封筒』と『小包』もナンカ違う？　そう、『封筒』の場合はテキスト情報だけが入っているのに対して、『小包』の場合は写真や動画などバイナリ情報が入っているのだ。

と言う事で、『リクエスト』を大別すれば、以下の３種類が実存する。（ぎゃー、、、メマイが、、、）

a. 葉書⇒ 「GETメソッド」
b1.封筒⇒ 「POSTメソッド (application/x-www-form-urlencoded)」
b2.小包⇒ 「POSTメソッド (multipart/form-data)」

＃深夜ラジオに「チェッカーズの新曲、流して！」と依頼するリクエストは、ハガキだ。（どうでもイイ）
＃あ、「涙ぁ～のぉ～、リクエぇ～スト」は、誰に何をリクエストしてたのだろう。（どうでもイイ２）

2-2. 『レスポンス』（回答）の種類

では、（『リクエスト』に応答する）、『レスポンス』には、どんなものがあるのだろう？　（頑張ってイコー）＞自分

考えてみれば難しいことではないが、『レスポンス』（返信）には必ず「中身」がある。

「text/html」、「text/css」、「application/octet-stream」、「video/mpeg」。。。非常に種類が多いのでアンマリ知らなくて良いが、（ワタシも良く知らない）、こちらも「テキスト情報系」と「画像系情報」がある。つまり、テキスト情報系なら『封筒』でよいが、画像系情報なら『小包』で返ってくるのだ。

ここで大切な事実は、『レスポンス』も『リクエスト』と非常に似ていると言う事だ。実際、両者は共に「メッセージ」と呼ばれる。ちなみにレスポンスの『封筒』や『小包』には、（『リクエスト』（依頼）には必須だった）、「URL」や「メソッド命令」はない。

2-3. API への『リクエスト』と API からの『レスポンス』

いや、待てよ・・・。

イマドキの Web 通信は「コンピュータ同士もすなる」とぞ言ふ。

そう、今、コンピュータ達の間で流行している「中身」は『application/json』だ。（「ジェイソン」と言っても「殺人鬼」ではない ←オキマリ）

API からの『レスポンス』（の中身）は「application/json」だったり、「application/soap+xml」だったりするのだ。既に説明したように、人間には読みづらい。が、機械には非常に読み易い。ここで大切な事は、『レスポンス』だけでなく『リクエスト』でも、API との通信においては「人間には読みづらいフォーマット」が多用されていると言う事実だ。

＃ちなみに json や xml はテキストなので、画像系データを載せづらいと言う弱点がある。

3. 具体的な API リクエスト

さて、、、ここまでの説明を踏まえて、『API リクエスト』の例を見てみよう。

3-1. 事例：カレンダー予定の追加

いきなり、リクエスト例を書いてみる。簡単追加（quickAdd）と言う API を使っている。

Request:

POST https://www.googleapis.com/calendar/{TeamCalendarID}/events/quickAdd
Content-Type: application/x-www-form-urlencoded

text=Meeting 2014-01-22

「にゃるほどぉー！！」と、1人にでも言ってもらえれば、この記事を書いてよかったのだが、どうだろう？

先頭のPOSTとContent-Typeの説明で、「封筒(POST)でリクエストするよー」と言って、URL部で、「カレンダ{TeamCalendarID}に、予定(events)を追加してー」と言って本文で、「予定の内容は「Meeting 2014-01-22」だよー」

と言っているのだ。するとすかさずサーバから「登録したぜ」と言う内容が json フォーマットで返ってくるのだ。

Response:

{
  “kind”: “calendar#event”,
  “status”: “confirmed”,
  “created”: “2014-01-21T07:28:46.000Z”,
  “updated”: “2014-01-21T07:28:46.357Z”,
}

3-2. 事例：ブログ原稿の投稿

例をもう一つ。

Request:

POST https://www.googleapis.com/blogger/v3/blogs/{TeamBlogId}/posts?isDraft=true
Content-Type: application/json

{
  “content”: “Hello<br>Hello<br>Hello”
}

このリクエスト例は

先頭で、「封筒で(POST)でリクエストするよー」
URLで、「ブログ{TeamBlogId}に、草稿を追加してー」
本文で、「草稿の内容は「Hello<br> Hello<br> Hello<br>」だよー」

と言っている。こちらはリクエスト本文にも json が使われている例だ。そして返事にも恐怖の json 殺人鬼が…。

{
  “kind”: “blogger#post”,
  “content”: “Hello<br> Hello<br> Hello<br>”,
  ...
}

4. 誰が許したリクエスト？

「API へのリクエスト」と「API からのレスポンス」が解読できる様になった。（へ？、なった？？）

しかし、誰でもリクエストできるワケでは無い。つまり権限の問題がある。そこで重要な技術は「許可」の技術だ。その名も「おーおーす」（OAuth）と言う。いまや Facebook Twitter などなど、さまざまなサービスで利用されている。

そう言えば、会議の場で「その件は未だ社内で“オーソライズ”されて居ないので云々」などと発言するオトナ達がいるが、あの “オーソライズ” と同じ言葉だ。Web サーバ間の OAuth 通信も、システムユーザに「オーソライズ」された通信しかできない。

以下は、「システム利用者」ではなく、「システム運用者/設定者」や「業務プロセス設計者」が知るべき知識を書く。つまり日頃ユーザとして利用するだけの方は、以下の内容までは知る必要が無い。

ちなみに、この「許可」(認可)と言う概念は、「IDパスワードを渡す」(認証)の概念と本質的に違う。例えば、「許可」であれば後で取り消せるが、「IDパスワード」を忘れてもらう事はコンナンだ。

4-1. OAuth 2.0 通信の設定

OAuth 通信設定とは、要するに「自動送受信の御膳立て」だ。大きな流れは以下の通りとなる。

しかしこの「許可設定」は、実際に設定画面と格闘してもらう方が早い。手順等を詳細に書いたとて、ナカナカ頭に入るものでもない。と言う事で、無責任な話ながら、まずは「Googleコンソール」にアクセスし、新しい「Project」を作成する所から始めるのをオススメする！ ※ https://cloud.google.com/console/project

1) 自動接続の受け入れ設定（Google側）
1-1. 連携設定ユーザが「Googleコンソール」にアクセス
1-2. [Credential](証明書)メニューに移動し「CLIENT ID」を作成
– 要 Questetra の「Callback URL」
1-3. 『Client ID』と『Client secret』を取得

2) 自動発信の設定（Questetra側）
2-1. プロセスモデル（業務プロセス定義）を作成
2-2. 日付型のデータ項目、文字列型のデータ項目を作成
2-3. 自動送信文字列の生成
2-4. 自動送信アイコンの[OAuth 2.0 設定]に証明書を登録
2-5. 自動送信アイコンの「通信設定」にて送信先を設定

＜より詳細には…＞
◇クラウド型 Workflow と Google Calendar (OAuth 2.0 連携) (2014-01-27)
http://ja.workflow-sample.net/2014/01/oauth2-google-calendar.html

4-2. OAuth 2.0 通信の基礎知識

Credential （証明書）

OAuth サーバ側で、特定の通信に対して発行する証明書

OAuth 2.0 サーバの種類

A. 接続許可証（Access Token）のみを提供する API
B. 接続許可証を更新する仕組み（Refresh Token）併せて提供する API

1. 許可の範囲（Scope）の指定が必須の API
2. 許可の範囲（Scope）の指定が任意の API

OAuth 2.0 の構成
a. OAuth 2.0 クライアント
– a1. Web Application に組み込まれたプログラム（Webサーバー上 Confidential クライアント）
– a2. Web クライアント等に組み込まれたプログラム（User-agent-based application）
– a3. Android/iOS等ローカルアプリに組み込まれたプログラム（Native application）
b. OAuth 2.0 認可サーバ（アクセストークンを発行する：Authorization Server）
c. OAuth 2.0 リソースサーバ（データ提供等を行う：Resource Server）

OAuth 2.0 の用語
[Consumer key] クライアントを識別するID（client_id）
[Consumer secret] クライアント識別IDとペアの秘密鍵（client_secret）
[Authorize URL] エンドユーザーがクライアントにリソースの使用許可を出す確認画面
[Redirect URI] クライアントが認可コードなどを受け取ることになるエンドポイント

◆OAuth 2.0 通信の仕様 [RFC6749,RFC6750] http://tools.ietf.org/html/rfc6749
http://tools.ietf.org/html/rfc6750
（和訳）
http://openid-foundation-japan.github.io/rfc6749.ja.html
http://openid-foundation-japan.github.io/rfc6750.ja.html

5. まとめ

サーバへの「リクエスト」には POST/GET と言う依頼の種類がある。
サーバへの「リクエスト」中身がある時とない時がある。
サーバからの「レスポンス」には色々な中身がある。
コンピュータ同士の API 通信では「json」と言うテキストやり取りが流行しているらしい。

非常に乱暴な概説だったが、まずはこの程度の「システム構築知識」があれば自動連携通信の設定ができるようになる。以上の知識に「プログラミング知識」は要らない。

しかし、、、クラウド時代のシステムインテグレータ（システム構築）はタイヘンだ。
つまるところ、世界中の「OAuth リソース」を活用する事になるのだ。そこにはいわゆる通信知識だけでなく、どこにどの様な「OAuth リソース」があるか？、その利用コストはどの程度か？、あるいは「OAuth リソース」が使えない場合にはどの様な対策を取るべきか？？と言った幅広い知識が必要になる？？