はじめに

「ログインしたのに、しばらく放置したら画面が戻った」
「毎回ログインしなくても使えるのはなぜ？」

こういった疑問を持ったことはないでしょうか。

自分もはじめて認証まわりのコードを読んだとき、トークンが2種類あって混乱した記憶があります。

この記事では、モバイル・Web問わず共通して使われているトークン認証の仕組みを、できるだけシンプルに整理します。

トークンとは何か ― パスワードを毎回送らないための仕組み

まず前提として、なぜトークンが必要なのかを押さえておきます。

ログインするとき、アプリはサーバーに「このメールアドレスとパスワードで認証してください」とリクエストを送ります。

認証に成功したあと、その後の通信でも毎回パスワードを送り続ける設計は、セキュリティ上好ましくありません。

そこで登場するのが トークン です。

ログイン成功時に、サーバーは「このユーザーは認証済みです」という証明書のような値を発行します。
以降の通信では、パスワードではなく、そのトークンをリクエストに添付して API を呼び出します。

このトークンの代表的な形式が JWT（JSON Web Token） です。

ただし、すべてのトークンが JWT とは限りません。

Access Token や ID Token は JWT として発行されることが多い一方で、Refresh Token は中身を読み取る前提ではない不透明な文字列として扱われることもあります。

2種類のトークンの役割

トークンは1種類ではなく、通常2種類がセットで使われます。

トークン	有効期限の目安	役割
Access Token	短い（例：1時間）	APIを呼ぶときに添付する「入場チケット」
Refresh Token	長い（例：30日など）	Access Token を再発行するための「再発行券」

なぜ2種類に分けるのでしょうか。

Access Token の有効期限を短くすることで、万が一トークンが漏れても被害を限定しやすくなります。

一方で、Access Token が切れるたびに毎回ログインを求めると、ユーザー体験が悪くなります。

そこで、長めに有効な Refresh Token を使って、Access Token をサイレントに再発行するという役割分担になっています。

この「Access Token（短命）+ Refresh Token（長命）」という考え方は、OAuth 2.0 でも使われる一般的なトークン管理の考え方です。

Access Token = 短命な入場チケット
Refresh Token = Access Token の再発行券

ログインから再ログインまでの流れ

実際の動作を4つのフェーズに分けて見ていきます。

フェーズ1：ログイン時

ログインに成功すると、認証サーバーから Access Token と Refresh Token が返されます。

アプリはこの2つを保存し、以降の API 通信に利用します。

フェーズ2：普通に使っているとき

Access Token が有効な間は、API リクエストに Access Token を添付するだけで通信できます。

ユーザーはトークンの存在を意識しません。

フェーズ3：Access Token が切れたとき

Access Token は短命なので、一定時間が経つと期限切れになります。

ここでポイントになるのが Refresh Token です。

Access Token が期限切れになった場合、アプリは Refresh Token を使って新しい Access Token を取得します。

再取得に成功したら、失敗した API リクエストをもう一度実行します。

この処理はアプリ側で自動的に行われるため、ユーザーは基本的に気づきません。

フェーズ4：Refresh Token も使えなくなったとき

Refresh Token も永遠に使えるとは限りません。

Refresh Token が期限切れになったり、無効化されたりすると、新しい Access Token を取得できなくなります。

ユーザーが「もう一度ログインしてください」と言われるのは、多くの場合このタイミングです。

Refresh Token が切れるとどうなるか

Refresh Token の有効期限や更新ルールは、利用する認証サービスによって異なります。

たとえば AWS Cognito では、Refresh Token の有効期限が設定されており、デフォルトでは30日です。
また、アプリクライアント設定により 60分〜10年の範囲で変更できます。

一方で Firebase Auth の Refresh Token は、通常は長期的に有効です。
ただし、ユーザー削除・ユーザー無効化・パスワードやメールアドレス変更などの重大なアカウント変更が発生すると失効します。

Auth0 では、Refresh Token の最大有効期限やアイドル有効期限を設定でき、Refresh Token Rotation を利用する構成もあります。

そのため、

Refresh Token は使うたびに延長されるのか？
ログイン時点から固定なのか？
一定期間使わないと切れるのか？

といった挙動は、利用している認証基盤の仕様を確認する必要があります。

「毎日使っているのに、なぜかログアウトされた」という現象は、Refresh Token の期限や失効ルールが関係していることがあります。

ただし、Refresh Token の扱いはサービスによってかなり違うため、実装時は必ず利用している認証サービスの仕様を確認する必要があります。

サービスによる違い

概念は共通していますが、実装の細部はサービスごとに異なります。

役割	AWS Cognito	Firebase Auth	Auth0	自前 JWT
ログイン	InitiateAuth など	signInWithEmailAndPassword() など	/oauth/token など	独自エンドポイント
短命トークン	Access Token / ID Token	ID Token	Access Token / ID Token	JWT など
有効期限の目安	Access Token / ID Token は短命	ID Token は約1時間	設定による	任意
Refresh Token	デフォルト30日、設定可能	通常は長期有効。ただしユーザー削除・無効化・重大な変更などで失効	設定による。Rotation / Idle Lifetime などあり	任意
トークン更新	実装またはSDKで対応	SDK が自動管理	SDKまたは実装で対応	全部自前

Firebase Auth では、SDK が ID Token の更新を管理してくれるため、フロント側で明示的に 401 を受けてリフレッシュ処理を書く場面は比較的少ないです。

Cognito では Refresh Token を使って新しい ID Token / Access Token を取得できます。
また、Refresh Token Rotation を有効にした場合は、更新時に新しい Refresh Token も発行されます。

Auth0 でも Refresh Token を使ってユーザー操作なしに新しい Access Token を取得できます。
さらに Refresh Token Rotation により、更新のたびに新しい Refresh Token を発行し、古い Refresh Token を無効化する構成も可能です。

自前 JWT の場合は、有効期限・保存場所・更新方法・失効方法をすべて自分たちで設計する必要があります。
自由度は高いですが、その分セキュリティ設計の責任も大きくなります。

実装時に気をつけたいこと

トークンの考え方自体はシンプルですが、実装時にはいくつか注意点があります。

Access Token の有効期限切れは、基本的に 401 Unauthorized として返る
Refresh Token で再取得できた場合は、元の API リクエストを再実行する
Refresh Token も失効していた場合は、ログイン画面へ戻す
Refresh Token の保存場所は慎重に選ぶ
認証サービスによって、自動更新される範囲が異なる

特に Firebase Auth のように SDK が自動で更新してくれるものと、Cognito や自前実装のようにアプリ側で制御が必要なものでは、フロント側の実装方針が変わります。

まとめ

Access Token と Refresh Token の役割をざっくり整理すると、以下のようになります。

トークン	役割
Access Token	API を呼ぶための短命な入場チケット
Refresh Token	Access Token を再発行するための再発行券

Access Token は短命にすることで、漏えい時のリスクを抑えます。

Refresh Token は Access Token を再発行するために使われ、ユーザーに毎回ログインを求めずに済むようにします。

ただし、Refresh Token の有効期限や更新ルールはサービスによって異なります。

そのため実装時には、

Access Token はいつ切れるのか
Refresh Token はいつ切れるのか
自動更新されるのか
失効時にログイン画面へ戻すのか

を確認しておくと、認証まわりの挙動を理解しやすくなります。

参考