FileMakerから、GoogleのAPIを利用する際に、リフレッシュトークン(更新トークン)をFileMakerの内部で管理します。
その際に、お客様から「リフレッシュトークンは、更新する必要がなく、ずっと使えるの？」と良く質問を頂きます。
ということで、リンクを張っておきます。
リフレッシュトークンの有効期限について
付与された更新トークンが機能しなくなる可能性を想定したコードを記述する必要があります。更新トークンが機能しなくなる理由は、次のいずれかです。
- ユーザーがアプリのアクセス権を取り消した。
- 更新トークンが 6 か月間使用されていません。
- ユーザーがパスワードを変更し、更新トークンに Gmail スコープが含まれている。
- ユーザーアカウントが付与されている（有効な）更新トークンの最大数を超えています。
- 管理者がアプリのスコープでリクエストされたサービスのいずれかを制限付きに設定した場合（エラーは admin_policy_enforced）。
ということで、基本的には一度取得したリフレッシュトークンは、無効化されることがないという認識です。
有効期限切れを防ぐための実践的な対策
しかし、実際の運用では以下の点に注意が必要です。「6ヶ月以内にリフレッシュする」だけでは不十分で、包括的なトークン管理戦略が重要です。
1. 定期的な使用（6ヶ月ルール対策）
- 6ヶ月以内に必ず1回はリフレッシュトークンを使用する
- 実際には3-4ヶ月間隔での定期実行を推奨
- バックグラウンドでの自動実行を設定
2. ユーザーのパスワード変更時の考慮点
特にGmailスコープを含む場合、ユーザーのパスワード変更がリフレッシュトークンに与える影響について理解しておく必要があります。
3. エラーハンドリングの実装
- トークンが無効化された場合の再認証フローを準備
- ユーザーに分かりやすいエラーメッセージを表示
- 自動復旧機能の実装
4. 最大トークン数の管理
- 同一ユーザーが複数のアプリで認証する場合の上限に注意
- 不要な認証を定期的に整理
- トークン使用状況の監視
5. セキュリティ対策
- Gmailスコープを使用する場合は、パスワード変更時の影響を考慮
- 必要最小限のスコープのみを要求
- セキュリティログの監視
まとめ
Google OAuth 2.0のリフレッシュトークンは適切に管理すれば長期間使用できますが、複数の無効化条件が存在するため、予防的な対策と適切なエラーハンドリングが重要です。
特にFileMakerとの連携においては、自動化された定期メンテナンスの仕組みを構築することを強く推奨します。