はじめに
Webサービスを利用する際に「Googleアカウントでログイン」や「Twitterアカウントで連携」といったボタンを見たことはありませんか？この便利な機能を支えているのがOAuthという仕組みです。
本記事では、OAuthの基本的な仕組みを初心者の方にも分かりやすく解説します。
OAuthが解決する問題
従来の認証方式の課題
OAuthが登場する前は、外部サービスと連携する際に次のような問題がありました。
例えば、写真管理アプリがGoogleフォトの写真を取得したい場合を考えてみましょう。従来の方式では、ユーザーはGoogleアカウントのIDとパスワードを写真管理アプリに直接入力する必要がありました。
この方式には以下のような深刻な問題があります。
- セキュリティリスク: パスワードを第三者のアプリに渡すことになる
- 権限の制御ができない: アプリに全ての権限を与えることになる
- パスワード変更時の問題: パスワードを変更すると全ての連携アプリで再設定が必要
OAuthが登場した背景
これらの課題を解決するために、「パスワードを渡さずに、必要な権限だけを安全に委譲する」という仕組みとしてOAuthが開発されました。
OAuth 1.0が2007年に、より使いやすく改良されたOAuth 2.0が2012年に標準化されました。現在、多くのWebサービスで採用されている標準的な認可の仕組みです。
OAuthの基本的な仕組み
登場人物（4つの役割）
OAuthには4つの役割が登場します。
- Resource Owner（リソース所有者）: データの持ち主であるユーザー自身
- Client（クライアント）: ユーザーが利用したいアプリケーション
- Authorization Server（認可サーバー）: ユーザーの認証と権限の付与を行うサーバー
- Resource Server（リソースサーバー）: 実際のデータを保管しているサーバー
認可フロー（流れ）の全体像
OAuthの基本的な流れは次のようになります。
- アプリがユーザーに「○○の権限がほしい」と要求
- ユーザーが認可サーバーで許可
- 認可サーバーがアプリにアクセストークンを発行
- アプリはトークンを使ってリソースサーバーからデータを取得
重要なポイント: パスワードは一切アプリに渡されません。
具体例で理解するOAuth
「Googleアカウントでログイン」の裏側
写真編集アプリで「Googleアカウントでログイン」をクリックした場合の流れを見ていきましょう。
この流れのポイントは以下の通りです。
- ユーザーはGoogleのサイトでログインするため、パスワードがアプリに渡らない
- ユーザーが明示的に「許可する」を選択する
- アプリは「写真の読み取り」のみの権限を取得（他のデータにはアクセスできない）
OAuthの認可フロー詳細
認可コードフロー（Authorization Code Flow）
最も一般的に使われる認可コードフローについて、もう少し詳しく見ていきましょう。
ステップ1: 認可リクエスト
アプリがユーザーを認可サーバーにリダイレクトします。このとき、以下の情報を含むURLを生成します。
-
client_id: アプリを識別するID -
redirect_uri: 認可後に戻ってくるURL -
scope: 要求する権限の範囲 -
state: CSRF攻撃を防ぐためのランダムな値
ステップ2: ユーザーの認証と認可
ユーザーが認可サーバーでログインし、アプリへの権限付与を承認します。
ステップ3: 認可コードの発行
認可サーバーがアプリに認可コードを返します。この認可コードは一時的なもので、短時間で期限切れになります。
ステップ4: アクセストークンの取得
アプリは認可コードと自身の秘密鍵を使って、認可サーバーからアクセストークンを取得します。この秘密鍵は、アプリが正当なものであることを証明します。
ステップ5: リソースへのアクセス
取得したアクセストークンを使って、リソースサーバーからデータを取得します。
よく使われる用語の整理
アクセストークンとは
アクセストークンは、リソースにアクセスするための鍵のようなものです。
- 有効期限が設定されている（通常は数時間から数日）
- 特定の権限（スコープ）のみを持つ
- パスワードと異なり、必要に応じて無効化できる
リフレッシュトークンとは
リフレッシュトークンは、アクセストークンの有効期限が切れた際に、新しいアクセストークンを取得するためのトークンです。
- アクセストークンより長い有効期限を持つ
- ユーザーが再度ログインする必要がない
- より厳重に管理される必要がある
スコープとは
スコープは、アプリが要求する権限の範囲を表します。
例えば、Googleの場合は以下のようなスコープがあります。
-
https://www.googleapis.com/auth/userinfo.email: メールアドレスの読み取り -
https://www.googleapis.com/auth/drive.readonly: Googleドライブの読み取り専用アクセス
スコープを細かく設定することで、アプリに必要最小限の権限だけを与えることができます。
OAuth 2.0とOpenID Connectの違い
OAuthについて調べていると、OpenID Connectという言葉を目にすることがあります。この2つの関係を整理しておきましょう。
OAuth 2.0
- 目的: 認可（権限の委譲）
- 用途: 他のサービスのデータにアクセスする権限を得る
- 例: 「このアプリにGoogleドライブの写真を読ませる」
OpenID Connect
- 目的: 認証（本人確認）+ 認可
- 用途: ログイン機能として使う
- 例: 「Googleアカウントでログインする」
- 特徴: OAuth 2.0を拡張したもの
OpenID ConnectはOAuth 2.0の上に構築されており、IDトークンという仕組みを追加することで、「このユーザーが誰か」を確認できるようになっています。
まとめ
OAuthは以下のような特徴を持つ認可の仕組みです。
- パスワードを第三者のアプリに渡さずに済む
- 必要な権限だけを限定して委譲できる
- ユーザーが明示的に許可する仕組み
- いつでも権限を取り消すことができる
これにより、安全で便利なサービス連携が実現されています。
OAuthを理解することで、普段使っているWebサービスの裏側で何が起きているのかが見えてくるようになります。セキュリティを意識したサービス開発にも役立つ知識ですので、ぜひ実際のサービスで試してみてください。