OAuth

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

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

概要

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

• リソースオーナー (resource owner) :リソースの所有者であり、一般的にエンドユーザーを指す。
• リソースサーバー (resource server):保護されたリソースを管理しているサーバ（例: あるサービスのAPIを提供するサーバ）。
• クライアント (client):リソースオーナの許可を得て、リソースサーバ上の保護されたリソースにアクセスするアプリケーション。
• 認可サーバー (authorization server):リソースオーナの同意に基づき、クライアントに対してアクセストークンを発行するサーバ（例: あるサービスの認可機能を持つサーバ）。認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでもよい^[2]。

これら4つのロールを具体例に即して説明する。

1. 前提：今、ウェブサイトA（リソースサーバー）にアカウントを持っているユーザー（リソースオーナー）がいたとし、ユーザーがAとは別のサイトB（クライアント）にサイトAに保管されているリソースに対して何らかの行動Xを行う権限を与えたい（認可したい）とする。具体的にはサイトAが写真保管サービスでサイトBが印刷サービスだとすると、ユーザーが「Aに保管されているリソース（＝写真）へのアクセス」という権限XをサイトBに与えることでユーザーはBから写真を印刷することができる^{[注釈 1]}。
2. 認可要求：ウェブサイトB（印刷サービス）を利用したいユーザーは、Bのサイト上で「A（写真保管サービス）の写真を使って印刷する」といった操作を開始する。これをトリガーに、サイトBは、ユーザーを。サイトAの認可サーバへリダイレクトさせ、写真へのアクセス権限を要求する。
3. 同意と認可コード発行：サイトAの認可サーバは、ユーザーに対してサイトAへのログインを求め、本人確認を行う。その後、「サイトBがあなたの写真にアクセスすることを許可しますか？」といった同意画面を表示する。ユーザーがこれに同意すると、認可サーバは一時的な認可コードを発行し、ユーザーをサイトBへリダイレクトする。
4. 認可コード取得：サイトBは、ユーザーから受け取った認可コードを、裏側で（ユーザーには見えない形で）サイトAの認可サーバへ送信します。
5. トークン発行：サイトAの認可サーバは、受け取った認可コードが正当なものであることを確認し、問題がなければサイトBに対して正式なアクセストークン（権限委譲用クレデンシャルともいう）を発行する。
6. リソースアクセス：以後、サイトBは印刷などの処理が必要になるたびに、このアクセストークンを提示してサイトA（リソースサーバ）にアクセスし、ユーザーの写真データを安全に取得できるようになる。

ここで重要なのは、ユーザーがサイト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 1.0は、委任認可の分野における画期的な標準であったが、そのプロトコル設計には、実装の複雑さや将来の技術的進歩への対応力といった点で、いくつかの根本的な課題が存在した。

• OAuth 1.0の署名生成は、3-leggedフローという複雑で、パラメータのエンコーディングや並び順など、細部にわたる厳密なルールに従う必要があった。このため、開発者がゼロから実装することは極めて困難であり、多くの場合、特定のライブラリに依存せざるを得ないという問題があった^[15]。
• OAuth 1.0は、ブラウザベースのWebアプリケーションを主要なターゲットとして設計されていた^[16]。そのため、当時台頭しつつあったネイティブのデスクトップアプリケーションやモバイルアプリケーションにはうまく適合しなかった。これらの非ブラウザクライアントは、標準的なリダイレクトメカニズムを持たず、複雑な暗号処理を安全に実行することが困難な場合が多かった
• サーバー側がすべてのAPIリクエストに対して一意の暗号署名を検証する必要があるため、計算コストが非常に高かった。これは、特にAPIトラフィックの多い大規模なサービスプロバイダーにとって、インフラストラクチャへの大きな負担となっていた^[15]。

OAuth 1.0のプロトコルは、各メッセージの完全性と送信元の証明を保証することに重点を置いていたが、その代償として、開発者体験、クライアントの多様性、サーバーのパフォーマンスが大きく損なわれた。OAuth 1.0は、これらの課題に対応するため、Internet Engineering Task Force (IETF) のOAuthワーキンググループは、プロトコルの完全な再設計に着手した。Eran Hammer-Lahavによれば、IETF OAuthワーキンググループは2010年終わりごろまでの範囲での締結を期待していた^[17]が、作業は大幅に遅延し、2012年8月にようやくRFCエディタへ送付された。その成果であるOAuth 2.0（RFC 6749）は、単なるバージョンアップではなく、委任認可に対するアプローチを根本から変えるパラダイムシフトであった^[18]。これにより、OAuth 2.0はOAuth 1.0と、後方互換性を持たなくなった。2025年現在、OAuth2.0はGoogle^[19]、Facebook^[20]、マイクロソフトなどで広く採用されている。

OAuth 2.0では、CSRF（クロスサイトリクエストフォージェリ）を防ぐために、「state パラメータ」の利用が推奨されている。これは、認可クライアントと認可サーバでの通信をする際、「state パラメータ」が一致するかどうかで、同じユーザーが同一のセッションで行われていることを確認するためである。

主な変更点

