みんな知るべきクラウド技術 「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 の仕組み)の理解は進まない。
当然だが「依頼に応える側」が『サーバ』だ。(そして依頼する側は『クライアント』と呼ばれる)

beer-server

 

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

一度は聞いた事がある「ゆーあい」(UI)と言う言葉。。。『USER インターフェース』の略だ。
ゲームに代表される「スマホアプリ」(「ネイティブアプリ」とも)の場合は、サーバから情報を受け取った「スマホアプリ」自身が「インターフェース」を表示する。また「汎用ソフト」(ブラウザ)の活用を前提とするシステムの場合は、『Web サーバ』自身が情報のレイアウトを配慮した上でデータを送信している。

いずれにせよ UI とは、USER (人間)に対する情報提供の仕組みであり、人間と近い機械が「情報のレイアウト」を行ってくれている。

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

 

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

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

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

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

web-servers

 

 

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

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

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

◆ 2-1. 『リクエスト』(依頼)の種類

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

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

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

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

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

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

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

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

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

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

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

request-method

 

◆ 2-2. 『レスポンス』(回答)の種類

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

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

「text/html」、「text/css」、「application/octet-stream」、「video/mpeg」。。。

非常に種類が多いのでアンマリ知らなくて良いが、(ワタシも良く知らない)、こちらも「テキスト情報系」と「画像系情報」がある。つまり、テキスト情報系なら『封筒』でよいが、画像系情報なら『小包』で返ってくるのだ。

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

responce-content

 

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

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

そう、今、コンピュータ達の間で流行している「中身」は『application/json』だ。
(「ジェイソン」と言っても「殺人鬼」ではない ←オキマリ)
API からの『レスポンス』(の中身)は「application/json」だったり、「application/soap+xml」だったりするのだ。既に説明したように、人間には読みづらい。が、機械には非常に読み易い。

ここで大切な事は、『レスポンス』だけでなく『リクエスト』でも、API との通信においては「人間には読みづらいフォーマット」が多用されていると言う事実だ。

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

json

 

 

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

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

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

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

<リクエスト例>
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 フォーマットで返ってくるのだ。

<レスポンス(抜粋)>
{
“kind”: “calendar#event”,
“status”: “confirmed”,
“created”: “2014-01-21T07:28:46.000Z”,
“updated”: “2014-01-21T07:28:46.357Z”,
}

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

例をもう一つ。

<リクエスト>
POST https://www.googleapis.com/blogger/v3/blogs/{TeamBlogId}/posts?isDraft=true
Content-Type: application/json

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

このリクエスト例は

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

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

<レスポンス(抜粋)>
{
“kind”: “blogger#post”,
“content”: “Hello<br> Hello<br> Hello<br>”,

}

oauth-setting

 

◆◆ 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 リソース」が使えない場合にはどの様な対策を取るべきか??と言った幅広い知識が必要になる??

 

◆◆ PS. 無料試用のススメ

クラウド型ワークフロー 『Questetra BPM Suite』 は、少人数なら無料で使い続ける事ができる!!そして、OAuth 2.0 のクライアント機能を標準装備している。

まだ、色々と機能制約はあるのだが、ぜひ一度試してみてもらいたい。
http://www.questetra.com/ja/free-saas-bpms/

 

◆◆ PS2. 専門家向けFAQ

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

 

IMAMURA Genichi の紹介

CEO & Founder - Questetra, Inc. || http://www.facebook.com/imamura.genichi
IMAMURA Genichi の投稿をすべて表示

あわせて読みたい
15.野望・展望・志 の前の記事 情報技術の未来予想、2014年新春
15.野望・展望・志 の次の記事 業務プロセスで「翻訳こんにゃく」を使う
IMAMURA Genichi の他の記事 クラウド型ワークフローのススメ

アーカイブ

 RSS