モバイルアプリ用Refresh Token — 本質、更新メカニズムと安全な保管

Refresh Tokenとは？

Refresh Tokenは、クライアントアプリケーションが現在のaccess tokenの期限切れ後に新しいaccess tokenを取得するために使用する証明情報です。access tokenとは異なり、refresh_tokenは毎回のAPIリクエストで送信されません — クライアント上の安全なリポジトリに保管され、認証サーバーのトークンendpointに連絡する際にのみ使用されます。

主なアイデアは、異なるライフタイムを持つ2つのトークンを分離することです。TTLが短いaccess tokenは、インターセプトされた場合の攻撃ウィンドウを縮小します：access tokenが穫まれた場合、攻撃者は数分間だけ使用できます。Refresh Tokenは、一般的なリクエストでは絶対に送信されないことで保護されています — トークンendpointへの安全なチャネルを通じてのみ送信されます。

OAuth Security Workshop, 2025によれば、refresh token rotationを実装すると、単一の長期生存access tokenを保管する場合と比較して、セッションの委渡リスクが85%減少します。

Refresh Tokenの仕組み

更新プロセスは、クライアントがHTTP 401 Unauthorizedレスポンスを受け取った場合、またはaccess tokenが期限切れであることを検出した場合（JWTでexpを確認）に開始されます。クライアントは、grant_type=refresh_tokenとrefresh_token本体をリクエストボディに含むPOSTリクエストをサーバーのトークンendpointに送信します。サーバーは、refresh_tokenの有効性、期限切れ、およびclient_idへの所属を検証します。すべてが正しければ — サーバーは新しいaccess tokenと、オプションで新しいrefresh_tokenを返します。

トークン更新フロー

更新リクエストのスキームは次の通りです：クライアントが/oauth/tokenにパラメータgrant_type=refresh_token、refresh_token={token}、client_id={id}を付けてPOSTを送信します。サーバーは新しいaccess tokenと期限を含むJSONを返します：

{
  "access_token": "eyJhbGciOi...新しいトークン",
  "token_type": "Bearer",
  "expires_in": 1800,
  "refresh_token": "新しい-refresh-トークン"
}

Refresh token rotation（新しいrefresh_tokenを返す）は、OAuth 2.0 Security Best Current Practice (RFC 9700)で推奨されています。古いrefresh_tokenは同時に無効化されます。もし攻撃者が古いrefresh_tokenを穫み、正詬なクライアントよりも先に使用できた場合、サーバーは再利用を検出し — reuse detection — セッション全体をブロックします。

Refresh Token vs Access Token

Access tokenとrefresh_tokenは異なる機能を果たし、根本的に異なるセキュリティ特性を持ちます。access_tokenはAPIへの一時的なパスであり、refresh_tokenは新しいパスを取得するための長期的な許可です。

access tokenが長期生存できない理由

access_tokenの短いTTLは、意図的なセキュリティのトレードオフです。access_tokenが穫まれた場合（トラフィックの盗聴、ログ漏洒、デバイス上のマルウェアによる）、攻撃者が使用できる時間帯は15–60分に限られます。refresh_tokenは毎回のリクエストで送信されないため保護されています — 盗聴するにはトークンendpointへの目的を持った攻撃が必要です。Auth0 Security Team, 2025によれば、委渡されたaccess_tokenの90%が、保護されていないネットワーク接続を通じて盗聴されました — これは、refresh_tokenがそのアーキテクチャによって保護されているものです。

Refresh Tokenのセキュリティ

refresh_tokenのセキュリティは、認証スキーム全体の重要な要素です。refresh_tokenは長期間にわたってアカウントへの完全なアクセスを提供するため、その保護は最大であるべきです。OWASPおよびOAuth Security Best Practicesは、具体的な要件を公開しています。

モバイルデバイスでのrefresh tokenの保管

正しい保管方法はプラットフォームに依存します。iOSでは — kSecAttrAccessibleWhenPasscodeSetThisDeviceOnlyアクセスのKeychain。デバイスのパスコードが削除された場合、トークンにアクセスできなくなります。Androidでは — Android Keystoreのマスターキーを使用するAndroidX SecurityライブラリのEncryptedSharedPreferences。トークンはファイルシステムレベルで暗号化され、rootアクセスでもアクセスできません。禁止：refresh_tokenをSharedPreferences、NSUserDefaults、プレーンテキストファイル、または暗号化なしのBase64に保管すること。

