OAuth 2.0とは何か？概要、仕組み、実装メリットや活用事例を初心者にもわかりやすく徹底解説

OAuth 2.0とは何か？概要、仕組み、実装メリットや活用事例を初心者にもわかりやすく徹底解説

OAuth 2.0は、サードパーティのアプリケーションがユーザー（リソースオーナー）に代わってリソース（データ）にアクセスするための認可フレームワークです。OAuth 2.0を使うことで、ユーザーは自分のパスワードをアプリに直接渡すことなく、安全にサービス間で連携できます。例えば、写真共有サービスのユーザーが、プリントサービスのアプリに対して写真データへのアクセスを許可するようなケースが挙げられます。

OAuth 2.0は2012年にIETFで標準化され（RFC6749）、従来のOAuth 1.0（RFC5849）に代わる仕組みとして策定されました。OAuth 1.0のような署名処理を廃止し、HTTPS上で動作する柔軟なモデルになったことで、多様なクライアント（Webアプリ、モバイルアプリ、サーバーアプリなど）で利用しやすくなっています。OAuth 2.0の利用メリットとしては、一度の認可で複数サービスにアクセスできるシングルサインオン（SSO）への応用や、細かいスコープ設定による最小権限原則の適用などが挙げられます。

OAuth 2.0の誕生背景：OAuth 1.0からの進化と規格化の経緯

OAuth 2.0は、従来のOAuth 1.0の課題を解決するために開発されました。OAuth 1.0では、クライアント側でリクエストに署名するなど実装が複雑でしたが、OAuth 2.0では署名の代わりにTLS/HTTPSによるセキュリティ確保を前提とし、よりシンプルなプロトコル設計になっています。これにより、クライアントの実装が容易になり、多様な環境で安全に認可機能を利用できるようになりました。

OAuth 2.0の主要コンポーネント：各ロールの役割と相互作用の仕組み

OAuth 2.0は以下の4つのロール（登場人物）で構成されます。リソースオーナーは保護されたリソースの所有者（通常はエンドユーザー）で、リソースサーバーはその保護されたデータをホストするサーバーです。クライアントはユーザーから認可を受けてリソースにアクセスしようとするアプリケーションで、ウェブアプリやモバイルアプリ、サーバーアプリなどが該当します。最後に、認可サーバーはリソースオーナーの認証とアクセス許可の取得後にアクセストークンを発行する役割を担います。認可サーバーとリソースサーバーは同じでも別でもよく、複数のリソースサーバーに対して一つの認可サーバーがトークンを発行することも可能です。

アクセストークンとリフレッシュトークン：概要と有効期限の仕組み

アクセストークンは、リソースオーナーの認可に基づいて認可サーバーがクライアントに発行する資格情報であり、クライアントはこれを用いてリソースサーバーの保護されたデータにアクセスします。アクセストークンは一般にランダムな文字列で、アクセス範囲（scope）や有効期間が含まれます（例：有効期限は1時間など）。一方で、リフレッシュトークンは、アクセストークンの有効期限切れ時に新しいアクセストークンを取得するために用いられる長期的なトークンで、クライアントに対してオプションで発行されます。

OAuth 2.0におけるスコープ（Scope）設定：アクセス範囲制御の方法

OAuth 2.0では、scopeパラメータによってクライアントが要求するアクセス権限の範囲を指定します。認可エンドポイントやトークンエンドポイントでクライアントは要求するスコープを明示でき、認可サーバーはアクセストークンに付与した実際のスコープをレスポンスで通知します。スコープは空白区切りの文字列リストで表現され、リソースオーナーやサービスのポリシーに応じて許可範囲が制限されることもあります。

活用事例：ソーシャルログインやAPI連携で広がる導入シナリオ

OAuth 2.0は現代のWebサービスやモバイルアプリで広く利用されています。代表例としては、SNSアカウントを用いたログイン連携（例：GoogleやFacebookのアカウントで他サービスにログイン）や、Webアプリ間でユーザーデータを共有するAPI連携があります。これらのシナリオでは、ユーザーは自分のパスワードを共有せずにOAuth 2.0のアクセストークンを介して安全に権限を委譲します。企業内でも、OAuth 2.0ベースのソリューションを採用することで、認証・認可基盤を統一して運用管理を効率化できます。