• RFC 6749は、プロトコルに関与するエンティティを4つのロール「リソースオーナー」「リソースサーバー」「クライアント」「認可サーバー」を定義した^[21]。
• 特に、認可サーバーとリソースサーバーの役割を分離したことは、アーキテクチャ上の大きな改善点である。これにより、認可とID管理を一元化し、複数のリソースサーバーで共有することが可能になった。
• OAuth 1.0の複雑な3-leggedフローを廃止。OAuth 2.0では、クライアントはリソースオーナーから「認可グラント (Authorization Grant)」と呼ばれる一時的な資格情報を取得し、それを認可サーバーで直接「アクセストークン」と交換する^[22]。これにより、プロセスの複雑さが大幅に軽減された。
• 「ベアラートークン (Bearer Token)」という概念を導入した^[23]。これは、特定の暗号署名を必要とせず、トークンを「保持（bear）している」だけでアクセスが許可される単純な文字列である。これにより、クライアント側の実装が劇的に簡素化された。
• OAuth 1.0では、リクエストトークンとアクセストークンの2種類を必要としたが、OAuth 2.0では、主要なフローにおいてアクセストークンという単一のトークンを使用する。フローが大幅に簡素化した^[24]。
• OAuth 2.0では、クライアントがAPIリクエストごとに暗号署名を生成するという要件を完全に撤廃した^[24]。これにより、実装の複雑さとサーバーの計算負荷が劇的に軽減された。
• OAuth 2.0は、トークンが通信経路上で傍受されるのを防ぐため、すべての通信においてTLS/SSL（HTTPS）の使用を必須としている^[24]。
• ネイティブのモバイルアプリケーションやデスクトップアプリケーション、シングルページアプリケーション（SPA）など、ブラウザベース以外のクライアントをより良くサポートするように明示的に設計された^[25]。
• OAuth 2.0は、有効期間の短いアクセストークンと、長期間有効な「リフレッシュトークン」を導入した^[26]。これはセキュリティ上の大きな進歩である。万が一、短命のアクセストークンが漏洩しても、その有効期限が短いため被害は限定的である。クライアントは、より安全に保管されたリフレッシュトークンを使用することで、ユーザーに再度のログインを要求することなく、新しいアクセストークンを安全に取得できる。

OpenID Connect（OIDC）

OAuth2.0が「認可（アクセス許可）」に特化しているのに対し、OIDCは「認可」に加えて「認証（本人確認）」の仕組みを提供するものである。OIDCは、OAuth 2.0のフローの上に「認証レイヤー」を追加したものであり、OAuthの連携フローの中で、アクセストークンに加えて「IDトークン」というユーザーが認証されたことを証明するトークンを発行することで、「認証（本人確認）」の仕組みを実現している。

→詳細は「OpenID」を参照

OAuth 2.1

OAuth 2.1は、OAuth 2.0の運用を通じて蓄積されたセキュリティ上のベストプラクティスや、PKCE（RFC 7636）のような重要な拡張仕様を単一の文書に統合し、フレームワークをよりシンプルで、デフォルトで安全なものにしたものである^[27]。

主な変更点

• すべてのクライアント（Public Client、Confidential Clientを問わず）が認可コードグラントを使用する際に、PKCE (ピクシー、英語：Proof Key for Code Exchange) の利用が必須となった^[28]。これは、「認可コード横取り攻撃」を緩和するための仕組みである。この攻撃は、特にモバイルアプリやSPAのようなPublic Clientにおいて、悪意のあるアプリケーションが正当なアプリケーションに送られる認可コードを傍受し、それを使ってアクセストークンを不正に取得するというものである。元々拡張仕様（RFC7636）だったPKCEを必須化することで、認可フローを開始したクライアントだけが認可コードをトークンに交換できることを保証し、この脅威を根本的に排除する。
• インプリシットグラント（response_type=token）の廃止^[28]。インプリシットグラントはアクセストークンをURLフラグメントで直接ブラウザに返すため、ブラウザの履歴、Webサーバーのログ、リファラヘッダなどを通じてトークンが漏洩するリスクが常に存在した。また、リフレッシュトークンを発行できないという問題もあった。現代のブラウザはCORS (Cross-Origin Resource Sharing) をサポートしているため、SPAであっても、より安全な「PKCE付き認可コードグラント」を使用することが可能であり、インプリシットグラントを維持する理由がなくなった^[28]。
• リソースオーナーパスワードクレデンシャルグラントの廃止^[28]
• 。このグラントは、第三者アプリケーションに認証情報を渡さないという、OAuthの最も基本的な原則に反する仕様である。このフローを許容することは、攻撃対象領域を不必要に拡大させ、OAuthを利用するメリットそのものを無効にしてしまう^[28]。
• リダイレクトURIのワイルドカードの使用の禁止。完全一致での比較が必須とり、攻撃者が巧妙に細工したリダイレクトURIを使ってユーザーを悪意のあるサイトに誘導する「オープンリダイレクタ脆弱性」を防ぐ^[28]。
• URLのクエリパラメータにベアラートークンを含めることが禁止される。トークンはAuthorization HTTPヘッダ、または限定的なケースでPOSTボディに含める必要がある。これにより、サーバーログやブラウザ履歴へのトークンの記録を防ぎ、漏洩リスクを低減する^[28]。
• リフレッシュトークンは、送信者制約付きであるか、ワンタイムユースであるという制約が追加される。これにより、リフレッシュトークンが漏洩した場合でも、攻撃者による不正利用が困難になる^[27]。