【図解】OAuth2.0認証の仕組みを初心者向けにわかりやすく解説

「Googleでログイン」「LINEでログイン」――こうしたソーシャルログイン機能を支えているのがOAuth2.0という仕組みです。Webサービスの開発やシステム連携を検討する上で、この技術の理解は欠かせません。

本記事では、OAuth2.0の基本的な仕組みを図解でわかりやすく解説します。認証と認可の違いやアクセストークンの役割など、IT担当者が押さえておくべきポイントを丁寧に説明します。

OAuth2.0とは？基本の仕組みを理解する

「Googleアカウントでログイン」「LINEでログイン」といったボタンを見かけたことはありませんか？これらはOAuth2.0（オーオース2.0）という仕組みで実現されています。

OAuth2.0は、パスワードを直接渡すことなく、安全に権限を委譲する仕組みです。たとえば、新しいWebサービスに登録する際、Googleアカウントでログインすれば、そのサービスにGoogleのパスワードを教えることなく、必要な情報だけを共有できます。

OAuth2.0が解決する課題

OAuth2.0が登場する以前は、外部サービスと連携する際にIDとパスワードを直接渡す必要があり、以下のような問題がありました。

パスワード漏洩リスク：複数のサービスにパスワードを教えることで情報漏洩の可能性が高まる（パスワードレス認証も注目されています）
権限の制限不可：パスワードを渡すとすべての情報にアクセスできてしまう
アクセス権の取り消し困難：パスワード変更以外に方法がない（JWTとの連携についてはOAuth2.0とJWT認証の仕組みで詳しく解説しています）

OAuth2.0は2012年に標準化され、「必要な権限だけを、必要な期間だけ委譲する」という考え方でこれらの課題を解決しました。

「認証」と「認可」の違い

OAuth2.0を理解する上で重要なのが「認証」と「認可」の違いです。

認証（Authentication）は「あなたが誰であるか」を確認すること。会社の入口で社員証を見せて本人確認をするのが認証です。

認可（Authorization）は「何をすることが許可されているか」を決めること。社員証を見せた後、特定の部屋に入る権限があるかを判断するのが認可です。

OAuth2.0は本来「認可」のためのプロトコルですが、実際には認証の仕組みと組み合わせて「Googleでログイン」のような認証機能としても広く活用されています。

三者すべてにメリットがある仕組み

OAuth2.0が多くのサービスで採用される理由は、ユーザー・サービス提供者・プラットフォーム提供者の三者すべてにメリットがあるからです。

ユーザーは新しいサービスごとにパスワードを作る必要がなく、どのサービスに何の権限を与えているか管理しやすくなります。

サービス提供者（中小企業など）はユーザー登録のハードルが下がり、パスワード管理の責任から解放され、信頼性の高いプラットフォームの認証を活用できます。

プラットフォーム提供者は自社のユーザー基盤を拡大でき、エコシステムが広がり、プラットフォームの価値が高まります。

OAuth2.0の4つの登場人物

OAuth2.0の仕組みを理解するには、「誰が何の役割を担うのか」を把握することが重要です。ここでは「Googleアカウントを使って予約管理サービスにログインする」場面を例に説明します。

役割と具体例

リソースオーナー（Resource Owner）
保護されたデータの所有者であるあなた自身。自分の情報へのアクセスを許可するかどうかを決める人です。

クライアント（Client）
リソースオーナーの代わりにリソースにアクセスしたいアプリケーション。あなたが使おうとしている予約管理サービスがこれにあたります。

認可サーバー（Authorization Server）
リソースオーナーの認証と、アクセス許可の発行を担当。Googleの認証システムが「本当にあなたですか？」と確認し、「このサービスに情報を渡していいですか？」と許可を求めます。

リソースサーバー（Resource Server）
保護されたデータを保管し、提供するサーバー。正しい許可証（アクセストークン）を持っている人にだけデータを渡します。

実際のシステムでは、認可サーバーとリソースサーバーは同じ組織が運営していることが多く（例：どちらもGoogle）、まとめて扱われます。

身近な例で理解する

ホテルのルームキーを受け取る場面に例えると以下のようになります。

リソースオーナー：ホテルの部屋を予約した宿泊客（あなた）
クライアント：ホテル予約サイトやアプリ
認可サーバー：本人確認をしてルームキーを発行するフロント
リソースサーバー：ルームキーがないと入れない部屋

中小企業がOAuth2.0を導入する場合、多くは「クライアント」の立場になります。GoogleやLINEなどの大手プラットフォームが提供する認証機能を利用して、自社サービスにログイン機能を実装する形です。認可サーバーやリソースサーバーの構築は不要で、開発コストと期間を大幅に削減できます。

OAuth2.0の認証フロー：4つのステップ

最も一般的で安全な認可コードフロー（Authorization Code Flow）の流れを順を追って見ていきましょう。

ステップ1：認可リクエスト

ユーザーがクライアント（あなたの会社のサービス）で「Googleでログイン」ボタンをクリックすると、クライアントは以下の情報を含めてユーザーを認可サーバー（Googleの認証ページ）にリダイレクトします。

