初心者でもよくわかるOAuthの仕組みと安全な使い方

知らないWebサービスで「Googleでログイン」と表示されて、押して良いのか不安になったことはないでしょうか。
パスワードを教えているのか、どこまで情報が渡るのか、なんとなく怖くて閉じてしまった経験がある人も多いはずです。
この記事では、その裏側で動いている代表的な仕組み「OAuth」を、専門用語をかみ砕きながら整理します。

OAuthの基本と仕組みを初心者向けに整理する

まずは、OAuthという言葉が指しているものと、ざっくりとした全体像を整理します。
ここを押さえておくと、細かい用語や図を見ても「結局何のため？」と迷いにくくなります。

OAuthの結論と要点3つ

OAuthは、アプリが他社サービス上のデータへ「代理でアクセスする」ための仕組みです。
ユーザーのIDやパスワードを預からずに、代わりに「アクセスしてよい範囲」を示すアクセストークンを使います。(RFC エディタ)

要点を3つにまとめると次の通りです。

1つ目は、パスワードを共有せずに権限だけ渡す仕組みであることです。
ユーザーはパスワードを相手アプリに教えませんが、「このアプリには自分のカレンダーだけ見せてよい」といった許可だけを与えます。

2つ目は、許可できる範囲や期限を細かく制御できることです。
閲覧だけ許可して編集は不可にしたり、数十分だけ有効など、状況に合わせた柔軟なコントロールが一般的に行われます。(oauth.net)

3つ目は、業界で広く使われている標準的な枠組みであることです。
世界中の多くのサービスがOAuth 2.0の仕様に沿って実装しており、相互接続しやすい形で整備されています。(oauth.net)

現場では「OAuth＝安全に他社アプリへ権限を渡すための共通ルール」と理解されることが多いです。

OAuthの基本用語と前提知識

OAuthでは、主に次の4つの登場人物が出てきます。(RFC エディタ)

1つ目はリソースオーナー（ユーザー本人）です。
自分のカレンダーや写真などのデータの持ち主を指します。

2つ目はクライアント（アプリ）です。
ユーザーの代わりに、カレンダーや写真にアクセスしたい側のアプリケーションです。

3つ目は認可サーバーです。
「このユーザーは本当に本人か」「どの範囲を許可するか」を判断し、トークンを発行する役割を持ちます。

4つ目はリソースサーバーです。
カレンダーや写真など、実際のデータを持っているAPIのサーバーです。

もう1つ重要な用語がスコープ（scope）です。
スコープは「このアプリにはメールの件名だけ読ませる」「連絡先の読み取りだけ許可」など、アクセス範囲を細かく表現するためのラベルのようなものです。(oauth.net)

ここでよくある誤解が、OAuthは「ログインの仕組みそのもの」ではないという点です。
OAuth自体は「権限を渡す仕組み」であり、「誰であるか」を証明する認証は別の仕組み（OpenID Connectなど）で補うことが一般的です。(oauth.net)

OAuthの仕組みをざっくりイメージする

技術的な説明の前に、日常の例えでイメージしてみます。

会社の受付で、来客用に「ゲストカード」を発行する場面を考えてみてください。
ゲストは社員証（本当の身分証）は渡しませんが、「3階の会議室に17時まで入れる」など制限付きのカードを受け取ります。

このとき、社員証が「パスワード」、ゲストカードが「アクセストークン」に相当します。
受付の人はゲストカードの情報だけを確認して、「3階だけOKですね」と入館を許可します。

Webの世界でも同じイメージです。
ユーザーは本当のパスワードはサービス側に隠したまま、制限付きのゲストカード（トークン）だけをアプリに渡す、これがOAuthです。

会話で表すと次のようなやり取りになります。

ユーザー「この家計簿アプリ、銀行の明細を自動取得してくれるみたいだけど、口座のパスワードを預けるのは怖いな。」
友人　　「直接パスワードは渡さずに、銀行側が発行したトークンだけをアプリに渡す仕組みとして、OAuthが使われていることが多いよ。」

認可コードフローで見るOAuthの流れ

実際の処理の流れとして代表的なのが、認可コードフローと呼ばれるパターンです。(oauth.net)
初心者向けに、余計なパラメータを省いて大まかなステップだけ並べると次のようになります。

1つ目のステップは、クライアントがユーザーを認可サーバーへリダイレクトすることです。
画面上では「Googleでログイン」「●●アカウントに接続」といったボタンを押した瞬間に、裏側でこのリダイレクトが行われます。

2つ目のステップは、ユーザーが認可サーバーの画面でログインし、どの範囲を許可するか確認することです。
同意画面に「このアプリはあなたのカレンダー予定の閲覧を求めています」といった説明と、許可ボタンが表示されます。

