OAuth 2.0の認証と認可とは？初心者向けにわかりやすく解説

はじめに

アジアクエスト デジタルインテグレーション部の井上祐斗と申します。

現代のウェブサービスやアプリケーションでは、「○○でログイン」という機能をよく見かけます。
これらは他のサービスと連携し、ユーザーが簡単にログインできるようにする技術です。
その背後にあるのが「OAuth 2.0」という仕組みです。

たとえば、Googleアカウントを使って別のウェブサイトにログインする機能や、アプリがユーザーの許可を得てソーシャルメディアに投稿する機能など、OAuth 2.0はこうした連携を安全に実現するための標準プロトコルです。

まず、OAuth 2.0を理解するために重要なのは、「認証」と「認可」の違いです。

• 認証:
  ユーザーが誰であるかを確認するプロセスです。
  たとえば、ユーザーが自分のIDとパスワードを使ってウェブサイトにログインするのが認証です。

• 認可:
  認証されたユーザーが、どのリソースやデータにアクセスできるかを決めるプロセスです。
  たとえば、あなたがウェブアプリに自分のGoogleカレンダーにアクセスする許可を与えることが認可です。

OAuth 2.0は、ユーザーが認証された後、特定のリソースやデータへのアクセスを「認可」する仕組みです。
これにより、ユーザーは自分のアカウント情報を第三者に公開することなく、他のサービスに権限を与えることができます。

この記事では、初心者の方に向けたOAuth 2.0の基本や使用事例について紹介していきます。

OAuth2.0の基本概念

OAuth 2.0を理解する上で、まずは登場する基本的な役割や概念を把握することが重要です。
OAuth 2.0は、さまざまなシステムやアプリケーションが安全にリソースへのアクセスを制御できる仕組みを提供しています。
ここでは、主要な役割について説明します。

クライアント（Client）

クライアントは、ユーザーの代わりにリソースにアクセスしようとするアプリケーションやサービスのことを指します。
たとえば、あるウェブアプリがユーザーのGoogleカレンダーにアクセスして、イベントを表示する場合、そのウェブアプリがクライアントです。

リソースオーナー（Resource Owner）

リソースオーナーは、アクセスするリソース（データ）の所有者、つまりユーザー自身です。
ユーザーは、自分のデータへのアクセスをクライアントに許可します。

リソースサーバー（Resource Server）

リソースサーバーは、実際にリソース（データ）を保管し、それを提供するサーバーのことです。
たとえば、GoogleカレンダーのデータはGoogleのサーバーに保存されています。このGoogleのサーバーがリソースサーバーに該当します。

認可サーバー（Authorization Server）

認可サーバーは、クライアントがリソースにアクセスするための許可を発行する役割を持っています。
ユーザーがリソースへのアクセスを許可すると、認可サーバーはクライアントに「アクセストークン」という形で許可を与えます。このトークンを使って、クライアントはリソースサーバーにアクセスできます。

権限スコープ（Scope）とは？

OAuth 2.0では、クライアントがリソースオーナーのデータにどの範囲までアクセスできるかを指定する「スコープ」という概念があります。
たとえば、クライアントがユーザーの連絡先だけにアクセスできるようにする、または、カレンダーの読み取りのみを許可する、といった細かな制御が可能です。

OAuth2.0のフローの種類

OAuth 2.0には、さまざまなシチュエーションに対応するための複数の認可フローがあります。
これらのフローは、クライアントがどのようにリソースオーナーからアクセス権を取得するかを定義しています。
以下では、代表的な4つのフローを紹介します。

認可コードフロー（Authorization Code Flow）

このフローは、セキュリティ面で非常に安全なフローの一つです。
特に、サーバー側でアクセストークンを安全に管理できるウェブアプリケーションに適しています。
手順は以下の通りです。

1. クライアントがリソースオーナーに認証と認可を要求。
2. 認可サーバーがクライアントに認可コードを発行。
3. クライアントはその認可コードを認可サーバーに送信し、アクセストークンを取得。

このフローでは、ユーザーが一度認可サーバーにリダイレクトされて認証を行い、その後クライアントに戻ってきます。
これにより、クライアントはユーザーのパスワードを直接扱うことなく、安全に認可を受け取ることができます。
また、アクセストークンが直接ブラウザを介して渡されないため、セキュリティ上のリスクが少ないです。

インプリシットフロー（Implicit Flow）

