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

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

1 概要

2 プロトコル

3 歴史

3.1 背景

3.2 OAuth 1.0

3.3 セキュリティ

3.4 OAuth 2.0


4 脚注

5 関連項目

6 出典・外部リンク

概要

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ワーキンググループを立ち上げることに幅広い支持が得られた。
セキュリティ