OAuth 2.0の認証・認可フロー：主要な登場人物と仕組み・基本的な流れをわかりやすく丁寧に解説

OAuth 2.0の認証・認可フローでは、クライアント、リソースオーナー、認可サーバー、リソースサーバーの間で上記の役割に応じたやり取りが行われます。RFC6749に示された図1の抽象フローでは、次のステップが定義されています。まず(A)でクライアントがリソースオーナー（通常はユーザー）に対してアクセス権を要求し、(B)でリソースオーナーから認可グラント（例：認可コード）を受け取ります。次に(C)でクライアントは認可サーバーに自身を認証した上で認可グラントを提示し、(D)で認可サーバーは正当性を確認した上でアクセストークンを発行します。最後に(E)(F)でクライアントはリソースサーバーにアクセストークンを提示して保護されたリソースにアクセスし、リソースサーバーはトークンを検証することでリクエストを承認します。

OAuth 2.0のフローにおいては、先述の4つのロールが協調して動作します。クライアントはユーザーに代わってアクセス要求を行い、認可サーバーがユーザー認証後にクライアントにアクセストークンを発行します。リソースサーバーはそのアクセストークンを検証することでリクエストを承認し、ユーザーの保護されたリソースを返却します。この4者の役割分担により、ユーザーが自分の認証情報を共有せずにアクセス権を委譲できる仕組みが成り立っています。

OAuth 2.0の主要な登場人物：リソースオーナー、クライアント、認可サーバー、リソースサーバーの役割

OAuth 2.0のフローにおいては、上述のリソースオーナー、クライアント、認可サーバー、リソースサーバーの4つが協調して動作します。クライアントはユーザーに代わってアクセス要求を行い、認可サーバーがユーザー認証後にアクセストークンを発行します。リソースサーバーはそのアクセストークンを検証することでアクセスを承認し、ユーザーの保護されたリソースを返却します。この4者の明確な役割分担により、ユーザーの認証情報を直接共有せずに安全なアクセス委譲が実現します。

認可コードフロー：認可コード取得からアクセストークン発行までの手順

認可コードフローは、最も一般的でセキュアなOAuth 2.0の認可グラント方式です。クライアントはリソースオーナーを認可サーバーへリダイレクトし、ユーザーが認証・承認を行うと一時的な認可コードを受け取ります。その後、クライアントは認可サーバーに認可コードと自身の認証情報を送信し、アクセストークンを取得します。この方式では、ユーザーのクレデンシャルがクライアントに直接渡らないため、セキュリティ面でのメリットがあります。

インプリシットフロー：シングルページアプリ向けの簡易な認可プロセス

インプリシットフローは、ブラウザのみで動作するシングルページアプリケーション(SPA)向けに設計された方式です。このフローでは、認可コードを経由せずにアクセストークンが直接ブラウザに返されます。そのためクライアント認証が不要となりますが、トークンがURLフラグメントで返されるためセキュリティリスクが高くなります。最近ではセキュリティ強化のため、Authorization Code Flow + PKCEの利用が推奨されており、Implicit Grantは廃止方向です。

クライアントクレデンシャルフロー：バックエンドサービス間で用いられる認可方式

クライアントクレデンシャルフローは、クライアント自身がリソースに対して権限を持つ場合や、あらかじめクライアントと認可サーバー間で連携が設定されている場合に使われます。この方式ではユーザーの関与がなく、クライアントは自身のIDとシークレットで認可サーバーに認証し、アクセストークンを直接取得します。マシン間通信（サーバ間連携）など、ユーザー代理でないアクセスシナリオに適しています。

リソースオーナー・パスワードフロー：ユーザー認証情報を直接用いる旧方式とその課題

