Webサービスの自動ログインが安全に保たれる仕組み——アクセストークンとリフレッシュトークン

多くのWebサービスやアプリでは、一度ログインするとブラウザを閉じても次回からIDやパスワードを入れ直すことなく利用できます。

非常に便利な機能ですが、端末内にパスワードそのものが平文で保存されているわけではありません。パスワードを保存することなく、安全にログイン状態（セッション）を維持する現代のトークン認証の仕組みについて整理しました。

1. パスワードを端末に保存しない理由

もしブラウザや端末内にユーザーのパスワードをそのまま保存（またはCookieなどに記録）していた場合、重大なセキュリティリスクを抱えることになります。

• 端末紛失やマルウェア感染のリスク：端末が物理的に盗まれたり、悪意のあるソフトウェアに侵入された際に、本来のパスワードがそのまま抜き取られてしまいます。
• クロスサイトスクリプティング（XSS）による漏洩：Webサイトの脆弱性を突かれてスクリプトを実行された場合、保存されていたパスワードが外部へ送信される危険があります。
• 権限の取り消しが困難：一度漏洩したパスワードは、ユーザー自身が変更するまで不正アクセスを止める手段がありません。

そのため現代のWebサービスでは、最初のログイン成功時にサーバー側が「電子通行手形（トークン）」を発行し、以降の通信ではパスワードではなくトークンを使って認証を行う方式が標準となっています。

2. 2種類のトークンの役割分担

トークンを使った認証（OAuth 2.0など）では、安全性を担保するために「アクセストークン」と「リフレッシュトークン」という役割の異なる2種類のトークンを組み合わせて運用するのが基本です。

アクセストークン（短命な電子通行手形）

Webページを開いたり、サーバーからデータを取得したりする通信ごとに毎回提示する通行手形です。

• 役割：APIへのアクセス権を証明し、ユーザーのデータへのアクセスを許可します。
• 有効期限：数分〜数時間程度と非常に短く設定されています。
• 安全上の設計：日々の通信で何度もネットワーク上を行き来するため、通信経路やブラウザ上で盗聴・漏洩するリスクが相対的に高くなります。そのため、万が一漏洩しても被害を最小限に抑えられるよう、すぐに失効（期限切れ）する仕組みになっています。

リフレッシュトークン（長命な合鍵）

アクセストークンの有効期限が切れた際、ユーザーにパスワードを再入力させることなく、新しいアクセストークンを発行してもらうための合鍵です。

• 役割：新しいアクセストークンを再取得するためだけに使用されます。
• 有効期限：数日〜数ヶ月、あるいは数年など、比較的長期間に設定されています。
• 安全上の設計：通常のデータ通信には一切乗せず、トークン更新専用のエンドポイントとの間でのみやり取りされます。ブラウザ環境では、JavaScriptから読み取れないよう保護された属性（HttpOnly や Secure）を持つCookieなどに格納して保管されるのが一般的です。

3. 自動更新の流れと仕組みのまとめ

アクセストークンが失効した際、バックグラウンドでは以下のような処理が自動的に行われています。

1. アクセス拒否：期限切れのアクセストークンで通信すると、サーバーから「認証エラー（期限切れ）」が返る。
2. トークン再要求：ブラウザ（またはアプリ）が、安全に保持しているリフレッシュトークンを認証サーバーに送信する。
3. 新規発行：認証サーバーがリフレッシュトークンを検証し、問題がなければ新しいアクセストークンを発行する。
4. 通常通信の再開：新しく取得したアクセストークンを使って、本来のリクエストを再試行する。

この一連のやり取りがバックグラウンドで瞬時に行われるため、ユーザーは再ログインを意識することなく使い続けることができます。

4. 安全と利便性の両立

Webサービスの自動ログインは、「日常的に使う鍵」と「金庫の鍵」を分離するアプローチによって成り立っています。

• 頻繁に持ち歩くアクセストークンは短命にして、万が一落としてもすぐ使えなくする
• 長命なリフレッシュトークンは普段の通信には出さず、安全な場所に保管する
• パスワードそのものは端末に残さないため、パスワード漏洩の連鎖を防げる
• 不審なログインや端末紛失時は、サーバー側でリフレッシュトークンを無効化すれば遠隔ログアウトが可能

利便性を損なうことなく、通信路上のリスクと端末側のリスクを最小化する設計になっています。