3つ目のステップは、ユーザーが許可すると、認可サーバーが認可コードと呼ばれる一時的なコードをクライアントに返すことです。
この段階ではまだ本物のアクセストークンはアプリに渡されていません。

4つ目のステップは、クライアントがその認可コードを持って認可サーバーへ裏側からアクセスし、アクセストークンの発行を要求することです。
ここはサーバー同士の通信なので、ブラウザ画面からは見えません。

5つ目のステップは、認可サーバーが認可コードを確認し、妥当であればアクセストークン（必要に応じてリフレッシュトークンも）をクライアントに発行することです。

6つ目のステップは、クライアントがアクセストークンを使ってリソースサーバーのAPIを呼び出し、カレンダーや写真などのデータにアクセスすることです。

現場ではこのフローに、PKCEなどの追加の安全対策や、期限切れに備えるリフレッシュトークンの更新処理などが組み合わされることが多いです。

会話形式でまとめると次の通りです。

ユーザー「ボタンを押しただけなのに、どうして家計簿アプリから銀行明細が取れているの？」
開発担当「ボタンを押した後は、銀行の画面で許可をもらって、銀行から発行されたトークンを使って明細を読みに行っているんだ。」

OAuthを使う場面と考え方を具体的に理解する

次に、OAuthがどんなサービスで使われているのか、そして自分のプロジェクトで採用すべきかどうかを考える視点を整理します。
実務では「とりあえずOAuthを使っておけば安心」という考え方で設計してしまい、かえって複雑になってしまうケースもあります。

OAuthが使われている身近なサービス例

身近なところでは、次のようなサービスでOAuthが利用されています。

ソーシャルログインの代表例として、「Googleでログイン」「Appleでサインイン」といったボタンがあります。
これらの裏側では、GoogleやAppleがOAuth 2.0に基づいた仕組みでトークンを発行し、アプリ側に必要な情報だけを渡しています。(Google for Developers)

クラウドストレージと連携するアプリも典型例です。
例えば、オンライン画像編集ツールが「OneDriveの写真を読み込む」「クラウドストレージに保存する」といった機能を提供している場合、多くの場合はOAuthでアクセス権を受け取っています。

ビジネスの現場では、CRMやチャットツールが他のSaaSと連携する際にもOAuthがよく使われます。
「このアプリにはカレンダーへの読み取り権限だけ付与」「この社内ツールにはSlackの特定チャンネルへの投稿だけ許可」といった細かい権限の付け方が求められるためです。

OAuthを採用するかどうかの判断基準

OAuthを使うかどうかは、次のような観点で判断するのが一般的です。

1つ目の観点は、「他社（別ドメイン）のAPIにユーザーの代理でアクセスする必要があるか」です。
自分のサービス内だけですべて完結する場合は、通常のログインとセッション管理だけで十分なことも多いです。

2つ目の観点は、「パスワードを共有させたくない相手かどうか」です。
銀行や大規模なクラウドサービスなど、非常に重要なアカウント情報を扱う場合、パスワードを預からずにトークンベースで権限を分離することが強く求められます。

3つ目の観点は、「権限の範囲や期間を柔軟に変えたいかどうか」です。
業務アプリ同士の連携では、「閲覧だけ」「特定プロジェクトだけ」「試用期間中だけ」など細かい条件が発生しやすく、OAuthのスコープや有効期限の仕組みが役立ちます。

逆に、自社の単一Webサービスの中だけでログインと権限管理を行う場合は、まず通常のID・パスワード＋ロール管理で設計できないかを検討することが多いです。
現場では、最初からOAuthを前提にしてしまい、設計が過剰に複雑化して後から見直すケースも見られます。

セキュリティで押さえたいOAuthのポイント

OAuthは正しく使えば安全性向上に役立ちますが、設計や設定を間違えるとリスクも生じます。(IETF Datatracker)

重要なポイントの1つが、リダイレクトURIの厳格な指定です。
許可後に戻ってくるURLを広く許可し過ぎると、悪意のあるサイトにトークンが送られてしまう危険があります。

2つ目のポイントが、アクセストークンの有効期限を短くすることです。
長期間有効なトークンが漏洩すると被害が大きくなるため、一般的には短い有効期限のアクセストークンと、必要に応じて更新するリフレッシュトークンを組み合わせます。

3つ目は、PKCEなどの追加防御を積極的に採用することです。
特にモバイルアプリやブラウザベースのアプリでは、コード横取り攻撃への対策としてPKCEの利用が推奨されることが多くなっています。(oauth.net)

