OAuth

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

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

概要

OAuth 2.0では以下の4種類のロール（役割）を考える^[2]：

• リソースオーナー (resource owner)
• リソースサーバー (resource server)
• クライアント (client)
• 認可サーバー (authorization server)

リソースオーナーが人間である場合は、リソースオーナーのことをエンドユーザーともいう。 認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでもよい^[2]。

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

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

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

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

アクセストークン

OAuth 2.0 におけるアクセストークン（英: Access Token）は保護リソースへのアクセス認可を表現する文字列である。言い換えれば、アクセストークンは認可クレデンシャルである^[3]。

OAuth 2.0 では、リソースオーナーは認可の範囲・期間が紐づいたアクセストークンをクライアントへ付与し^[4]、クライアントはこれを用いてリソースへアクセスする。リソースサーバーは認可クレデンシャルたるアクセストークンを見てアクセスを制御し、正統なリクエストにはリソースを返す。このように、アクセストークンは認可フレームワークである OAuth 2.0 の核をなす概念である。

アクセストークン方式にはセキュリティ上の利点がある。アカウントパスワード認証で認可をおこなう場合、クレデンシャル流出はパスワード流出そのものでありアカウント乗っ取りに直結してしまう。アクセストークンは限定的な認可情報のみをもつため、悪意あるクライアントやクレデンシャル流出が引き起こす悪影響を最小限（認可済みリソースへの不正アクセス）に留められる。

アクセストークンの内容・形式・伝達方法はOAuth 2.0 で規定されず、各リソースサーバーがそのセキュリティ要件に応じて定義できる^[5]。アクセストークンの実体の一例として、秘匿化されたランダム文字列や署名付き検証可能認可情報（c.f. JSON Web Token）が挙げられる^[6]。なお、認可の検証に追加クレデンシャルが必要か否か（=アクセストークン単体で必要十分とするか否か）はOAuth仕様の範囲外である（c.f. PoPトークン）^[7]。

認可グラント

OAuth 2.0 における認可グラント（英: Authorization Grant）はリソースオーナーの認可を表現しアクセストークン発行を可能にするクレデンシャルである^[8]。

平易な言い方をすれば「オーナーの認可を表現するアクセストークン引き換え券」が認可グラントである。認可サーバーでこの券を実際のアクセストークンに引き換えてもらうという手順を踏む。

OAuth 2.0 では4種類の認可グラントタイプを定義している。以下はその一覧である：

表. 認可グラントタイプの一覧

認可グラントタイプ名	クレデンシャル実体
認可コード（英: Authorization Code）
インプリシット（英: Implicit）	無し[9]
リソースオーナーパスワードクレデンシャル（英: Resource Owner Password Credentials）	ユーザ名+パスワード[10]
クライアントクレデンシャル（英: Client Credentials Grant）	クライアントの認証情報[11]

プロトコル

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

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

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

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

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

歴史

背景

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

OAuth 2.0

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

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