リソースオーナーパスワードフローは、ユーザーがクライアントに直接ユーザー名とパスワードを提供する方式です。従来はOAuth 2.0で定義されていましたが、クライアント側がユーザーの認証情報を扱うためセキュリティ上問題があることから、OAuth 2.1では廃止予定となっています。現在では、この方式よりも認可コードフロー（PKCE利用）や他の認証連携手段が推奨されます。

なぜOAuth 2.0が必要なのか？セキュリティと利便性を両立する理由、クラウド/モバイル時代の利用シーン

OAuth 2.0の必要性は、従来の認証・認可方式の問題点から生じています。従来はパスワードなどの認証情報をサービスごとに直接アプリへ登録する必要があり、パスワード漏洩リスクや管理コストが増大していました。OAuth 2.0を利用することで、ユーザーはサービス間で同一の認証情報を共有せずに、必要最小限の許可だけをトークンで委譲することが可能になります。この仕組みにより、セキュリティ強化と利便性向上を両立できます。

OAuth 2.0が解決する課題：従来の認証方式が抱える問題点

OAuth 2.0は、複数のWebサービスやアプリを連携させる際のセキュリティ課題を解決します。例えば、外部アプリがSNSのAPIにアクセスする場合、本来はユーザーの認証情報（ID/PW）を渡さずに済む点が大きなメリットです。トークンを介した認可では、サービス側で細かくアクセス権限（scope）を設定でき、不正アクセスや権限の乱用を防ぐことができます。また、パスワード不要にすることで、ユーザーは複数のサービスで同じパスワードを使い回す必要がなくなり、安全性が高まります。

トークン認可の利点：パスワード非共有によるセキュリティ強化

トークンベース認可の利点として、パスワード非共有によるセキュリティ向上が挙げられます。OAuth 2.0では、クライアントはユーザーのパスワードではなく、一時的に有効なアクセストークンを用います。このトークンは期限やアクセス範囲が明示されており、万が一漏洩しても被害を限定できます。また、リフレッシュトークンを使えば長期セッションも安全に維持でき、セッション管理コストの軽減にも寄与します。これらにより、OAuth 2.0は安全性と利便性の両立を実現します。

ユーザビリティ向上事例：SNSログインやシングルサインオンで得られる利便性

OAuth 2.0を活用した具体例として、SNSアカウントを使ったログイン（例：TwitterやGoogleアカウントで別のサービスにログイン）があります。この場合、ユーザーはOAuth認可画面で許可するだけで新しいサービスのアカウントが作成でき、ユーザビリティが大幅に向上します。また、OAuth 2.0はシングルサインオン（SSO）でも利用されており、一度のログインで複数サービス間の移動が可能になります。OpenID Connectでは、ユーザー認証を一元管理しながら複数サービスでのSSOを実現できます。

クラウド・モバイル時代の課題：OAuth 2.0が提供する柔軟な認可モデル

クラウド環境やモバイルアプリでは、柔軟な認可モデルが求められます。OAuth 2.0では、ユーザーがスマートフォンアプリ上で動くクライアントであっても、PKCEやモバイル向けフローを使うことで安全に認可を実現できます。組織内では、クラウドサービスやマイクロサービス間の通信にOAuth 2.0を適用して統合認可基盤とすることで、セキュリティとスケーラビリティを両立できます。また、APIアクセスが増える現代において、OAuth 2.0のトークン認可はクラウドネイティブなサービス連携に最適です。

導入効果とメリット：運用負荷低減と安全性向上の両立

実際にOAuth 2.0を導入すると、パスワード管理の手間削減やパスワード漏洩リスクの低減などの効果が期待できます。企業システムにおいても、統一IDプロバイダを通じて複数アプリの認可を一元管理できるため、運用効率が向上します。さらに、OAuth 2.0ではトークンのスコープ制御により最小権限原則を適用しやすいため、内部統制やセキュリティ監査上の要件にも対応しやすくなります。

認証と認可の違いとは？OAuth 2.0でそれぞれの役割を整理し、セキュリティ面での留意点を解説