client_id：クライアントを識別するID
redirect_uri：認可後に戻ってくるURL
response_type：「code」（認可コードを要求）
scope：要求する権限の範囲（例：メールアドレス、プロフィール情報）
state：CSRF攻撃を防ぐためのランダムな値

ユーザーの画面には、Googleのログイン画面と「このサービスに以下の情報へのアクセスを許可しますか？」という確認画面が表示されます。

ステップ2：認可コードの発行

ユーザーが「許可する」をクリックすると、認可サーバーは以下の処理を行います。

ユーザーが本人であることを確認
ユーザーが要求された権限を許可したことを記録
認可コードを生成
ユーザーを元のサービス（redirect_uri）に戻す

この認可コードは、一度しか使えない、有効期限が非常に短い（通常10分程度）一時的なコードです。これ自体ではリソースにアクセスできません。

ステップ3：アクセストークンの取得

クライアントは、受け取った認可コードを使って、認可サーバーにアクセストークンを要求します。この通信は、ユーザーのブラウザを経由せず、サーバー間で直接行われます。これが重要なセキュリティポイントです。

リクエストには以下の情報が含まれます。

code：受け取った認可コード
client_id：クライアントID
client_secret：クライアントシークレット（事前に発行された秘密鍵）
redirect_uri：ステップ1と同じリダイレクトURI
grant_type：「authorization_code」

認可サーバーは、これらを検証した上で、アクセストークン（場合によってはリフレッシュトークンも）を発行します。

ステップ4：リソースへのアクセス

クライアントは、取得したアクセストークンを使って、リソースサーバー（Googleのユーザー情報API）にアクセスします。リソースサーバーは、このトークンが有効かどうかを確認し、有効であれば要求されたリソース（ユーザー情報）を返します。

これで、クライアントはユーザーのパスワードを知ることなく、必要な情報だけを安全に取得できました。

なぜ認可コードを使うのか？

認可コードを経由することで以下のメリットがあります。

アクセストークンがブラウザの履歴やログに残らない
クライアントシークレットで二重に認証できる
より強固なセキュリティが実現できる

主な認証フロータイプと選び方

OAuth2.0には、利用シーンに応じて複数のフロータイプ（グラントタイプ）が用意されています。

認可コードフロー（推奨）

最も安全で推奨されるフローです。サーバーサイドでトークンを管理し、クライアントシークレットを使った二重認証を行います。

適している場面
- Webアプリケーション（サーバーサイドがある）
- 顧客向けサービスでソーシャルログインを実装
- セキュリティを最優先したい場合

中小企業での活用例
- 予約管理システムにGoogleログインを導入
- 顧客管理システムにLINEログインを実装
- ECサイトで会員登録の手間を削減

クライアントクレデンシャルフロー

ユーザーの認証を必要とせず、サービス間の通信に使用します。クライアントIDとシークレットのみで認証します。

適している場面
- サーバー間のAPI連携
- バッチ処理やバックグラウンド処理
- 特定のユーザーに紐づかないデータアクセス

中小企業での活用例
- 自社の在庫管理システムとECサイトの在庫同期
- 基幹システムと外部APIの自動連携
- 定期的なデータ取得バッチ処理

インプリシットフロー（非推奨）

認可コードを経由せず、直接アクセストークンを取得します。アクセストークンがURLに含まれるため漏洩リスクが高く、現在は非推奨です。新規実装では使用しないでください。

選択の判断基準

ユースケース	推奨フロー
Webアプリケーション（サーバーあり）	認可コードフロー
SPA（React、Vueなど）	認可コードフロー + PKCE
モバイルアプリ	認可コードフロー + PKCE
サーバー間API連携	クライアントクレデンシャル

中小企業が自社サービスにソーシャルログインを導入する場合、認可コードフローを選んでおけば間違いありません。セキュリティが最も高く、主要プラットフォームが推奨し、実装事例が豊富だからです。

アクセストークンとリフレッシュトークン

アクセストークン：リソースへの許可証

アクセストークンは、リソースサーバーにアクセスするための「許可証」です。遊園地の入場チケットに似ており、このチケットを持っていれば園内のアトラクション（データ）を利用できます。

アクセストークンの特徴は以下の通りです。

有効期限が短い：通常1時間程度
特定の権限のみ：scopeで指定された範囲のみアクセス可能
使い捨て感覚：期限が切れたら新しいものに交換

このトークンを持っていれば、パスワードを入力することなく、許可された範囲のデータにアクセスできます。

リフレッシュトークン：継続利用のための仕組み

「アクセストークンの有効期限が1時間なら、1時間ごとにログインし直すの？」という疑問には、リフレッシュトークンが答えです。

リフレッシュトークンは、新しいアクセストークンを発行するための特別なトークンで、遊園地の年間パスポートのようなものです。

リフレッシュトークンの特徴は以下の通りです。

