OAuth

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

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

概要

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

これら４つのロールを具体例に即して説明する。今、ウェブサイトA（リソースサーバー）にアカウントを持っているユーザ (リソースオーナー)がいたとし、ユーザがAとは別のサイトB（クライアント）にサイトAに保管されているリソースに対して何らかの行動Xを行う権限を与えたい（認可したい）とする。具体的にはサイトAが写真保管サービスでサイトBが印刷サービスだとすると、ユーザが「Aに保管されているリソース（＝写真）へのアクセス」という権限XをサイトBに与えることでユーザはBから写真を印刷する事ができる^[3]。

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

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

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

プロトコル

OAuth 2.0のプロトコルフローは以下のとおりである^[4]：

クライアント	─(A) Authorization Request→	リソース オーナー
	←(B) Authorization Grant─
	─(C)Authorization Grant →	認可 サーバー
	←(D) Access Token───
	─(E) Access Token──→	リソース サーバー
	←(F) Protected Resource─

• (A) まずクライアントがリソースオーナーに認可要求（Authorization Request）を出す。図ではクライアントがリソースオーナーに直接要求を出しているが、認可サーバー経由で間接的に要求する事がのぞましい^[4].
• (B) リソースオーナーは認可要求を許諾する旨の返答として認可グラントをクライアントに送る。これも認可サーバー経由で行う事がのぞましい^[4]
• (C) クライアントは認可サーバーに認可グラントを送ることでアクセストークンを要求
• (D) 認可サーバーはクライアントの認証と認可グラントの正当性の検証を行い、問題なければアクセストークンを発行。
• (E)クライアントはアクセストークンにより認証を受けることで、保護されたリソースへのアクセスをリクエスト
• (F) アクセストークンが正当なら、クライアントのリクエストを受け入れる

認可グラントにはその発行の方法に以下の４タイプがある^[5]：

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

歴史

背景

マッシュアップによる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）に影響がある^[6]。この問題は、OAuth 1.0a にて修正された。

OAuth 2.0

OAuth 2.0は次世代のOAuthプロトコルであり、OAuth 1.0とは後方互換性を持たない。OAuth 2.0はクライアントとなるウェブアプリケーション、デスクトップアプリケーション、スマートフォン、リビングデバイス等のアプリケーションの開発者に対し、リソースアクセス権限を付与する簡単な方法を提供する。この規格は開発途上である。 ^[7] (Eran Hammer-Lahav)によれば、IETF OAuthワークグループは2010年終わりごろまでの範囲での締結を期待していた^[8]が作業は大幅に遅延し、2012年8月にようやくRFCエディタへ送付された。 仕様は中心になる The OAuth 2.0 Authorization Framework ^[9] の他、^[10]など幾つかに分割されている。

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

脚注

1. ^ For immediate release: OAuth Core 1.0 Specification released at Internet Identity Workshop 公式ブログ内に「OAuth (pronounced “Oh-Auth”)」の記載あり（記事アーカイブ）
2. ^ ^{a b} RFC 6749日本語訳 1.1節
3. ^ この写真の例は、RFC日本語訳 1章冒頭に記載されているものを参考にした。
4. ^ ^{a b c} RFC6749日本語訳 1.2節
5. ^ RFC6749日本語訳 1.3節
6. ^ Oauth (2009年4月23日). “OAuth Security Advisory: 2009.1”. 2009年4月23日閲覧。
7. ^ “The OAuth 2.0 Authorization Protocol” (2011年2月16日). 2011年11月28日閲覧。
8. ^ Eran Hammer-Lahav (2010年5月15日). “Introducing OAuth 2.0”. 2011年3月14日閲覧。
9. ^ “Dick Hardt, Ed. "The OAuth 2.0 Authorization Framework"”. 2016年3月30日閲覧。
10. ^ “Michael B. Jones, Dick Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage"”. 2016年3月30日閲覧。
11. ^ “Authentication - Facebook Developers”. developers.facebook.com. 2011年11月28日閲覧。
12. ^ “Making auth easier: OAuth 2.0 for Google APIs”. googlecode.blogspot.com (2011年3月14日). 2011年11月28日閲覧。
13. ^ Dare Obasanjo (2011年5月4日). “Announcing Support for OAuth 2.0”. windowsteamblog.com. 2011年11月28日閲覧。

関連項目

• OpenID
• DataPortability

出典・外部リンク

• OAuth.net
• OAuth.jp
• RFC6749 The OAuth 2.0 Authorization Framework 日本語訳
• OAuth Googleグループ
• Beginner’s Guide to OAuth on Hueniverse
• Google OAuth & Federated Login Research
• Yahoo! OAuth Quick Start Guide
• OpenID Foundation Japan - 翻訳・教育 Working Group OAuth 1.0 & 2.0翻訳版など
• APIアクセス権を委譲するプロトコル、OAuthを知る 作島立樹、@IT、2008年1月21日
• 特集：ゼロから学ぶOAuth 真武信和、gihyo.jp、2009年3月31日
• OAuth 2.0でWebサービスの利用方法はどう変わるか 木村篤彦、@IT、2011年2月2日
• 「OAuth」の基本動作を知る Nov Matake、@IT、2012年8月27日
• OAuth 2.0の代表的な利用パターンを仕様から理解しよう Nov Matake、Build Insider、2017年7月21日
• 「OAuth 2.0」の基本動作を知る (1/4) Ryo Ito、@IT、2017年9月1日