図でざっくり解説 OAuth 2.0入門

図でざっくり解説 OAuth 2.0入門

0. この記事を作成するきっかけ

OAuth 2.0は、現代のウェブアプリケーションやモバイルアプリで広く使用されている仕組みです。しかし、具体的にどのように機能しているのか、登場人物やステップごとの流れが少しわかりにくいと感じる方も多いのではないでしょうか。
私自身も、OAuth 2.0について調べた際に、多くの技術的な用語や図の説明に混乱し、なかなか全体像を掴むのに苦労しました。そこで、初心者でも直感的に理解できるように、できるだけシンプルに、かつ図を使ってわかりやすく説明する記事を作成することを目指しました。

本記事では、OAuth 2.0の全体の流れと主要な登場人物を簡単に解説し、実際の認証の流れを図を用いて説明します。最初に読んだときからスムーズに理解できるように設計していますので、この記事を通じて少しでもOAuth 2.0の理解が深まれば幸いです。

1. OAuth 2.0って何？

OAuth 2.0（オーオース2.0）は、ユーザーのパスワードを他のサービスに渡さずに、アプリやサービスがユーザーの情報にアクセスできるようにする仕組みです。

OAuth 2.0自体は認可の仕組みであり、認証のための技術ではありません。
たとえば、"Googleでログイン"のような機能を実現するには、OAuth 2.0を基盤にしたOpenID Connectと呼ばれる標準化された認証仕様が利用されます。

2024/10/13 ↑説明に関して誤った情報がありました。現在は修正しています。

登場人物

OAuth 2.0には、4つの主要な登場人物がいます：

1. ユーザー（Resource Owner）
   サービスを利用する人。例えば、Googleアカウントを持っている人。

2. クライアント（Client）
   ユーザーの代わりに、他のサービス（認可サーバー）にリソースを要求するアプリケーション。例えば、「Googleでログイン」を使うアプリ。

3. 認可サーバー（Authorization Server）
   クライアントのリクエストを検証し、トークンを発行するサービス。例えば、Google。

4. リソースサーバー（Resource Server）
   実際にユーザーのデータ（リソース）を持っているサーバー。リソースサーバーは、認可サーバーから発行されたトークンを使ってアクセスを制御します。これも、GoogleのAPIなどが該当します。

2. OAuth 2.0の全体の流れ

OAuth 2.0の全体的な流れを説明します。以下は、ユーザーがアプリでGoogleアカウントを使ってログインする場面を想定した例です。

1. ユーザーがクライアント（アプリ）にログインを試みる。
2. クライアントは、ユーザーのGoogleアカウントにアクセスするために、認可サーバー（Google）に認証リクエストを送る。
3. 認可サーバーはユーザーに、クライアントがデータにアクセスしてもよいかを確認する画面を表示する。
4. ユーザーがアクセスを許可する。
5. 認可サーバーはクライアントにアクセストークンを発行する。
6. クライアントは、このアクセストークンを使ってリソースサーバーにリソース（たとえば、ユーザーのメールアドレスなど）を要求する。
7. リソースサーバーがクライアントにリソースを提供する。

OAuth 2.0の基本的な流れは、クライアントが認可を取得し、トークンを使ってリソースにアクセスすることです。

3. 各ステップの詳細

ステップ 1: クライアントが認可リクエストを送る

ユーザーがクライアントにログインしようとすると、クライアントはまず認可サーバーにリクエストを送ります。これは「認可コード」を取得するためのリクエストです。

認可コードとは、一時的に発行されるコードで、後のステップでアクセストークンと引き換えられます。このリクエストには、以下の情報が含まれています：

• クライアントID（クライアントが誰かを識別するID）
• リダイレクトURI（認可が成功した際にクライアントが戻ってくる場所）
• アクセスを求めるリソースのスコープ（範囲）

ステップ 2: 認可サーバーがユーザーに許可を求める

認可サーバー（Google）は、ユーザーに「このアプリにあなたの情報にアクセスすることを許可しますか？」という許可画面を表示します。ここでユーザーは、アクセスの可否を選ぶことができます。

ステップ 3: 認可サーバーが認可コードを発行する

ユーザーがアクセスを許可すると、認可サーバーはクライアントに「認可コード」を発行します。このコードは、クライアントがユーザーのパスワードを知ることなく、後でアクセストークンを取得するために使われます。

ステップ 4: クライアントがアクセストークンを取得する

クライアントは認可コードを受け取った後、それを使って認可サーバーにアクセストークンをリクエストします。アクセストークンは、クライアントがリソースサーバーにアクセスするための「カギ」のようなものです。このトークンは、ユーザーのパスワードは一切関与しません。

ステップ 5: クライアントがリソースサーバーにアクセスする

最後に、クライアントはリソースサーバーにアクセストークンを提示し、ユーザーのデータ（リソース）にアクセスします。このステップでは、リソースサーバーはトークンの有効性を確認し、認可された範囲内で必要なデータを返します。

4. OAuth 2.0のメリット

OAuth 2.0は、パスワードを他のサービスと共有することなく、ユーザーのデータにアクセスできる安全な仕組みです。

• セキュリティ：パスワードを直接やり取りしないので、セキュリティリスクが大幅に低減します。また、トークンは一時的で、必要に応じて期限切れにすることができます。
• 柔軟性：OAuth 2.0は、Webアプリケーション、モバイルアプリ、シングルページアプリケーションなど、多様な環境で利用可能です。
• スコープの指定：アクセスできるデータの範囲を細かく指定できるため、必要以上に情報を共有しなくて済む。

5. OAuth 1.0と2.0の違い

OAuth 1.0は設定が複雑で、暗号化技術の導入が必要でした。一方、OAuth 2.0はその点を大幅に簡素化し、より柔軟で使いやすくなっています。

主な違い

• 複雑さの改善：OAuth 1.0は非常に複雑で、HMAC-SHA1のような暗号化技術を使うための追加作業が必要でした。OAuth 2.0はこの部分を大幅に簡素化し、トークンのやり取りがよりシンプルになりました。
• セキュリティの改善：OAuth 2.0では、アクセストークンの使い方が改善され、アクセストークンの使用期限や権限範囲が指定できるようになりました。
• サポートの多様性：OAuth 2.0は、様々な認証方式（Webアプリ、モバイルアプリ、シングルページアプリケーションなど）に対応しています。OAuth 1.0ではこの柔軟性がありませんでした。

まとめ

OAuth 2.0は、ユーザーのパスワードを保護しながら、アプリケーションがユーザーのデータにアクセスするための強力な仕組みです。アクセストークンの発行と使用により、セキュリティとユーザー体験の向上を実現しています。特に、APIの利用や他サービスとの連携が求められる現代のウェブアプリケーション開発においては、OAuth 2.0は欠かせない技術です。

さらに、OAuth 2.0の柔軟なスコープ指定や認証フローを理解することで、最小限のリスクで最大限のセキュリティとユーザビリティを提供できるようになります。OAuth 2.0の導入により、セキュアで信頼性の高いアプリケーションを構築することが可能です。