はじめに
OAuth を使ったログインは、もはや Web/アプリでは当たり前。
しかしペンテストやセキュリティ設計の現場では、
「そもそもこのアプリは OAuth を使っているのか？」
「どの OAuth フレームワークなのか？」
を正確に見抜く必要があります。
この記事では、実際のアプリを分析する際に使える
OAuth 利用検知 → フレームワーク特定の実践メソッドをまとめました。
1. OAuth 使用のサイン：まずはログイン画面から読む
最初に確認する場所は ログイン画面。
次のようなボタンがあったら、ほぼ間違いなく OAuth / OIDC です：
- Sign in with Google
- Continue with Facebook
- Login with GitHub
- Appleでサインイン
これらは必ず外部ページにリダイレクトするため、OAuth の典型的挙動と一致します。
迷ったらまず「ログインボタン」を疑え。
2. ネットワーク解析で OAuth フローを確定する
OAuth を確実に検知する最強手段は ブラウザの Network タブを見ること。
ログインフロー中に、以下のような URL にリダイレクトされていれば：
https://dev.coffee.thm/authorize?
response_type=code
&client_id=AppClientID
&redirect_uri=https://dev.coffee.thm/callback
&scope=profile
&state=xyzSecure123
これは OAuth 2.0 認可コードフローの典型です。
これらのパラメータが見えたら OAuth 確定
| パラメータ | 意味 |
|---|---|
| response_type | 認可フローの種類（code, token など） |
| client_id | アプリの識別子 |
| redirect_uri | コールバック URL |
| scope | 要求権限（email, profile など） |
| state | CSRF 対策値 |
この5つが揃っている URL を見たら「OAuth が動いている」と断言できます。
3. 次のステップ：使っている OAuth フレームワークを特定する
OAuth 使用が分かったら、次に「どのフレームワークか？」を特定します。
これは脆弱性発見に直結します。
フレームワークごとに「発生しがちなバグ」や「エラー構造」が違うためです。
ここでは、実務でよく使う4つの分析手法を紹介します。
3.1 HTTP ヘッダー＆レスポンスから推測する
レスポンスヘッダーや HTML に、フレームワーク名が紛れ込んでいることがあります。
よくある例
| 観察ポイント | 推測できるフレームワーク |
|---|---|
X-Powered-By: Express |
Node.js + Passport.js |
HTMLコメント <!-- django-oauth-toolkit -->
|
Django OAuth Toolkit |
server: Werkzeug |
Flask + oauthlib |
JSON "spring_oauth_error"
|
Spring Security OAuth |
特に エラー画面はフレームワーク名が漏れやすい黄金地帯。
3.2 ソースコード／静的ファイルから検索する
アプリの JS バンドルや source map が見れる場合、
フレームワーク名がそのまま出てくることがあります。
Django OAuth Toolkit
oauth2_provider/oauth/authorize//oauth/token/
Spring Security OAuth
spring-security-oauth/oauth/check_token
Node.js (Passport)
passport.use(passport-google-oauth20
Python OAuthlib
from oauthlib.oauth2 import
これは特定力が非常に高い方法。
3.3 認可・トークンエンドポイントの構造で推測
フレームワークは URL ルーティングに特徴があり、
これだけで特定できる場合も多いです。
| フレームワーク | よくあるパス |
|---|---|
| Django OAuth Toolkit |
/oauth/authorize/ /oauth/token/
|
| Spring Security |
/oauth/token /oauth/check_token
|
| Node Passport |
/auth/google /auth/google/callback
|
| Keycloak | /realms/<realm>/protocol/openid-connect/ |
| Auth0 | https://*.auth0.com/authorize |
パターンが分かると一瞬で特定できます。
3.4 エラーメッセージから推測する（意外と最強）
以下のようなレスポンスはフレームワーク特有の形です：
OAuthlib（Python）
"error": "invalid_grant",
"error_description": "Invalid redirect URI"
Spring Security OAuth
"error": "access_denied"
Facebook OAuth
"OAuthException"
開発者がデバッグを切り忘れた瞬間があなたのチャンス。
まとめ
OAuth の構造が分かると、アプリの認証が どのように安全性を担保しているか
—or 時に危険な落とし穴を抱えているか—
すぐに見えてきます。
「ログイン画面 → ネットワーク → フレームワークの癖」
この 3 ステップを押さえておけば、OAuth の分析はもう怖くありません。