【ITニュース解説】## Understanding Access Token and Refresh Token Flow

Webサービスやスマートフォンアプリを利用する際、一度ログインすれば、しばらくの間はパスワードを再入力しなくてもサービスを使い続けられる。この「ログイン状態の維持」は、トークンベース認証と呼ばれる仕組みによって実現されていることが多い。ユーザーが毎回パスワードを送信する方法は、通信経路上でパスワードが盗まれるリスクが高いため、セキュリティ上好ましくない。その代わりに、ログイン成功時にサーバーが発行する「トークン」という特殊な文字列を、パスワードの代わりとして通信に利用する。このトークン認証の中でも、特にセキュリティと利便性の両立に優れた手法が、アクセストークンとリフレッシュトークンという2種類のトークンを使い分ける方式である。

この方式では、ユーザーがログインに成功すると、サーバーは2種類のトークンを発行する。一つは「アクセストークン」、もう一つは「リフレッシュトークン」である。それぞれは異なる役割と有効期間を持つ。アクセストークンは、APIへのリクエスト、つまりサーバーに対して何らかの処理を要求する際に使用される。これはユーザーが本人であることを証明するための鍵のようなものであり、リクエストのたびにサーバーへ送信される。しかし、このアクセストークンの有効期間は非常に短く設定されており、数分から1時間程度で無効になる。これは、万が一アクセストークンが第三者に漏洩した場合でも、利用できる時間が限られているため、被害を最小限に抑えるというセキュリティ上の狙いがある。一方、リフレッシュトークンは、アクセストークンが失効した際に、新しいアクセストークンを取得するためだけに存在する特別なトークンである。APIへのリクエストには直接使われず、その有効期間は数日や数週間といった長期間に設定される。このリフレッシュトークンがあるおかげで、ユーザーはアクセストークンの有効期間が切れるたびに再ログインする必要がなくなる。

実際の処理の流れは次のようになる。まずユーザーがIDとパスワードを入力してログインすると、サーバーは認証情報を検証し、正しければアクセストークンとリフレッシュトークンのペアを生成してユーザーのクライアント（Webブラウザやスマートフォンアプリ）に返す。クライアントはこれらを安全な場所に保存する。次に、ユーザーが保護された情報（例えば、自身のプロフィールページなど）にアクセスしようとすると、クライアントはリクエストのAuthorizationヘッダーと呼ばれる部分にアクセストークンを含めてサーバーに送信する。サーバーは受け取ったアクセストークンを検証し、有効であればリクエストに応じた処理を実行し、結果を返す。このやり取りが、アクセストークンの有効期間内は繰り返される。やがてアクセストークンの有効期間が過ぎると、クライアントが同じようにリクエストを送信しても、サーバーはそれを無効なトークンと判断し、「401 Unauthorized」というエラーを返す。ここでリフレッシュトークンの出番となる。通常、クライアント側のプログラムは、この401エラーを検知すると自動的に特別な処理を開始する。ユーザーにエラーを通知するのではなく、裏側で保持しているリフレッシュトークンを使い、サーバー上のトークン再発行専用のエンドポイント（特定のURL）にアクセスする。サーバーは送られてきたリフレッシュトークンが有効かどうかを検証する。この検証には、有効期限が切れていないか、あるいは不正利用などの理由で無効化されていないかといった確認が含まれる。リフレッシュトークンが正当であると確認できれば、サーバーは新しいアクセストークンと、多くの場合、新しいリフレッシュトークンのペアを生成してクライアントに返す。このとき、セキュリティをさらに高めるため、一度使用された古いリフレッシュトークンは無効化される。新しいトークンのペアを受け取ったクライアントは、それらを保存し直し、先ほど401エラーで失敗したAPIリクエストを、新しいアクセストークンを使って自動的に再試行する。この一連の処理はバックグラウンドでシームレスに行われるため、ユーザーはログイン状態が途切れたことに気づくことなく、サービスを継続して利用できる。

このように、アクセストークンとリフレッシュトークンの仕組みは、短命なアクセストークンで日々の通信の安全性を確保しつつ、長命なリフレッシュトークンでユーザーの利便性を損なわないという、優れたバランスを実現している。この仕組みを支える上で極めて重要なのが、リフレッシュトークンの厳重な管理である。リフレッシュトークンは長期間有効なため、これが漏洩すると長期間にわたって不正アクセスの足がかりを与えてしまう。そのため、サーバー側ではリフレッシュトークンを安全なデータストアに保管する必要がある。最も一般的な方法は、データベースに専用のテーブルを用意して保存することである。この際、トークンそのものを平文で保存するのではなく、ハッシュ化という不可逆な変換を施した文字列を保存することが不可欠である。これにより、万が一データベースの情報が漏洩しても、元のリフレッシュトークンを割り出すことは極めて困難になる。また、データベースで管理することで、特定のユーザーのセッションを強制的に終了させたい場合（例えば、ユーザーが「すべてのデバイスからログアウト」機能を使った場合）に、該当するリフレッシュトークンのレコードを削除するだけで、簡単にトークンを無効化（失効）させることができる。トラフィックが多い大規模なシステムでは、より高速な読み書きが可能なRedisのようなインメモリキャッシュが保管場所として利用されることもある。いずれの場合も、リフレッシュトークンをサーバー側でしっかりと管理し、必要に応じて失効させられる体制を整えることが、この認証方式の安全性を担保する上で鍵となる。