ポイ活サイト「ワラウ」を運営する株式会社オープンスマイルは2026年10月8日、同社サーバーへの不正アクセスで、Yahoo! JAPAN IDとの連携に使っていた「連携トークン」が外部に流出したと公表しました。対象は2017年8月から2020年頃に発行され、すでに有効期限が切れたトークンです。本記事では、会員が今やること（再連携・対象の確認・届くメールの見分け方）を公式発表の文言で先に示し、続いて期限切れのトークンがなぜログインに使えないのかをYahoo! ID連携 v2の実APIで確かめた結果と、会員サイトを運営する側が不要なトークンを残さないための保管と削除の設計を解説します。
まとめ：ワラウ不正アクセスで公表された事実と会員が今やること
公表されている事実は次のとおりです。流出したのは、PC版ログインと旧Tポイント交換でYahoo! JAPAN IDと連携するときに使っていた連携トークンです。トークンはすべて発行から4週間の有効期限が切れており、連携に必要な同社管理の鍵情報（シークレットキー）は流出していないと確認されています。そのため同社は、この情報で第三者がワラウやYahoo! JAPANのアカウントにログインすることはできないとしています。
| 項目 | 公表されている内容 |
|---|---|
| 流出した情報 | Yahoo! JAPAN ID連携トークン |
| 発行時期 | 2017年8月〜2020年頃 |
| 流出していない情報 | 氏名・メール・パスワード・ポイント・交換先口座 |
| シークレットキー | 流出していないと確認 |
| 実害 | 現時点で確認されていない |
| 対象人数 | 確認中（確定後にお知らせ更新と個別メール） |
表は2026年10月8日付けのお知らせの記載をもとにしています。表の連携トークンは、すべて期限切れのものです。
会員がやることは1つだけです。PC版でYahoo! JAPAN IDを使ってログインしている人は、次にログインするときに連携をやり直します。パスワードの変更やポイントの確認を求める記載はありません。
ワラウ会員が確かめる3点｜再連携の手順と届くメールの見分け方
PC版でYahoo! JAPAN ID連携を使う人の再連携と旧Tポイント交換の扱い
ワラウの公式発表によると、現在使われている連携情報は流出していません。それでも念のため、PC版ログインでのYahoo! JAPAN ID連携は同社がすべて解除しました。PC版でYahoo! JAPAN IDを使ってログインしていた人は、次回ログイン時に連携の手続きをもう一度行います。
旧Tポイント交換でのYahoo! JAPAN ID連携は、すでに提供を終えているため、会員の対応は不要とされています。スマートフォンのアプリやブラウザで、メールアドレスとパスワードでログインしている人について、公式発表は追加の対応を求めていません。
対象者への個別メールとお知らせの更新を待つ間の会員の確認事項
対象となる会員の範囲は、公表時点で確認中です。同社は範囲が確定し次第、お知らせを更新し、対象者に個別のメールを送るとしています。メールで連絡できない人には、お知らせへの掲載で連絡に代えると書かれています。
2017年8月から2020年頃にPC版でYahoo! JAPAN IDを連携した覚えがある人は、対象に入る可能性があります。ただ、流出したのは期限切れのトークンで、氏名・メールアドレス・パスワード・ポイント・交換先の口座情報は流出していないと確認されています。対象かどうかが分かる前に、ポイントの交換先を変えたり、退会したりする必要はありません。
ワラウを名乗る不審なメールと公式の問い合わせ窓口を見分ける基準
事故の公表後は、運営会社を装ってログインやポイントの確認を促すメールが出回りやすくなります。今回の公式発表が会員に求めている手続きは、PC版ログイン時の再連携だけです。メールのリンクからパスワードや口座番号を入力させる案内は、公式発表の内容と一致しません。
迷ったら、メールのリンクは開かず、ブラウザで自分でワラウを開いてログインしてください。本件についての問い合わせは、ワラウ カスタマーサービスの問い合わせフォームが窓口です。運営会社のオープンスマイルは静岡県浜松市に本社を置く会社で、会社概要もワラウのサイトに掲載されています。
公式発表の時系列｜10月4日の検知から10月8日の報告までの経緯
検知から脆弱性の修正と個人情報保護委員会への報告までの4日間
| 日付 | 出来事 |
|---|---|
| 10月4日 | 不正アクセスを検知し同日中に侵入経路を遮断 |
| 10月6日 | 期限切れの連携トークンの流出が判明・脆弱性を修正 |
| 10月8日 | 個人情報保護委員会へ報告・お知らせを公開 |
検知から公表までは4日です。原因は「当社システムの脆弱性」と書かれており、どの機能のどのような不備だったかは明かされていません。個人情報保護委員会への報告は法令に基づくものとされ、速報と確報の段取りは個人情報保護委員会への報告義務で整理しています。
再発防止策の「不要になった情報を確実に削除」が示す保管の実態
同社が再発防止策の筆頭に挙げたのは、不要になった情報を確実に削除する運用の徹底です。2020年頃までに発行され、4週間で期限が切れたトークンが、2026年10月の時点でサーバーに残っていたことになります。最も新しいものでも、期限切れから5年以上たっていた計算です。
期限切れのトークンは、ログインにもAPI呼び出しにも使えません。使えない値を残しておく理由は無く、残っていたこと自体が流出の範囲を広げました。運営する側にとっての教訓は、この1点に集約されます。
期限切れの連携トークンでログインできない理由｜Yahoo! ID連携 v2の仕様
Refresh Tokenの有効期限4週間とクライアント認証の仕組み
Yahoo! JAPAN IDの連携は、OAuth 2.0とOpenID Connectに沿った「Yahoo! ID連携 v2」で実装されます。Yahoo!デベロッパーネットワークのTokenエンドポイントの説明では、Access Tokenの有効期限はレスポンスのexpires_inで返され（例は3600秒）、Refresh Tokenの有効期限は4週間です。公式発表の「発行から4週間」は、この値と一致します。
同じページによると、サーバーサイドのアプリケーションはClient IDとシークレットをBase64でまとめ、Authorization: Basicヘッダーで送らないとトークンを取得も更新もできません。RFC 6749の10.4節も、認可サーバーはRefresh Tokenと発行先のクライアントの結び付きを保たなければならないと定めています。トークンの文字列だけを持っていても、発行先のクライアントになりすませなければ使えない構造です。OAuth 2.0の役割分担はOAuth 2.0の仕組みと認可フローで解説しています。
流出トークンだけを持つ第三者の要求をTokenエンドポイントへ送った結果
次のPythonは、流出したトークンを手に入れた第三者がアクセストークンの再発行を試みる場面を再現します。シークレットを持たない場合と、誤ったシークレットを付けた場合の2通りで、Tokenエンドポイントの応答を見ます。トークン、Client ID、シークレットはどれも実在しないダミーの値です。
import base64, json, urllib.parse, urllib.request, urllib.error
TOKEN_URL = "https://auth.login.yahoo.co.jp/yconnect/v2/token"
def refresh(refresh_token, client_id=None, client_secret=None):
body = urllib.parse.urlencode({"grant_type": "refresh_token",
"refresh_token": refresh_token}).encode()
headers = {"Content-Type": "application/x-www-form-urlencoded"}
if client_id and client_secret:
basic = base64.b64encode(f"{client_id}:{client_secret}".encode()).decode()
headers["Authorization"] = "Basic " + basic
req = urllib.request.Request(TOKEN_URL, data=body, method="POST", headers=headers)
try:
with urllib.request.urlopen(req, timeout=15) as r:
return r.status, json.loads(r.read())
except urllib.error.HTTPError as e:
return e.code, json.loads(e.read())
print("認証なし", *refresh("leaked-refresh-token-dummy"))
print("誤ったシークレット", *refresh("leaked-refresh-token-dummy", "dummy-client-id", "wrong-secret"))2026年10月16日にPython 3.14.7で、実際のTokenエンドポイントへ送った結果です。
認証なし 401 {'error': 'invalid_client', 'error_code': 1109, 'error_description': 'failed to authenticate as a result of insufficient parameter.'}
誤ったシークレット 401 {'error': 'invalid_client', 'error_code': 1108, 'error_description': 'client_id or client_secret are invalid.'}どちらもトークンの中身を調べる前に、クライアント認証の段階で401が返りました。期限切れであることに加え、シークレットが漏れていないことが、同社の「ログインできない」という説明の技術的な裏付けになります。ただし本結果はダミー値での応答で、実在の期限切れトークンで同じ番号が返るかは確かめていません。
シークレットを持たない公開クライアントでは期限だけが守りになる条件
Yahoo!の説明には、クライアントサイドのアプリケーションとして発行されたClient IDではclient_secretの指定が不要だとも書かれています。スマートフォンアプリやブラウザだけで動くアプリは、配布物の中にシークレットを安全に置けないためです。この場合、有効期間内のRefresh Tokenが漏れると、トークンだけで再発行が通る余地が残ります。
今回のワラウの説明はシークレットキーの存在を前提にしており、サーバーサイドでの連携だったと読めます。自社の会員サイトやアプリでID連携を組んでいる場合は、Client IDの種別がどちらかを先に確かめてください。公開クライアントなら、後述するローテーションと短い有効期限が必須になります。
連携トークンの保管表と削除ジョブ｜期限切れの行を残さない実装例
平文を置かずHMACと有効期限を持たせるトークン保管表の設計
RFC 6749の10.4節は、Refresh Tokenを通信時も保管時も秘匿するよう求めています。保管表には平文を置かず、暗号化した値と照合用のHMACだけを持たせ、暗号鍵はKMSなどで別に管理します。ハッシュと暗号の使い分けはハッシュ化と暗号化の違いにまとめました。
もう1つの要は、発行時にexpires_atを必ず記録することです。期限の列が無い表では、どの行が使えない値かを後から判定できず、削除の条件を書けません。連携の解除日時も別の列で持たせると、解除済みの行を一定期間後に消せます。
期限切れと連携解除済みの行を消すSQLiteの実装例と実行結果
次のスクリプトは、保管表を作り、2019年ごろと2020年ごろに発行された期限切れの行、有効期間内の行、10日前に連携を解除した行を入れてから、削除ジョブを1回走らせます。Python 3の標準ライブラリだけで動きます。
import hashlib, hmac, os, sqlite3, time
DAY = 86400
REFRESH_TTL = 28 * DAY # Yahoo! ID連携 v2のRefresh Tokenは4週間
PEPPER = os.environ.get("TOKEN_PEPPER", "dev-only-pepper").encode()
db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE idp_link (
user_id INTEGER NOT NULL,
provider TEXT NOT NULL,
refresh_enc BLOB, -- 暗号化した値（鍵はKMS等で別管理）
refresh_mac TEXT NOT NULL, -- 照合用のHMAC。平文は保存しない
issued_at INTEGER NOT NULL,
expires_at INTEGER NOT NULL,
unlinked_at INTEGER,
PRIMARY KEY (user_id, provider)
);
CREATE INDEX idx_idp_link_expires ON idp_link(expires_at);
""")
def mac(token):
return hmac.new(PEPPER, token.encode(), hashlib.sha256).hexdigest()
def save(user_id, token, issued_at):
db.execute("INSERT OR REPLACE INTO idp_link VALUES (?,?,?,?,?,?,NULL)",
(user_id, "yahoo", b"<encrypted>", mac(token), issued_at, issued_at + REFRESH_TTL))
def purge(now):
# 期限切れは猶予なし・連携解除から7日で消す
cur = db.execute("DELETE FROM idp_link WHERE expires_at < ? "
"OR (unlinked_at IS NOT NULL AND unlinked_at < ?)", (now, now - 7 * DAY))
return cur.rowcount
now = int(time.time())
save(1, "rt-2019-a", now - 6 * 365 * DAY)
save(2, "rt-2020-b", now - 5 * 365 * DAY)
save(3, "rt-active", now - 3 * DAY)
db.execute("UPDATE idp_link SET unlinked_at=? WHERE user_id=3", (now - 10 * DAY,))
save(4, "rt-active-2", now - 1 * DAY)
print("削除前", db.execute("SELECT COUNT(*) FROM idp_link").fetchone()[0], "件")
print("削除 ", purge(now), "件")
print("残り ", db.execute("SELECT user_id, provider FROM idp_link").fetchall())2026年10月16日にPython 3.14.7で実行した結果です。
削除前 4 件
削除 3 件
残り [(4, 'yahoo')]期限切れの2行と、解除から7日を過ぎた1行が消え、有効期間内の1行だけが残りました。本番ではpurgeを日次のジョブで動かし、削除件数を監査ログに残します。ワラウのように、提供を終えた連携（旧Tポイント交換）のトークンが残る事態は、機能の終了時に該当プロバイダの行をまとめて消す手順を加えると防げます。
連携トークンの失効設計｜RFC 7009の失効要求とRFC 9700のローテーション
連携解除と同時にIdP側でトークンを失効させるRFC 7009の要求
自社の表から行を消しても、IdP側でトークンが有効なままなら、写しを持つ第三者には使えます。RFC 7009は、クライアントがtokenと任意のtoken_type_hintをクライアント認証付きで送り、トークンを失効させるための手順を定めた仕様です。サーバーは失効に成功したときだけでなく、無効なトークンを受け取ったときも200を返します。
同じRFCは、失効させたのがRefresh Tokenで、サーバーがAccess Tokenの失効にも対応しているなら、同じ認可に基づくAccess Tokenもすべて無効にすべきとしています。連携を提供するIdPが失効のエンドポイントを公開しているかはIdPごとに違うため、組み込む前に各社の仕様で確かめてください。今回参照したYahoo!のTokenエンドポイントのページには、失効の手順は書かれていません。
漏えいを検知できるリフレッシュトークンのローテーションと再利用検知
2025年1月に出たRFC 9700（OAuth 2.0 Security Best Current Practice）は、公開クライアントのRefresh Tokenに、送信者制約かローテーションのどちらかを必須としています。ローテーションでは更新のたびに新しいRefresh Tokenを出し、古いものは無効になる仕組みです。攻撃者と正規の利用者が同じトークンを使えば、どちらかが無効化済みの値を出すことになり、サーバーはそれを漏えいの兆候として扱い、有効なRefresh Tokenを失効させます。
4.14節は、クライアントが一定期間使われていなければRefresh Tokenを期限切れにすべきだとも書いています。ID連携を自前の認可サーバーで提供する側なら、ローテーション、無操作での期限切れ、パスワード変更時の自動失効の3点を設計に入れてください。API全体の守り方はAPI不正アクセス対策の実装手順で扱っています。
連携トークンの棚卸しを急ぐ事業者と公式の案内待ちで足りる会員
ソーシャルログインを長く提供してきた会員サイトの運営者が今週やること
Yahoo! JAPAN ID、LINE、Googleなどの外部ID連携を数年以上提供している会員サイトは、ワラウと同じ状態になっていないかを今週中に確かめてください。手順は3つです。まず、トークンを保管している表に有効期限と連携解除日時の列があるかを見ます。次に数えるのは、期限切れと提供終了済みの連携の行が何件残っているかです。最後に、削除ジョブを入れたうえで、平文のまま保存している列が無いかを確かめます。
この棚卸しは、表の定義を見れば始められます。ただ、連携の種類が多い、過去の担当者が抜けて保管場所が分からない、といった事情で社内だけでは洗い出せない場合は、脆弱性診断・セキュリティ診断で、認証まわりの保管と外部APIとの接続をまとめて点検できます。
メールアドレスでログインするワラウ会員にとって過剰になる対応
ワラウ会員の側では、公式発表の範囲を超える対応は過剰です。流出したのは期限切れのトークンで、パスワードもポイントも口座情報も対象外とされています。メールアドレスとパスワードでログインしている人は、何もしなくて構いません。
Yahoo! JAPAN IDのパスワードを変える必要も、公式発表には書かれていません。対象者への個別メールとお知らせの更新を待ち、その間はワラウを名乗る不審なメールのリンクを開かないことに集中してください。
よくある質問
ワラウの不正アクセスについて、会員と会員サイトの運営担当者から出やすい質問をまとめました。
ワラウのポイントや交換先の口座情報は盗まれていませんか？
公式発表は、氏名、メールアドレス、パスワード、ポイント、ポイント交換先の口座情報などが流出していないことを確認したとしています。流出したのは、PC版ログインと旧Tポイント交換でYahoo! JAPAN IDと連携するときに使っていた、期限切れの連携トークンだけです。現時点で本件による実害も確認されていないとされています。気になる場合は、メールのリンクではなく自分でワラウを開き、ポイント履歴を確かめてください。
Yahoo! JAPAN IDのパスワードを変更する必要はありますか？
公式発表は、Yahoo! JAPAN IDのパスワード変更を求めていません。流出したトークンは発行から4週間の期限が切れており、連携に必要なシークレットキーも流出していないため、第三者がこの情報でYahoo! JAPANのアカウントにログインすることはできないとされています。ほかのサービスと同じパスワードを使い回しているなら、本件とは別に、使い回しをやめる機会にしてください。
PC版でログインできなくなったのは不正アクセスの影響ですか？
本件の対応として、ワラウはPC版ログインでのYahoo! JAPAN ID連携をすべて解除しました。PC版でYahoo! JAPAN IDを使ってログインしていた人は、次回ログイン時に連携の手続きをやり直す必要があります。これはアカウントが乗っ取られたためではなく、念のための措置と説明されています。再連携してもログインできない場合は、ワラウの問い合わせフォームから連絡してください。
対象になったかどうかはいつ分かりますか？
2026年10月8日のお知らせの時点では、対象となる会員の範囲は確認中です。同社は範囲が確定し次第、お知らせを更新し、個別のメールで知らせるとしています。メールで連絡できない会員には、お知らせへの掲載で連絡に代えるとされているため、ワラウのお知らせ一覧もときどき確かめてください。原因の詳細や件数も、続報で示される可能性があります。
期限切れのトークンでも漏れると問題になるのはなぜですか？
期限切れのトークン単体ではログインに使えませんが、会員と結び付いた情報が外部に出たことに変わりはありません。一般にトークンは会員IDと同じ行に保管されるため、表ごと読まれれば連携の履歴も一緒に出ます（ワラウの事案で何が一緒に出たかは公表されていません）。運営する側から見ると、使えない値を何年も残していたことで、流出の範囲が広がりました。使い終わった値をその日のうちに消す設計にしておけば、同じ不正アクセスを受けても漏れる情報を減らせます。
関連記事
- OAuth 2.0とは？仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説：連携トークンが発行される仕組みの基礎
- JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説：ID連携で受け取るトークンの中身と検証
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：漏れたトークンの失効とAPI側の守り方
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：不正アクセスで漏えいしたときの報告手順
- Studio不正アクセスで全顧客の情報流出か｜パスワード・APIキー・Webhook URLを今日替える手順：外部サービスに預けた認証情報が流出した同時期の事案
