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

0. 進化する Web 技術

時代の流れは非情だ。

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

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

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

1. OAuth 理解に重要な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 だけで良い。例えば「 https://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)
https://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]
  • https://tools.ietf.org/html/rfc6749
  • https://tools.ietf.org/html/rfc6750
  • https://openid-foundation-japan.github.io/rfc6749.ja.html
  • https://openid-foundation-japan.github.io/rfc6750.ja.html

5. まとめ

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

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

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

PS. 無料試用のススメ

クラウド型ワークフロー 『Questetra BPM Suite』 は、少人数なら無料で使い続ける事ができる！！そして、OAuth 2.0 のクライアント機能を標準装備している。まだ、色々と機能制約はあるのだが、ぜひ一度試してみてもらいたい。

PS2. 専門家向けFAQ

アクセストークンは HTML ヘッダ部にて送出されマス。ファイル型データはファイル名が送出されます。同一パラメータ名で複数データを送出する設定にすれば配列になります。今（v9.8）のところ「多階層な json データ」をリクエスト送出する事はデキマセン。

「スクリプト工程」や「Addon サービス工程」（自作の自動工程）などで、多階層な json を送出することが可能です（20160905, v11.1～）