インプリシットフローは、シングルページアプリケーション（SPA）やクライアントサイドのアプリケーションで使用されます。
SPAとは、ページをリロードせずに動的にコンテンツを更新できるアプリケーションのことです。

このフローでは、クライアントがリソースオーナーから直接アクセストークンを取得し、サーバーを経由しないため、手続きが簡単です。
しかし、アクセストークンがブラウザを介して直接クライアントに渡されるため、セキュリティリスクが高くなる点に注意が必要です。

パスワードクレデンシャルフロー（Password Credentials Flow）

このフローは、リソースオーナーがクライアントに対してユーザー名とパスワードを直接提供する場合に使われます。

信頼されたクライアント（自社サービスのモバイルアプリなど）で使われることが多いですが、リソースオーナーのパスワードをクライアントが知ることになるため、推奨されるケースは少ないです。

クライアントクレデンシャルフロー（Client Credentials Flow）

このフローは、リソースオーナーが存在しない状況で使用されます。

クライアント自身が認可サーバーから直接トークンを取得し、リソースにアクセスする場合に適しています。
一般的には、サーバー間の通信やバックエンドのAPIへのアクセスに使用されます。

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

OAuth 2.0において、認可サーバーから発行されるトークンは、クライアントがリソースにアクセスするための鍵となります。
このトークンには、アクセストークンとリフレッシュトークンの2種類が存在します。
それぞれの役割と使い方を詳しく見ていきましょう。

アクセストークン（Access Token）

アクセストークンは、クライアントがリソースサーバーに対してリソースへのアクセス権を持っていることを証明するために使用されるトークンです。
アクセストークンは通常、短期間しか有効ではなく、有効期限が切れると再度認可が必要になります。

アクセストークンの特徴

• 有効期限がある（例: 1時間など）
• クライアントはこのトークンを使ってリソースサーバーにリクエストを送り、データにアクセス
• スコープ（権限の範囲）によってアクセスできるデータが制限される

アクセストークンが流出すると、第三者に不正アクセスされるリスクがあるため、セキュリティの管理が重要です。

リフレッシュトークン（Refresh Token）

リフレッシュトークンは、アクセストークンの有効期限が切れた際に、新しいアクセストークンを取得するために使われるトークンです。
リフレッシュトークンは通常、アクセストークンよりも長期間有効で、ユーザーが再度ログインすることなく、新しいトークンを取得する手間を省く役割を果たします。

リフレッシュトークンの特徴

• アクセストークンの再発行に使用される
• ユーザーの手間を省き、シームレスな体験を提供
• 一度発行されると、長期間（数日〜数ヶ月）有効であることが多い

リフレッシュトークンが適切に管理されないと、長期間不正利用されるリスクがあるため、保存場所や使用方法には十分な注意が必要です。

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

アクセストークンとリフレッシュトークンの役割を正しく理解することは、OAuth 2.0を安全かつ効率的に使うために非常に重要です。
これらの違いを踏まえて、正しい運用を心がけましょう。

OAuth 2.0の実際の利用例

OAuth 2.0は、さまざまなウェブサービスやアプリケーションで広く使われています。
ここでは、日常的に見かけるOAuth 2.0の利用例をいくつか紹介します。

GoogleやFacebookでのログイン

多くのウェブサイトやアプリケーションでは、ユーザーがGoogleやFacebookなどのアカウントを使ってログインできる「ソーシャルログイン」を提供しています。
この場合、ウェブサイトやアプリはOAuth 2.0を使ってGoogleやFacebookから認証を受け、ユーザーのプロフィール情報（メールアドレスや名前など）へのアクセスを許可されます。

流れの概要（Googleの場合）

• ユーザーが「Googleでログイン」ボタンをクリック
• Googleの認証ページでユーザーが認証
• Googleがウェブサイトにアクセストークンを発行
• ウェブサイトがそのアクセストークンを使ってユーザー情報にアクセス

これにより、ユーザーは新しいアカウントを作成せずに、他のサービスを簡単に利用できるようになります。

APIを利用したサービス間の認可

OAuth 2.0は、APIを使ったサービス間のデータアクセスにもよく利用されます。
たとえば、あるアプリケーションがユーザーのTwitterアカウントに投稿したり、GitHubリポジトリの情報を取得したりする際に、OAuth 2.0が使われます。

具体例: ツールAがユーザーのTwitterアカウントにツイートを投稿する場合