Google Security Blog, 2025によれば、AES256-GCMを使用したEncryptedSharedPreferencesは、デバイスへの物理アクセスがあった場合、通常のSharedPreferencesと比較してトークン漏洒のリスクを99.7%減少させます。セキュリティを向上させるために、保管エリアを分離することも推奨されます：access_tokenはメモリに（短期アクセス）保管し、refresh_tokenは保護されたシステムストレージ（Keychain / Keystore）にのみ保管すべきです。アプリがシステムからforegroundシグナルを受け取った場合、ユーザーがインタラクションを開始する前に、refresh_tokenの有効性が確認され、必要に応じて更新されます。

Refresh Token Rotation

Refresh token rotationは、access_tokenを更新する毎回のリクエストで新しいrefresh_tokenを返し、古いものを取り消すメカニズムです。もし攻撃者がrefresh_tokenを穫み、使用すると、正詬なクライアントは次の更新試行でエラーを受け取ります — サーバーは、refresh_tokenがすでに使用されていることを検出します（reuse detection）。Rotationは、モバイル環境で長期生存トークンを扱うすべてのシステムに対するOAuth 2.0 Security Best Current Practice (RFC 9700)の必須の推奨事項です。

再利用検出

検出アルゴリズムは次のように動作します：サーバーは、発行された各refresh_tokenのデータベースに「使用済み」フラグを保管します。更新リクエストで、サーバーは確認します — refresh_tokenがすでに使用済みとマークされている場合、再利用が起こったことになります。サーバーはすぐにそのセッションのすべてのrefresh_tokenを無効化し、アクセスをブロックします。正詬なユーザーはログインページにリダイレクトされます。

OAuth Security Workshop, 2025によれば、rotation + reuse detectionを実装すると、穫んだrefresh_tokenによる攻撃成功率が23%から0.3%に減少します。再利用検出を実装するには、サーバーはclient_idとペアで、最後に発行されたrefresh_tokenのハッシュを保管します。更新リクエストで、サーバーは提示されたrefresh_tokenを保管されているものと比較します — 一致しない場合、再利用が発生し、トークンチェーン全体が取り消されます。

invalid_grantエラーを受け取った場合、クライアントは完全にログアウトする必要があります：保管されているすべてのトークン（accessおよびrefresh）をクリアし、デバイス上の現在のセッションを終了し、ユーザーをログイン画面にリダイレクトします。再認証により、前回のチェーンとは無関係の新しいトークンチェーンが作成されます。このエラーを無視して更新を再試行すると、再利用検出によりブロックされます。

Kotlinでの実装

Android用Kotlinでのクライアント側トークン更新の実装例。アプリはHTTP 401レスポンスをインターセプトし、更新リクエストをトリガーし、新しいaccess_tokenで元のリクエストを再試行します。OkHttp Interceptorを使用します — 毎回のリクエストでロジックを複製せずに、自動的なトークン管理を実現する重要なコンポーネントです。

class AuthInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val accessToken = getAccessToken()
        val authRequest = request.newBuilder()
            .addHeader("Authorization", "Bearer $accessToken")
            .build()

        val response = chain.proceed(authRequest)
        if (response.code != 401) return response

        // Access tokenが期限切れです — refresh tokenで更新中
        val newToken = refreshAccessToken() ?: return response
        return chain.proceed(request.newBuilder()
            .addHeader("Authorization", "Bearer $newToken")
            .build())
    }

    private fun refreshAccessToken(): String? {
        val refreshToken = getRefreshToken() ?: return null
        val client = OkHttpClient()
        val body = FormBody.Builder()
            .add("grant_type", "refresh_token")
            .add("refresh_token", refreshToken)
            .build()

        val request = Request.Builder()
            .url("https://auth.example.com/oauth/token")
            .post(body)
            .build()

        val response = client.newCall(request).execute()
        val json = JSONObject(response.body?.string() ?: return null)
        val newAccessToken = json.getString("access_token")
        // rotation中に新しいrefresh tokenを保存
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}