有効期限が長い：数日から数ヶ月、場合によっては無期限
アクセストークンの再発行専用：リソースへの直接アクセスには使えない
厳重に保管：サーバーサイドでのみ管理し、ブラウザには渡さない

仕組みの流れは以下のようになります。

最初の認証でアクセストークンとリフレッシュトークンを取得
アクセストークンが期限切れになる
リフレッシュトークンを使って新しいアクセストークンを取得
ユーザーは再ログイン不要でサービスを継続利用できる

なぜ有効期限を分けるのか

アクセストークンの有効期限を短くする理由は、セキュリティにあります。

もしアクセストークンが盗まれても、1時間後には使えなくなるため被害を限定できます。また、ユーザーが権限を取り消したい場合、短い有効期限であればすぐに反映されます。

アクセストークン：短い有効期限で頻繁に使う（セキュリティ重視）
リフレッシュトークン：長い有効期限で厳重に保管（利便性重視）

この二段構えの仕組みが、OAuth2.0の安全性を支えています。

セキュリティ対策と注意点

OAuth2.0は安全な仕組みですが、実装を誤るとセキュリティリスクが生じます。

トークン管理の基本

アクセストークンの管理
- HTTPS通信でのみ送信する
- ブラウザのローカルストレージには長期保存しない
- URLパラメータには含めない（ログに残るため）

リフレッシュトークンの管理
- サーバーサイドでのみ保管（データベースなど）
- 暗号化して保存する
- ブラウザには渡さない
- 不要になったら即座に無効化する

CSRF攻撃対策：stateパラメータ

CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐため、stateパラメータを必ず使用します。

stateパラメータは、認可リクエスト時にランダムな値を生成してセッションに保存し、認可サーバーから戻ってきた値と一致するか確認することで、リクエストが正規のものであることを検証します。

リダイレクトURIの厳格な設定

リダイレクトURIは、認可後にユーザーが戻ってくるURLです。これを適切に設定しないと、攻撃者が不正なURLに認可コードを送らせることができます。

認可サーバーに登録するリダイレクトURIは完全一致で指定
ワイルドカードは使用しない
HTTPSを必須とする

中小企業が押さえるべきポイント

自社でシステムを開発する場合、以下の点を開発パートナーに確認してください。

トークンはどこに保存されるのか？
有効期限はどのように設定されているか？
ユーザーが権限を取り消す方法はあるか？
セキュリティ監査は実施されているか？

これらの質問に明確に答えられる開発パートナーであれば、安心して任せられます。

中小企業でのOAuth2.0活用

ソーシャルログインの導入

自社サービスにGoogleやLINEのログイン機能を導入することで、ユーザー登録のハードルが下がり、利用者が増えやすくなります。パスワード管理の責任からも解放されます。

具体的な導入例
- 予約システムでGoogleログインを提供
- 顧客ポータルでLINEログインを実装
- ECサイトで複数のソーシャルログインに対応

社内システムとの連携

社内の複数システムを連携させる際にもOAuth2.0が活用できます。

具体的な活用例
- 勤怠管理システムと給与計算システムの連携
- 在庫管理システムとECサイトのリアルタイム同期
- 顧客管理システムとメール配信サービスの連携

ツール・ライブラリの選び方

OAuth2.0を実装する際は、実績のあるライブラリを使用することで、セキュリティリスクを低減できます。

主要なライブラリ
- Auth0：包括的な認証プラットフォーム
- Firebase Authentication：Googleが提供する認証サービス
- 各言語の公式ライブラリ：Google、LINEなどが提供

開発パートナーに依頼する場合は、「認可コードフローで実装してください」と伝えれば、適切に対応してもらえるでしょう。

まとめ：OAuth2.0で安全なシステム構築を

重要ポイントの振り返り

OAuth2.0は、パスワードを直接渡すことなく、安全に権限を委譲する仕組みです。以下のポイントを押さえておきましょう。

OAuth2.0は「認可」のためのプロトコルだが、認証機能としても広く活用されている
4つの登場人物（リソースオーナー、クライアント、認可サーバー、リソースサーバー）が連携して動作する
認可コードフローが最も安全で推奨される
アクセストークンとリフレッシュトークンの二段構えでセキュリティと利便性を両立

OAuth2.0導入のメリット

中小企業がOAuth2.0を導入することで、以下のメリットが得られます。

ユーザー登録のハードルが下がり、サービス利用者が増える
パスワード管理の責任とコストから解放される
GoogleやLINEなど信頼性の高いプラットフォームの認証を活用できる
低コストで高品質な認証機能を実装できる

次のステップ

OAuth2.0の導入を検討する際は、以下のステップで進めましょう。

自社サービスでどのような認証が必要か整理する
GoogleやLINEなど、連携したいプラットフォームを選定する
信頼できる開発パートナーに相談する
セキュリティ要件を確認しながら実装を進める

ITに詳しくない企業でも、適切なパートナーと協力することで、OAuth2.0を活用した安全で使いやすいシステムを構築できます。まずは小さく始めて、徐々に機能を拡張していくことをお勧めします。