OAuthのまとめ情報

OAuth』の解説

OAuth (オー オース) は、権限の認可(authorization)を行うためのオープンスタンダードである。

2016年現在の最新の標準は、2012年にRFCとして発行されたOAuth 2.0である(、)ので、本稿でも以下、OAuth 2.0をベースに解説する。

概要

OAuth 2.0では以下の4種類のロール(役割)を考える:リソースオーナー(resource owner)、リソースサーバー (resource server)、クライアント (client)、認可サーバー (authorization server)。リソースオーナーが人間である場合は、リソースオーナーの事をエンドユーザーともいう。 認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでもよい。

このときユーザはサイトAの信任を得た認可サーバーから認証を受け、認可サーバーからサイトBのXに対するアクセストークン権限委譲用クレデンシャルともいう)を発行してもらい、サイトBにアクセストークンを渡す。以後、サイトBは必要に応じてサイトAにアクセストークンを見せる事で、Xを行う事ができるようになる。

ここで重要なのは、ユーザがサイトBにサイトAのパスワードを渡していない事である。上述のような権限の認可を行う最も簡単な方法の一つは、サイトAのアカウント用のパスワードそのものをサイトBに渡してしまう方法だが、この方法だと、写真の印刷には必要のない権限すらも全てサイトBに認可してしまう事になる。OAuthはこの単純な方法の欠点をなくした権限認可プロトコルである。

サイトAのアカウントとサイトBのアカウントが紐付けされてしまうセキュリティリスクが存在する。

プロトコル

OAuth 2.0のプロトコルフローは以下のとおりである:

  • (A) まずクライアントがリソースオーナーに認可要求(Authorization Request)を出す。図ではクライアントがリソースオーナーに直接要求を出しているが、認可サーバー経由で間接的に要求する事がのぞましい:
  • 認可コード:クライアントはリソースオーナーを認可サーバにリダイレクトし、認可サーバはリソースオーナーを認証した上で認可コード型の認可グラントを発行する。
  • インプリシット:スクリプト言語を使用してブラウザ上で実行されるクライアント向けに認可コードを最適化したもの
  • リソースオーナーパスワードクレデンシャル:ユーザ名とパスワードのペアのような、リソースサーバーへのフルアクセスを許す情報をリソースオーナーパスワードクレデンシャルと呼び、この情報を直接アクセストークンとして得る。
  • クライアントクレデンシャル:認可範囲がクライアントの管理下にある保護されたリソース, もしくはあらかじめ認可サーバーとの間で調整済の保護されたリソースに制限されている場合に用いる。

背景

マッシュアップによるWebサービスの連携が増え、デジタルアイデンティティの共有が問題となってきた。OpenIDのような連合アイデンティティが解決策として登場したが、これはIDの持ち主による認証手段であって、それによってどのリソースにアクセスできるかという認可については扱っていない。あるWebサービスAにユーザーの個人情報があるとき、そのWebサービスAと別のWebサービスBが連携し、WebサービスAにある個人情報をWebサービスBが自由にアクセスできる状況は好ましくない。そのため、WebサービスのAPIへのアクセスを認可する手段が必要とされていた。

OAuth 1.0

2006年11月、ブレイン・クックTwitterでのOpenID実装を行っていた。同じ頃、ソーシャルブックマークサイトの Ma.gnolia は、会員がOpenIDを使ってDashboardウィジェットからサービスにアクセスすることを認可する方法を必要としていた。そこでクックとクリス・メッシーナ、Ma.gnolia のラリー・ハーフはデビッド・リコードン(当時ベリサイン)と会い、OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論した。その結果、APIアクセス委譲についてのオープン標準はまだ存在しないという結論に達した。

OAuth のインターネットコミュニティは2007年4月に誕生し、少人数で新たなオープンプロトコルの草案を書いた。OAuthプロジェクトのことを知ったGoogleのデウィット・クリントンは、支援を表明した。2007年7月、チームは仕様の草案を完成させた。Eran Hammer-Lahav が加わって多数の協力者の調整を行い、より正式な仕様を作成していった。2007年10月3日、OAuth Core 1.0 の最終草案がリリースされた。

2008年11月、ミネアポリスで開かれた第73回のIETF会合でOAuthの非公式会合も開かれ、さらなる標準化に向けてIETFにOAuthプロトコルを提案するかどうかを議論した。会合は盛況で、IETFで正式にOAUTHワーキンググループを立ち上げることに幅広い支持が得られた。