実務の現場では、これらのポイントを守らずに「ひとまず動く状態」を優先してしまい、後からセキュリティレビューで指摘されるケースが多く見られます。
一般的には、ベンダーやクラウド提供側のベストプラクティスに沿う形で実装することが、安全性と工数のバランスを取りやすいと考えられています。

初心者がつまずきやすい誤解と注意点

初心者が特につまずきやすい誤解や落とし穴をいくつか挙げます。

1つ目の誤解は、「OAuth＝ログインの仕組み」だと思ってしまうことです。
先ほど触れたように、OAuthは権限委譲の仕組みであり、「誰なのか」を証明するには別のレイヤーの仕組みが関わることが多いです。

2つ目の誤解は、アクセストークンをそのままブラウザのローカルストレージに長期間保存してしまうことです。
ブラウザ内での保存場所や有効期限の扱いを誤ると、盗まれたトークンで長期間アクセスされるリスクが高まります。

3つ目は、スコープを広く取り過ぎることです。
「とりあえず全部の権限を要求しておけば安心」と考えるのは逆効果で、ユーザーから見ると何をされるか分からず不安になり、離脱やクレームにつながることがあります。

実務では、次のような会話が起きることがあります。

開発者A「とりあえずメールも連絡先も全部スコープに入れておこうよ。」
開発者B「本当に必要なのはユーザーIDだけだから、そこまで広い権限は求めない方が良さそうだね。」

このように、「何が本当に必要な権限なのか」をチームで議論すること自体が、安全な設計に直結します。

OAuthの理解を深めるためのQ&Aとまとめ

最後に、初心者が疑問に感じやすいポイントをQ&A形式で整理し、記事全体の要点をまとめます。
ここまでの内容をざっと振り返りたいときの再確認用としても利用できます。

よくある質問

Q1．OAuthを使えば、パスワードの安全性は気にしなくてよくなりますか。
A1．パスワードを他社アプリと共有せずに済む点でリスクを減らせますが、パスワード自体の管理が不要になるわけではありません。
　　ユーザー自身のパスワード強度や多要素認証など、別のレイヤーの対策も引き続き重要です。

Q2．小さな社内システムでもOAuthを導入した方がよいでしょうか。
A2．社内だけで完結し、他社サービスと連携しない場合は、必ずしもOAuthが必要とは限りません。
　　別ドメインのAPIに代理アクセスする必要があるかどうかを基準に検討するのが一般的です。

Q3．「Googleでログイン」と書いてあれば、すべて同じ仕組みで動いていますか。
A3．多くの場合はOAuth 2.0とその周辺仕様に沿って実装されていますが、具体的なフローやスコープの設計はサービスごとに異なります。
　　同じ文言でも、実際に何を許可しているかは、同意画面の説明を確認する必要があります。

Q4．一度許可したアプリをあとから止めたい場合はどうすればよいですか。
A4．一般的には、権限を発行した側（例：Googleやクラウドサービス）のアカウント設定画面から、連携アプリを一覧し、権限を取り消すことができます。
　　アプリ側だけをアンインストールしても、トークン自体は残る場合があるため注意が必要です。

Q5．OAuth 2.0とOAuth 2.1の違いは初心者も気にすべきですか。
A5．OAuth 2.1は、後から追加された安全性向上のルールなどを整理した新しい仕様案という位置付けです。
　　初心者のうちは「安全なベストプラクティスをまとめた新しいガイドラインがある」と理解しておけば十分な場合が多いです。(IETF Datatracker)

OAuthの仕組みを初心者向けに整理したまとめ

・OAuthはパスワードを共有せずに権限だけを渡す仕組み
・ユーザー本人クライアント認可サーバーリソースサーバーが登場人物
・スコープでアプリに許可するアクセス範囲を細かく指定できる
・代表的な認可コードフローでは一時コード経由でトークンを取得する
・OAuthはログインそのものではなく権限委譲の仕組みである
・他社サービスのAPIにユーザーの代理でアクセスするときに向いている
・自社内だけで完結するシステムでは必須とは限らない
・リダイレクトURIの厳格な指定はセキュリティ上とても重要
・アクセストークンは有効期限を短くし更新用トークンと組み合わせる
・PKCEなど追加対策でコードの横取り攻撃を減らせる
・スコープを取り過ぎるとユーザーの不安や離脱につながりやすい
・アクセストークンの保存場所や扱い方を誤ると漏洩リスクが高まる
・連携を止めたいときは権限を発行したサービス側で解除する
・OAuth二〇点一は安全性のベストプラクティスを整理した新しい仕様案
・まずは身近なソーシャルログインの仕組みとしてイメージすると理解しやすい