アジアクエスト デジタルインテグレーション部の井上祐斗と申します。
現代のウェブサービスやアプリケーションでは、「○○でログイン」という機能をよく見かけます。
これらは他のサービスと連携し、ユーザーが簡単にログインできるようにする技術です。
その背後にあるのが「OAuth 2.0」という仕組みです。
たとえば、Googleアカウントを使って別のウェブサイトにログインする機能や、アプリがユーザーの許可を得てソーシャルメディアに投稿する機能など、OAuth 2.0はこうした連携を安全に実現するための標準プロトコルです。
まず、OAuth 2.0を理解するために重要なのは、「認証」と「認可」の違いです。
認証:
ユーザーが誰であるかを確認するプロセスです。
たとえば、ユーザーが自分のIDとパスワードを使ってウェブサイトにログインするのが認証です。
認可:
認証されたユーザーが、どのリソースやデータにアクセスできるかを決めるプロセスです。
たとえば、あなたがウェブアプリに自分のGoogleカレンダーにアクセスする許可を与えることが認可です。
OAuth 2.0は、ユーザーが認証された後、特定のリソースやデータへのアクセスを「認可」する仕組みです。
これにより、ユーザーは自分のアカウント情報を第三者に公開することなく、他のサービスに権限を与えることができます。
この記事では、初心者の方に向けたOAuth 2.0の基本や使用事例について紹介していきます。
OAuth 2.0を理解する上で、まずは登場する基本的な役割や概念を把握することが重要です。
OAuth 2.0は、さまざまなシステムやアプリケーションが安全にリソースへのアクセスを制御できる仕組みを提供しています。
ここでは、主要な役割について説明します。
クライアントは、ユーザーの代わりにリソースにアクセスしようとするアプリケーションやサービスのことを指します。
たとえば、あるウェブアプリがユーザーのGoogleカレンダーにアクセスして、イベントを表示する場合、そのウェブアプリがクライアントです。
リソースオーナーは、アクセスするリソース（データ）の所有者、つまりユーザー自身です。
ユーザーは、自分のデータへのアクセスをクライアントに許可します。
リソースサーバーは、実際にリソース（データ）を保管し、それを提供するサーバーのことです。
たとえば、GoogleカレンダーのデータはGoogleのサーバーに保存されています。このGoogleのサーバーがリソースサーバーに該当します。
認可サーバーは、クライアントがリソースにアクセスするための許可を発行する役割を持っています。
ユーザーがリソースへのアクセスを許可すると、認可サーバーはクライアントに「アクセストークン」という形で許可を与えます。このトークンを使って、クライアントはリソースサーバーにアクセスできます。
OAuth 2.0では、クライアントがリソースオーナーのデータにどの範囲までアクセスできるかを指定する「スコープ」という概念があります。
たとえば、クライアントがユーザーの連絡先だけにアクセスできるようにする、または、カレンダーの読み取りのみを許可する、といった細かな制御が可能です。
OAuth 2.0には、さまざまなシチュエーションに対応するための複数の認可フローがあります。
これらのフローは、クライアントがどのようにリソースオーナーからアクセス権を取得するかを定義しています。
以下では、代表的な4つのフローを紹介します。
このフローは、セキュリティ面で非常に安全なフローの一つです。
特に、サーバー側でアクセストークンを安全に管理できるウェブアプリケーションに適しています。
手順は以下の通りです。
このフローでは、ユーザーが一度認可サーバーにリダイレクトされて認証を行い、その後クライアントに戻ってきます。
これにより、クライアントはユーザーのパスワードを直接扱うことなく、安全に認可を受け取ることができます。
また、アクセストークンが直接ブラウザを介して渡されないため、セキュリティ上のリスクが少ないです。
インプリシットフローは、シングルページアプリケーション（SPA）やクライアントサイドのアプリケーションで使用されます。
SPAとは、ページをリロードせずに動的にコンテンツを更新できるアプリケーションのことです。
このフローでは、クライアントがリソースオーナーから直接アクセストークンを取得し、サーバーを経由しないため、手続きが簡単です。
しかし、アクセストークンがブラウザを介して直接クライアントに渡されるため、セキュリティリスクが高くなる点に注意が必要です。
このフローは、リソースオーナーがクライアントに対してユーザー名とパスワードを直接提供する場合に使われます。
信頼されたクライアント（自社サービスのモバイルアプリなど）で使われることが多いですが、リソースオーナーのパスワードをクライアントが知ることになるため、推奨されるケースは少ないです。
このフローは、リソースオーナーが存在しない状況で使用されます。
クライアント自身が認可サーバーから直接トークンを取得し、リソースにアクセスする場合に適しています。
一般的には、サーバー間の通信やバックエンドのAPIへのアクセスに使用されます。
OAuth 2.0において、認可サーバーから発行されるトークンは、クライアントがリソースにアクセスするための鍵となります。
このトークンには、アクセストークンとリフレッシュトークンの2種類が存在します。
それぞれの役割と使い方を詳しく見ていきましょう。
アクセストークンは、クライアントがリソースサーバーに対してリソースへのアクセス権を持っていることを証明するために使用されるトークンです。
アクセストークンは通常、短期間しか有効ではなく、有効期限が切れると再度認可が必要になります。
アクセストークンが流出すると、第三者に不正アクセスされるリスクがあるため、セキュリティの管理が重要です。
リフレッシュトークンは、アクセストークンの有効期限が切れた際に、新しいアクセストークンを取得するために使われるトークンです。
リフレッシュトークンは通常、アクセストークンよりも長期間有効で、ユーザーが再度ログインすることなく、新しいトークンを取得する手間を省く役割を果たします。
リフレッシュトークンが適切に管理されないと、長期間不正利用されるリスクがあるため、保存場所や使用方法には十分な注意が必要です。
| 項目 | アクセストークン | リフレッシュトークン |
|---|---|---|
| 有効期限 | 短い（数分〜数時間） | 長い（数日〜数ヶ月） |
| 使用目的 | リソースへのアクセス | 新しいアクセストークンの発行 |
| セキュリティリスク | 流出すると即座に不正アクセスの可能性 | 長期間利用されるため、適切な管理が必要 |
アクセストークンとリフレッシュトークンの役割を正しく理解することは、OAuth 2.0を安全かつ効率的に使うために非常に重要です。
これらの違いを踏まえて、正しい運用を心がけましょう。
OAuth 2.0は、さまざまなウェブサービスやアプリケーションで広く使われています。
ここでは、日常的に見かけるOAuth 2.0の利用例をいくつか紹介します。
多くのウェブサイトやアプリケーションでは、ユーザーがGoogleやFacebookなどのアカウントを使ってログインできる「ソーシャルログイン」を提供しています。
この場合、ウェブサイトやアプリはOAuth 2.0を使ってGoogleやFacebookから認証を受け、ユーザーのプロフィール情報（メールアドレスや名前など）へのアクセスを許可されます。
これにより、ユーザーは新しいアカウントを作成せずに、他のサービスを簡単に利用できるようになります。
OAuth 2.0は、APIを使ったサービス間のデータアクセスにもよく利用されます。
たとえば、あるアプリケーションがユーザーのTwitterアカウントに投稿したり、GitHubリポジトリの情報を取得したりする際に、OAuth 2.0が使われます。
この仕組みを使えば、サービス同士が連携し、ユーザーのデータに安全にアクセスできるようになります。
OAuth 2.0は安全な認可の仕組みを提供しますが、適切に実装されていないと、脆弱性が発生する可能性があります。
ここでは、OAuth 2.0を利用する際の主要なセキュリティリスクと、それに対する対策を紹介します。
アクセストークンは、クライアントがリソースにアクセスするための重要なキーです。
もしアクセストークンが第三者に盗まれると、その人物が不正にデータへアクセスするリスクがあります。
トークンがブラウザやネットワークを通じて送受信される際、盗聴や中間者攻撃（MITM）といったセキュリティリスクが存在します。
リプレイ攻撃とは、攻撃者が一度取得したトークンや認証情報を再度送信して、不正にアクセスを試みる攻撃です。この場合、アクセストークンが不正に利用され、意図しないリソースアクセスが発生します。
フィッシング攻撃では、ユーザーを偽のログインページや認証ページに誘導し、ログイン情報を盗みます。OAuth 2.0の認可フローが使われている場合、偽の認可ページを作成することで、攻撃者はユーザーのデータに不正アクセスできるようになります。
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のサンプル実装リポジトリ。実際のコードを参考にしながら学ぶことができます。