セキュリティ

2009年4月23日、OAuth 1.0にセキュリティ問題があることが判明した。これは OAuth Core 1.0 Section 6 にあるOAuth認可フロー(3-legged OAuth)に影響がある。この問題は、OAuth 1.0a にて修正された。

OAuth 2.0

OAuth 2.0は次世代のOAuthプロトコルであり、OAuth 1.0とは後方互換性を持たない。OAuth 2.0はクライアントとなるウェブアプリケーション、デスクトップアプリケーション、スマートフォン、リビングデバイス等のアプリケーションの開発者に対し、リソースアクセス権限を付与する簡単な方法を提供する。この規格は開発途上である。

Eran Hammer-Lahavによれば、IETF OAuthワークグループは2010年終わりごろまでの範囲での締結を期待していたが作業は大幅に遅延し、2012年8月にようやくRFCエディタへ送付された。

仕様は中心になる The OAuth 2.0 Authorization Framework の他、など幾つかに分割されている。

facebookの新しいGraph APIはOAuth 2.0 Draft 10 のみをサポートし、OAuth 2.0 としては最大の実装の一つである。 2011年現在、Google およびマイクロソフトは OAuth 2.0による実験的なAPIを提供している。

OAuth』に 関連する人気アイテム

Webを支える技術 -HTTP、URI、HTML、そしてREST

2010年の本。著者はリコーのエンジニア。
曰く・・・
HTTP 1.0がIETF(Internet Engineering Task Force)で標準化された最初のバージョン。そのあと、1997年にHTTP 1.1が策定される。その後、改訂され、これが現在のHTTP 1.1仕様につながる。HTTP 1.1が策定されてからもHTTPの議論は続けられたが、結局、HTTP自身のバージョンアップは行われていない。ただし、WebDAVなどHTTPの拡張仕様はいくつか公開されている。

HTTP 1.1を有効に活用していこうというのが現代的な開発スタイルになっている。
サーバがクライアントの状態をおぼえる「ステートフル型」は、クライアント数が増えると苦しくなる。ステートレス型では、クライアントがリクエストメッセージに必要な情報のすべてを含める(自己記述的メッセージ)。ステートレス型では、クライアントは自らのアプリケーションの状態を覚え、すべてのリクエストを自己記述的メッセージで送信する。ステートレス型はスケーラビリティに優れるが、クライアントは毎回必要な情報をすべて送信せねばならず、送信データ量が多くなるし、認証などサーバに負荷のかかる処理を繰り返すためパフォーマンスが悪くなる。自己記述的メッセージもどうしても冗長になる。
構造化文書のためのマークアップ言語としてはもともとSGMLがあった。初期のHTMLはSGMLがベースだった。しかし、SGMLは作りづらさがあり、仕様をシンプルにしたXMLが開発される。XMLベースに変えた仕様がXHTML。
XMLは自由にタグが作れるマークアップ言語であるとされるが、XMLの本当の利点は既存のフォーマットに不足があればあとからタグを足して拡張できること。XML表現を選択する際の重要な指針は、独自フォーマットを作りださない、こと。
などなど。

Webシステムの実装に必要な基本知識をまとめて解説した本。REST(Representational State Transfer), URI, HTTP, JSON, JSONとクロスドメイン通信, RDF(Resource Description Framework)とmicroformats, Atom, OpenSearch, AtomPub, リソース設計のポイント、といったことが書かれてある。なぜSOAPからRESTになってきたのか、というような歴史的な経緯も最初に触れられている。

適時HTMLヘッダの例やサーバからの応答メッセージの例が掲載されていて、具体的に確認できる。

MIMEのタイプなどは一覧で示してある。また、Webサービスの設計においては、WebDAVのLOCK/UNLOCKメソッドを使う方法やLOCK相当の機能をWebサービスに組み込む方法などが解説されている。競合が発生したときだけ対処するために条件付きPUTを使う「楽観的ロック」についても説明されている。付録のステータスコード一覧やHTTPヘッダ一覧も、わかりやすくまとめられていて実用的なリファレンスになっている。