認証とは、ユーザーが主張する本人性を検証するプロセス（Authentication）であり、例えばID/パスワードや多要素認証によって本人確認を行います。一方、認可とは、ユーザーに対してシステムリソースへのアクセスを許可するプロセス（Authorization）です。つまり認証は「あなたは誰か？」を確かめるのに対し、認可は「あなたには何が許可されているか？」を判断します。

認証 (Authentication) の定義：本人確認プロセスの概要と例

認証はユーザー自身を確認する手続きであり、ログインフォームでパスワードを入力することなどがこれにあたります。OAuth 2.0では認証自体は原則扱わないため、ID/パスワードの検証は通常認可サーバー（または連携するIDプロバイダー）が担当します。認証が成功した上で、ユーザーがアプリに権限を与えることによって初めて認可（Access Token発行）が進みます。

認可 (Authorization) の定義：アクセス許可プロセスの概要と例

認可はリソースオーナーがシステムへのアクセス許可を与える行為です。OAuth 2.0における認可では、ユーザーが認可サーバー上でクライアントアプリに対するアクセス権限（スコープ）を明示的に承認します。その結果、認可サーバーはクライアントにアクセストークンを発行し、クライアントはリソースサーバーへそのトークンを提示してアクセスします。

OAuth 2.0における認証・認可の関係：役割分担と基本概念

OAuth 2.0自体は認可フレームワークであるため、ユーザー認証（ログイン）機能は仕様上明示されていません。認可サーバーは多くの場合ユーザー認証機能を持ちますが、OAuth 2.0標準ではなくOpenID Connectなど外部規格によって補います。このようにOAuth 2.0では「誰か」を確認する認証よりも、「何にアクセス可能か」を決める認可に主眼が置かれています。

認証と認可の典型的なフロー比較：ログインとAPIアクセス制御の違い

典型的な例として、ユーザーがWebサービスAからサービスBにアクセスする場合を考えます。ログイン時にID/PWを認証するのが「認証」です。一度ログインすれば、その認証情報に基づいてサービスAでの処理は実行できます。一方、サービスAがサービスBのデータにアクセスする際には、OAuth 2.0の認可フローによってアクセストークンを取得し、そのトークンでサービスBを利用します。ここで重要なのは、サービスA（クライアント）がOAuth認可によりアクセス許可を得た点であり、ユーザー自身のパスワードはサービスAに渡っていないことです。

OpenID Connectとの連携：OAuth 2.0に不足する認証機能の補完

前述のように、OAuth 2.0ではユーザー認証を直接扱いません。そのため、OAuth認可とユーザー認証を両立させる仕組みとしてOpenID Connect（OIDC）が提案されています。OIDCではOAuth 2.0のフロー上にIDトークンという概念を追加し、ユーザーの認証情報をトークンでクライアントに提供します。これにより、OAuth 2.0ベースのシステムでも安全にシングルサインオンが実現可能となります。

アクセストークンと認可コード：それぞれの役割と発行プロセスを詳しく解説し、その違いとセキュリティ上の留意点も整理

OAuth 2.0におけるアクセストークンは、認可サーバーからクライアントに発行される文字列で、保護されたリソースへのアクセス権を示すものです。クライアントはこのトークンをHTTPヘッダなどでリソースサーバーに送信し、リソースサーバーはトークンを検証することでアクセス制御を行います。アクセストークンには有効期間やスコープ（アクセス範囲）が設定され、通常は発行から一定時間（例：1時間）で期限切れになります。

アクセストークンの概要：保護されたリソースアクセスに使われる資格情報

アクセストークンは通常ランダムな文字列で、クライアントがリソースオーナーに代わってリソースサーバーにアクセスするための「鍵」に相当します。このトークンには、どのリソースにどの範囲でアクセスできるかが組み込まれており、トークン自体が有効である限りアクセスが可能です。トークンは有効期限が切れると無効となるため、長期間のアクセスにはリフレッシュトークンや再認可が必要です。

認可コードの概要：アクセストークン取得のための一時的な認可グラント