• ツールAがTwitter APIを介してユーザーにアクセス権を要求
• ユーザーは、ツールAがTwitterアカウントに投稿する許可を与える
• TwitterがツールAにアクセストークンを発行
• ツールAがアクセストークンを使ってTwitterに投稿

この仕組みを使えば、サービス同士が連携し、ユーザーのデータに安全にアクセスできるようになります。

セキュリティ上の注意点

OAuth 2.0は安全な認可の仕組みを提供しますが、適切に実装されていないと、脆弱性が発生する可能性があります。
ここでは、OAuth 2.0を利用する際の主要なセキュリティリスクと、それに対する対策を紹介します。

アクセストークンの保護

アクセストークンは、クライアントがリソースにアクセスするための重要なキーです。
もしアクセストークンが第三者に盗まれると、その人物が不正にデータへアクセスするリスクがあります。
トークンがブラウザやネットワークを通じて送受信される際、盗聴や中間者攻撃（MITM）といったセキュリティリスクが存在します。

対策

• HTTPS（SSL/TLS）を必ず使用し、通信の暗号化を徹底する。
• トークンの保存場所には、ブラウザのローカルストレージやセッションストレージではなく、より安全な方法を検討する（例: セキュアクッキー）。
• 短期間で有効期限が切れるトークンを発行し、必要に応じてリフレッシュトークンで再発行する。

リプレイ攻撃のリスク

リプレイ攻撃とは、攻撃者が一度取得したトークンや認証情報を再度送信して、不正にアクセスを試みる攻撃です。この場合、アクセストークンが不正に利用され、意図しないリソースアクセスが発生します。

対策

• アクセストークンの有効期限を短く設定する。
• トークンを利用する際に、タイムスタンプやノンス（使い捨ての一時的な値）を使用し、再利用を防ぐ。
• トークンの使用回数や場所（IPアドレス、デバイス）を制限する。

フィッシング攻撃のリスク

フィッシング攻撃では、ユーザーを偽のログインページや認証ページに誘導し、ログイン情報を盗みます。OAuth 2.0の認可フローが使われている場合、偽の認可ページを作成することで、攻撃者はユーザーのデータに不正アクセスできるようになります。

対策

• 認証ページや認可ページをしっかりと識別し、ユーザーに警告を表示する。
• クライアント側では、正規の認証プロバイダのみを使用することを強制する。
• ユーザーには、認証ページのURLを必ず確認するように促す。

トークンのスコープ制限

OAuth 2.0では、トークンを使ってどの範囲のデータにアクセスできるかを指定する「スコープ」が設定できます。過度に広いスコープを設定すると、攻撃者がトークンを使ってより多くのデータにアクセスする可能性があります。

対策

• 必要最小限のスコープを設定し、無駄に多くのデータにアクセスさせない。
• アプリケーションごとに異なるスコープを設け、特定の機能やリソースにのみアクセスを許可する。

OAuth 2.0の仕組みを活用する際は、これらのセキュリティリスクに十分配慮することが重要です。
適切な対策を講じることで、システム全体のセキュリティを大幅に強化できます。

まとめ

この記事では、OAuth 2.0の認証と認可の仕組みについて、基礎的な概念からセキュリティ対策まで詳しく解説しました。
OAuth 2.0は、ユーザーが自分の個人情報を直接公開することなく、安全に外部サービスと連携できる技術です。

OAuth 2.0を適切に実装することで、ユーザーにとって安全かつ利便性の高いサービスを提供できます。
これからOAuth 2.0を活用したシステムを設計する際には、この記事で学んだ知識を基に、ユーザーにとって安全で使いやすいサービスを提供しましょう。
新しいプロジェクトや既存のシステムで、ぜひOAuth 2.0を導入してみてください。

参考

• OAuth 2.0 Authorization Framework (RFC 6749)
  OAuth 2.0の公式な仕様が定義されているIETFのRFC文書です。

• OAuth 2.0に関するGoogleの開発者向けドキュメント
  Googleが提供するOAuth 2.0の実装に関するガイドです。実際に利用する際に役立ちます。

• OAuth.net
  OAuth 2.0の公式情報を提供しているサイトで、フレームワークに関する基本的な情報が網羅されています。

• OAuth 2.0 Sample Implementation on GitHub
  GitHub上で公開されているさまざまなOAuth 2.0のサンプル実装リポジトリ。実際のコードを参考にしながら学ぶことができます。