全体的にWebを支える技術が適切かつ具体的にまとめられていて、なかなか良い本だった。ただ、認証方式の解説でとりあげられているのがBasic認証とDigest認証、そしてWSSE認証がわずかにあるだけで、OpenIDとOAuthについてはまとめて1ページの簡単な補足説明のみになっている。

Webに関する基本的な技術に関する書籍だと思って軽い気持ちで読み始めたら、その内容の濃いこと。 特にREST、HTTP、サービス設計に関する部分は熟読した。 第4部のmicroformatsやatomの記載は深入りしすぎていると感じて軽く流したという感じ。 Webの基本技術は大抵理解していると勘違いして勝手に持っていた自信を失わせてくれ、真摯に勉強しようという気になった。 とにかくWeb技術の教科書としては優秀な書籍である。

Webエンジニアの教科書

5つ星のうち 3.0帯に短し、襷に長し

(参考になった人 13/16 人)

教科書という割には基礎が薄く、個々のツールの操作方法を総花的になぞっただけの印象が強いです。
個々の説明を脈絡なく寄せ集めただけで、「Webエンジニアはこうあるべき」というビジョンが見えませんでした。
軽く流し読みしてみただけでも、たとえば以下のような疑問が生じました。

・Rails,PHP,HTML5などの説明があるけど、HTTPプロトコルや画像の圧縮形式などの説明が薄い
・NoSQL(RedisとMongoDB)の説明があるけど、実務上切り捨てる訳にはいかないはずのRDBMSの説明が雑
・JavaScriptを大して説明しないままに、jQueryやCoffeeScriptなどフレームワークの説明に終始している
・データ分析の重要性を語るのであれば、Fluentdで吐いたログを単に可視化するだけでは不十分ではないか?
仮説検証するなら、本書で紹介されたツールよりは、ExcelやSQLで対話的に分析した方が断然便利なはず
・そもそも、Webエンジニアにとっては土俵であるはずの、ApacheやNginXといったWebサーバに関する章がない
"必要とされる技術領域"として冒頭で紹介されているものは、果たして必要十分な内容なのか?

おそらく初期の企画案では、最近Web開発で使用されるようになった話題性のあるツールを一揃い紹介するというものが、
タイトルに「教科書」と冠してしまって、余計な項目や想定読者が追加されたのではないでしょうか。



本書の想定読者のうち、「最新の動向を知っておきたいエンジニア」には本書はおすすめできます。
紹介されているツールはどれも便利で習得する価値のあるものです。
著者らのいうように、Webエンジニアに求められる知識は年々広汎になってきています。
Webサイトの情報を集めて学習する時間的コストを考えると、一冊の書籍でキャッチアップできることに価値は十分あります。

しかし、「これからWebエンジニアになろうとしている人」や「Webエンジニアになって2、3年目の人」という読者には
下手な背伸びよりはもっと基礎的な技術力を身につけて欲しいので、本書を彼らへの教科書としてはおすすめしません。
まずは「Webを支える技術(山本 陽平)」などの方をおすすめします。

「Webエンジニアになって2、3年目の人」
「最新の動向を知っておきたいエンジニア」などにオススメと書いてありますが、
Webエンジニア志望か1年目の人向けだと思います。
最新の動向というほど最新の内容ではないと思います。

この本の主眼は、「こんな技術・ライブラリがあります」という紹介であって、
概要の説明はありますが、何かを解説しているというほどではありません。
インストール方法や簡単なコード例も載っていますが、調べればすぐに見つかる内容です。


ただ、知らないものは調べづらいので、技術の存在を知るには良いでしょう。

Webエンジニア志望の人や、Web開発の一部分しか担当していない人が
全体を俯瞰して、どんな技術があるのか概要を把握するためには良い本だと思います。

4時間ほどで読めた。 プログラミング言語からミドルウェア、 仮想の環境構築までわかりやすく紹介されている。 新しい技術が次々と出てくるIT業界では常に勉強することが求められます。 しかし、中々追い続けることは大変です。 本書はひと通りの技術がわかりやすく紹介されているので、 聞いたことはあるけど、 どのような技術なんだろうと思っている人には大変役に立つ内容です。 こんなに便利なものがあるんだ触ってみようと思う技術もきっと紹介されているはずです。 エンジニア志望の学生や若手エンジニアの方が読むにはぴったしの内容だと思います。

OAuth』by Google Search

This page is provided by Matome Project.
Contact information.