認可コードは、一時的なコード（認可グラント）で、クライアントがアクセストークンを取得するために用いられます。クライアントは直接ユーザーの認証情報を扱わず、まずユーザーエージェントを介して認可サーバーにリダイレクトし、そこでユーザー認証と承認を行います。認可が与えられると、認可サーバーからクライアントに認可コードが返されます。クライアントはこのコードと自身の認証情報を使って認可サーバーからアクセストークンを発行してもらいます。認可コードの導入により、ユーザーのパスワードはクライアントに渡らず、セキュリティが向上します。

トークン発行の流れ：認可コードからアクセストークン取得までのプロセス

認可コードフローでは、まずクライアントが認可サーバーに認可要求を行い（リソースオーナーのブラウザリダイレクト）認可コードを受け取ります。その後、クライアントは認可コードを認可サーバーのトークンエンドポイントに送信し、アクセストークン（とリフレッシュトークン）を取得します。一方、Implicit Flowでは認可要求のレスポンスとして直接アクセストークンが返ります。いずれのフローでも、最終的にクライアントは得られたアクセストークンをリソースサーバーに提示してリソースへアクセスします。

リフレッシュトークンの活用：アクセストークン更新の仕組みと注意点

リフレッシュトークンは、アクセストークンの有効期限切れ時に新しいアクセストークンを発行してもらうためのトークンです。クライアントはアクセストークンが無効になると、認可サーバーにリフレッシュトークンを送信して新しいアクセストークンを取得します。リフレッシュトークンには通常期限が長く設定され、アクセストークンの更新回数や期間を制限できます。適切に扱えば、ユーザーは再ログインなしに連続してサービスを利用できるため、UX向上に役立ちます。

アクセストークン vs 認可コード：それぞれの用途とセキュリティ上の違い

アクセストークンと認可コードは役割が異なります。アクセストークンはリソースサーバーへのアクセスに直接使う資格情報であるのに対し、認可コードはあくまでアクセストークンを取得するためのブローカーのようなものです。認可コードは短期間で使い捨てられ、アクセストークンは期限内に複数回利用できます。また認可コードフローでは、クライアント認証（クライアントID/シークレットやPKCE）と組み合わせることで、認可コード単体が流出してもアクセストークン取得時に弾かれる仕組みが組み込まれています。

OpenID Connectとは何か？OAuth 2.0との違いと連携によるシングルサインオン実現をわかりやすく解説

OpenID Connect (OIDC)は、OAuth 2.0の上に構築されたユーザー認証用プロトコルです。OAuth 2.0自体は認可フレームワークであり、ユーザー認証（ログイン）機能は標準で規定されていません。OIDCではOAuthの認可フローを利用しつつ、IDトークンというJWT形式の認証情報を追加します。クライアントはこのIDトークンを受け取ることで、ユーザーの認証情報を検証しログイン状態を得ることができます。OIDCによって、OAuth 2.0ベースの仕組みでも安全にシングルサインオンが実現可能となります。

OpenID Connectの概要：OAuth 2.0を拡張した認証プロトコル

OpenID Connectでは、OAuth 2.0の認可フローに認証機能を追加しています。このプロトコルでは、認可コードやインプリシットフローの応答としてIDトークン（JSON Web Token形式）を返します。IDトークンには、ユーザーの識別子や認証時刻などが含まれ、クライアントは署名を検証することでユーザー認証情報を確認できます。これにより、OAuth 2.0のスコープ（例：openidスコープ）を要求することで認証まで含めた連携が行えます。

IDトークンの仕組み：ユーザー認証情報を含むJWT形式のトークン

IDトークンはJWT(JSON Web Token)形式で発行され、ユーザー識別情報などを含みます。クライアントは受け取ったIDトークンを検証（署名検証、発行者確認、対象ユーザーの一致など）することでユーザーが認証されたことを保証します。このIDトークンの取得により、クライアントはユーザーのプロフィール情報を別途取得せずにログイン状態を維持できます。

OAuth 2.0との違い：認証機能の追加と目的の違い

