OAuth

security web beginner

IDやパスワードを相手に渡すことなく、特定のウェブサービス間で安全にアクセス権限を受け渡しする仕組み。

概要（サマリー）

OAuth（オーオース）とは、自分のIDやパスワードを相手に教えることなく、ウェブサービス同士で「アクセス権（鍵）」を安全に貸し借りするための仕組みである。

たとえば、新しいスマホゲームを始めるときに「Googleアカウントでログイン」や「LINEで連携」というボタンを見たことがあるだろう。
本来なら、そのゲームに自分のGoogleのIDとパスワードを入力しなければならないが、そんな大切な情報を怪しいかもしれないゲーム会社に渡すのは非常に危険である。
そこでOAuthの出番となる。OAuthを使えば、Googleの画面で「このゲームにあなたのプロフィール情報を渡してもいいですか？」と確認され、あなたが「許可」ボタンを押すと、Googleからゲームへ「プロフィール閲覧用の特別な合鍵（トークン）」が渡される。
ゲームはこの合鍵を使ってあなたの情報を取得するため、ゲーム側にパスワードを知られることなく、安全に連携ができる。

詳細解説

認可（Authorization）の仕組み

OAuthは主に「認可（権限の付与）」を行うためのプロトコル（手順のルール）である。よく似た言葉に「認証（ログイン確認）」があるが、OAuth単体は「誰であるか」を証明するものではなく、「特定の操作を許可する鍵を渡す」ためのものである。
現在広く使われているのは「OAuth 2.0」という仕様である。

OAuthの登場人物

OAuthのやり取りには、以下の4者が登場する。
1. リソースオーナー（ユーザー）: アカウントの持ち主（あなた）。
2. クライアント（アプリ）: 連携したいアプリやサービス（スマホゲームなど）。
3. 認可サーバー: ユーザーを確認して合鍵を発行するサーバー（GoogleやLINEなど）。
4. リソースサーバー: ユーザーのデータが保管されている場所。

処理の大まかな流れ（グラントフロー）

代表的な手順（認可コードフロー）は以下の通り。

アプリ（クライアント）が「Googleで連携」ボタンを用意し、ユーザーを認可サーバーにリダイレクト（案内）する。
ユーザーは認可サーバーの画面でログインし、アプリへの権限譲渡を「承認」する。
認可サーバーからアプリへ、「認可コード」という一時的な引き換え券が送られる。
アプリは、その認可コードを認可サーバーに送り、本物の「アクセストークン（合鍵）」を受け取る。
アプリはアクセストークンを使って、リソースサーバーからユーザーのデータを取得する。

このステップを踏むことで、アクセストークンをブラウザのURLなどに直接載せにくくし、サーバー側で安全にトークンを交換しやすくなる。

OAuthとAPIキー・二要素認証の違い

OAuthは、ユーザー本人のパスワードを渡さずに、別サービスへ限定的な権限を渡す仕組みである。
APIキーは主にアプリや開発者を識別するための固定的な鍵として使われることが多く、OAuthのアクセストークンとは用途や管理方法が異なる。
また、二要素認証はログイン時の本人確認を強化する仕組みであり、OAuthのようにサービス間でアクセス権限を委任する仕組みではない。

AIコーディングとの関係

AIに「外部サービス（GoogleやGitHubなど）と連携したログイン機能を作って」と指示すると、OAuthを使ったコードが生成される。
OAuthの処理はセキュリティ上、リダイレクトやトークンの検証など手順が多く複雑であるため、AIに実装方針を整理させつつ、実際には公式ライブラリや公式ドキュメントに沿って設定を確認することが重要である。

AIへ指示する際のポイント

「Node.js（Express）で、GitHubのOAuthを使ったログイン機能を実装したい。Passport.jsライブラリを使ったサンプルコードを書いて」
「Next.jsでNextAuth.js（Auth.js）を使って、GoogleとDiscordのOAuth認証を導入する方法を教えて」

よくある勘違い

OAuthとSAMLやOIDCの違いは？

OAuthは「認可（権限を渡す）」の仕組みであり、本来は「ログイン（認証）」のための仕組みではない。
しかし、「合鍵をくれる＝本人である」と見なしてログイン代わりに使うケースが増えたため、OAuth 2.0を拡張して「認証（本人確認）」も安全に行えるようにした OIDC（OpenID Connect） という規格が作られた。現在の「SNSログイン」の多くは、このOIDCが使われている。
一方、SAML（Security Assertion Markup Language）は、主に企業向けのシングルサインオン（SSO）で使われる古い歴史を持つ規格であり、XML形式で認証情報をやり取りする。

OAuthを使えばセキュリティは完璧？

OAuthは安全な設計だが、実装側の不備がセキュリティリスクを生む。代表的なリスクは「リダイレクトURIの検証不足」である。認可後にユーザーを戻すURLが正しく制限されていない場合、攻撃者が意図したURLに認可コードやトークンを転送させることができてしまう（オープンリダイレクト攻撃）。
加えて、アクセストークンを安全に保管しなければ、漏洩時に第三者がなりすましてユーザーのデータにアクセスできてしまう。OAuthを採用したからといってセキュリティが自動で確保されるわけではなく、HTTPSの徹底、リダイレクトURIの厳格なホワイトリスト管理、トークンの適切な保存場所の選定が不可欠である。

OAuth 1.0とOAuth 2.0は何が違う？

OAuth 1.0は署名（HMAC-SHA1等）を使ってリクエストの正当性を確認するため、改ざん検知や送信者確認の仕組みが強かったが、実装が複雑だった。
OAuth 2.0はHTTPSの利用を前提に仕様を整理し、実装しやすくなった一方で、リダイレクトURIやトークン保管などの設定ミスが大きなリスクになる。現在は2.0が標準となっており、多くのサービスはOAuth 2.0を使用している。

まとめ

OAuthは、パスワードを他社に教えずに、サービス間で安全にアクセス権限を受け渡す仕組み。
ユーザーが承認することで、発行された「アクセストークン（合鍵）」を使ってアプリがデータにアクセスする。
認証（本人確認）の目的には、OAuthを拡張した「OpenID Connect（OIDC）」が使われる。
実装が複雑なため、AIにライブラリ（Passport.jsやAuth.jsなど）を使った実装例を生成してもらうと効率的である。

情報ソース

より詳しくAIに聞いてみよう

OAuth 2.0における「アクセストークン」と「リフレッシュトークン」の役割の違いと、それぞれの有効期限の設計について教えてください。
OpenID Connect (OIDC) が OAuth 2.0 に追加した機能（IDトークンなど）について、初心者向けに解説してください。
独自にOAuthの認可サーバーを作る必要があるのはどのようなケースですか？それとも既存のSaaSを使うべきですか？
OAuthのリダイレクトURIのホワイトリスト（許可リスト）を正しく設定しないと、どのような攻撃を受ける可能性がありますか？
PKCE（Proof Key for Code Exchange）とは何ですか？SPAやスマホアプリでのOAuth認証においてなぜ必要なのかを教えてください。