「Googleアカウントでログイン」「外部アプリにGoogleカレンダーやGitHubリポジトリへのアクセスを許可する」など、現代のWebサービスで当たり前のように使われている仕組み。
その根幹を支えているセキュリティ標準規格が「OAuth 2.0（オーオース 2.0）」です。
OAuth 2.0は、第三者のアプリケーションに自分のユーザーIDやパスワードを教えることなく、安全にデータや機能へのアクセス権限を委譲（認可）するための業界標準フレームワークです。
本記事では、OAuth 2.0の基本概念から4つの構成要素（ロール）、標準的な認可フロー（認可コードグラント＋PKCE）、トークン管理、そしてOpenID Connect（OIDC）との違いまで図解を交えて徹底的に解説します。

パスワード直接共有に伴う深刻なセキュリティリスク

• 過剰な権限の付与：カレンダーの閲覧だけを許可したいのに、メール（Gmail）やクラウド（Drive）を含むアカウント全体の完全な制御権をアプリ側に渡してしまう。
• パスワードの漏洩リスク：外部アプリ側のサーバーに生パスワードが保存され、そこがクラッキングされるとメインアカウントごと乗っ取られる。
• 権限剥奪の困難さ：特定アプリのアクセスだけを取り消す手段がなく、連携解除のためにはGoogleアカウント自体のパスワードを変更するしかない。

認可コードグラントのステップ

1. 認可リクエスト：クライアントはブラウザを認可サーバーのログイン・同意画面へとリダイレクトさせます。
2. ユーザーの認証と同意：ユーザーは認可サーバー上でログインし、「アプリAにカレンダーの閲覧を許可しますか？」という同意画面で許可します。
3. 認可コードの発行：認可サーバーはブラウザを通じて、一時的な引換券である「認可コード（Authorization Code）」をクライアントのリダイレクトURIに返却します。
4. アクセストークンの交換：クライアントのバックエンドサーバーが、認可コードとクライアントシークレットを添えて認可サーバーに直接POSTリクエストを送信し、「アクセストークン」を受け取ります。
5. リソースアクセス：クライアントはアクセストークンをヘッダーに付与してリソースサーバーのAPIを呼び出します。

PKCEでは、リクエスト開始時に動的なランダム文字列（code_verifier）とそのハッシュ値（code_challenge）を生成します。認可コード交換時に元の値を照合することで、途中で認可コードを盗聴した悪意ある第三者がトークンを不正取得することを完全に防ぎます。

「ソーシャルログイン（Googleでログイン）」を行いたい場合は、OAuth 2.0そのものではなく、OAuth 2.0を拡張してユーザー属性情報（IDトークン）を取得できるようにしたOpenID Connectを使用するのが正しいアプローチとなります。

• state パラメータによるCSRF対策：認可リクエストにランダムなstate値を埋め込み、コールバック時に検証することで、悪意あるユーザーによるアカウント乗っ取り（ログインCSRF）を防止します。
• リダイレクトURIの厳格な完全一致検証：ワイルドカードや部分一致を許容せず、事前に登録された正規のリダイレクト先URLのみに認可コードを返却します。
• 常時HTTPS（TLS）通信の徹底：トークンや認可コードの送受信はすべて暗号化通信路で行います。
• PKCEの適用：SPAやモバイルアプリはもちろん、サーバーサイドアプリにおいてもPKCEの導入が推奨されています。

• パスワードを外部アプリに渡さない安全な権限委譲フレームワーク。
• 4つのロール（オーナー・クライアント・認可サーバー・リソースサーバー）の責務分担が明確。
• 認可コードグラント＋PKCEが最もセキュアで推奨される標準フロー。
• 認可にはOAuth 2.0、ユーザー認証（ログイン）にはOpenID Connectを適切に使い分ける。