OAuth 2.0は認可を目的とした仕様であり、ユーザーのID確認（認証）は扱いません。これに対しOIDCは、OAuth 2.0の認可機能を活かしつつユーザー認証機能を提供する点で異なります。つまり、OAuth 2.0で「何ができるか」を規定するのに対し、OIDCでは「誰がアクセスしているか」を判断する仕組みが加わります。OAuth 2.0でユーザー認証も行いたい場合はOIDCの利用が必須です。

シングルサインオン (SSO) 実現：OpenID Connectによる統一ログインの仕組み

OpenID Connectを用いると、一度の認証で複数サービスに対するシングルサインオン（SSO）が可能になります。これにより、複数のWebアプリケーション間で同一のID基盤を共有でき、ユーザー体験が向上します。例えば、企業内においては一つのIDプロバイダー（IdP）でユーザー管理を行い、各種クラウドサービスへのSSO連携をOpenID Connectで実現できます。なおOIDCでは認証だけでなく認可も組み合わせて扱えるため、IDフェデレーション用途にも適しています。

OpenID Connect導入のメリット：標準化による実装の容易さと利便性

OpenID Connectを導入すると、認証と認可の機能が標準化されるため実装コストが削減できます。IDトークンにユーザー情報が含まれるため、認証連携後に別途ユーザーデータ取得APIを呼ばずに済み、開発効率が向上します。また、複数の認証プロバイダー（Google、Facebook、社内IdPなど）とも一貫したフローで連携可能で、拡張性と互換性が高まります。標準化されたOAuth/OIDCライブラリも多く提供されているため、セキュリティ実装も容易です。

OAuth 2.0の最新仕様・動向：OAuth 2.1の要点・新機能とセキュリティ強化策を詳しく紹介

OAuth 2.0は策定以来多くの改善が行われており、最新では「OAuth 2.1」仕様の策定が進められています。OAuth 2.1では、これまで別文書でまとめられていたベストプラクティスやセキュリティ要件を一つに統合します。例えば、認可コードフローではPKCEの利用を必須化し（Client Secretがないパブリッククライアントでも安全に使えるようにする）、インプリシットフローやResource Owner Password Credentials Grantを廃止するなど、現代のセキュリティ要件に沿った変更が加えられています。

OAuth 2.1ドラフトの概要：標準化の取り組みと整理の目的

OAuth 2.1ドラフトでは、既存のOAuth 2.0関連仕様を整理して一つの仕様書とする取り組みが行われています。2019年以降のIETF OAuthワーキンググループの議論では、複数の文書を参照せずに済むよう、現行RFC6749をベースに必要な改善点を加えた内容へまとめ直す方針が示されています。このドラフトは既にWG Draftとして公開されており、今後正式化に向けた議論が継続しています。

OAuth 2.1の主な変更点：PKCE必須化・Implicit Grant廃止など

ドラフト文書のDifferencesセクションによれば、OAuth 2.1では以下のような主な変更が計画されています。まず、認可コードグラントでは必ずPKCEを使用すること、リダイレクトURIの照合は完全一致とすることが定められています。また、Implicit GrantとResource Owner Password Credentials Grantは廃止されます。さらに、URLクエリでのトークン送信が禁止され、リフレッシュトークンも使い捨てまたは制限的になるなど、セキュリティ上の強化策が盛り込まれています。

セキュリティ強化の方向性：厳密なRedirectURI照合とHTTPS必須化

OAuth 2.1の狙いは、より安全かつ明確な仕様とすることです。例えば、PKCE必須化によりクライアントシークレットを持たないモバイルアプリでも強力に保護でき、Implicitフロー廃止でトークン露出リスクを排除します。加えて、リダイレクトURIはクライアント登録時に完全一致で指定することでオープンリダイレクトを防ぎ、常時HTTPS接続を前提とすることで通信盗聴のリスクを低減します。OAuth BCP（Security Best Current Practice）も参照しつつ、最新のセキュリティガイドラインが取り入れられています。

新たな拡張仕様：Device Flowや分散型ID連携の概要

最近ではOAuth 2.0の拡張仕様として「デバイス認可フロー（Device Flow）」やデバイス証明書の連携、分散型IDとの連携など、新しい動きも出てきています。Device Flowは、リソースの入力手段が限定されるデバイス（スマートTVやIoTデバイス）向けに、ユーザーが別端末で認可コードを入力することで認証・認可を行うフローです。これらの新技術は、OAuth 2.0の範囲外で策定された拡張規格ではありますが、OAuth 2.1の進行とも関連するトピックです。

OAuth 2.0関連技術の動向：OpenID Connectやゼロトラストとの連携

OAuth 2.1以外にも関連技術の動向があります。特にOpenID Connectはユーザー認証を標準化するプロトコルとして広まりつつありますし、最近注目のゼロトラストネットワークやマイクロサービス認証においても、OAuth 2.0ベースのフレームワークが採用されるケースが増えています。WebAuthn/FIDO2のようなパスワードレス認証技術とも組み合わせることで、次世代のアイデンティティ基盤が構築されつつあります。

OAuth/OIDCへの攻撃と対策：代表的な攻撃手法とその防御策、実装上の留意点をわかりやすく解説

OAuth 2.0やOpenID Connectは安全性を高める機能がある一方、実装次第で攻撃を受けるリスクもあります。例えば、認可フローの脆弱な実装によりアクセストークンが漏洩したり、悪意あるリダイレクトURIを介して認可コードが盗まれる事例が報告されています。ここでは、特に注意すべき攻撃例とその対策を紹介します。

リダイレクトURI検証不備：正規表現による脆弱性と攻撃事例

たとえば、リダイレクトURIの検証が不十分だと、悪意あるドメインに認可コードが流出する恐れがあります。正規表現で https://.example.com/ のようなパターンを許容すると、https://attacker.com/.example.com/ のように攻撃者ドメインを含むURIがマッチしてしまうケースがあります。これにより、認可サーバーが攻撃者の用意したURLにユーザーをリダイレクトし、認可コードを奪われてしまう可能性があります。

CSRF対策とstateパラメーター：認可リクエストの不正実行を防ぐ仕組み

クロスサイトリクエストフォージェリ(CSRF)攻撃に対しては、stateパラメータの利用が推奨されます。stateにはランダムな値を設定し、認可リクエストとコールバック時で一致するか確認することで、不正なリクエストを検知できます。RFCでは、stateパラメータは用いることが推奨されています。実際、認可リクエスト時にこのパラメータを省略しないようにし、リダイレクト後に照合する実装が必須です。

認可コードインジェクション：パラメータ汚染攻撃とその防御策

いわゆる「Parameter Pollution」攻撃では、複数の同名クエリパラメータを利用して認可コードをすり替える手法が報告されています。例えば、正しく照合されたリダイレクトURIの末尾に code パラメータを含めてリクエストすると、アプリケーションによっては攻撃者が用意した認可コードを利用してしまう可能性があります。これに対しては、パラメータのエンコード・検証処理を厳格に行い、サーバー側ではクエリパラメータを複数受け入れない実装とすることで対策できます。

アクセストークン窃取対策：HTTPS/TLSの強制とSecure/HttpOnly設定

アクセストークンの窃取対策としては、HTTPS/TLSの強制や、ブラウザで扱う場合にはSecure/HttpOnly属性付きCookieでトークンを保管するのが有効です。アクセストークンは有効期限が短いため、もし漏洩しても被害を抑えやすくなっています。また、必要最小限のスコープのみをリクエストして最小権限とし、不要なアクセスを制限することも重要です。サーバー側では盗難トークンのブラックリスト化やセッション終了機能も実装しておくと安全性が高まります。

PKCEとクライアント認証：コードフロー安全化のための手法

認可コードフローではPKCEの利用が特に推奨されます。PKCE (Proof Key for Code Exchange)はワンタイムパスワードのように、認可コードが盗まれてもアクセストークン取得時に合致しないことを利用して不正取得を防ぎます。RFCではクライアントシークレットが持てないアプリでも安全に利用できるよう、PKCEの使用が必須とされています。さらに、認可サーバーでクライアント認証を厳格に行えば、第三者によるクライアントIDの偽装やトークンリクエスト時の不正も防げます。