私が理解しているように、Box OAuth2 実装では、オプションのリフレッシュ トークン ローテーション スキームを使用します。このスキームでは、アクセス トークンが発行されるたびに、新しいリフレッシュ トークンも発行されます。oauth 仕様書のセクション 10.4 を参照してください。これはオプションの機能であり、Google と Microsoft は OAuth2 実装用の永続的な更新トークンを発行するため (または、少なくとも有効期間が十分に長い更新トークンであるため、実際には問題にはなりません)、採用していません。
私の謙虚な意見では、これは Box にとって非常に残念な選択です。
アプリケーションで行う必要があるのは、新しいアクセス トークンを要求するたびに、返された新しい更新トークンも保存する必要があるため、次にアクセス トークンを要求するときに新しい更新トークンを使用することです。そうすれば、更新トークンが期限切れになる唯一のシナリオは、ユーザーが Box ログインを 60 日間使用しない場合です。彼らがアプリを積極的に使用している限り、新しい更新トークンを取得でき、60 日のライフ サイクルは問題になりません。ここまではうまくいきましたが、常にそうであるとは限りません。
それに関する私の問題は、リクエストごとに更新トークンを保存する必要があることですが、何らかの理由でそれが失敗した場合はどうなりますか: ネットワークの停止、バッテリーのフラットライン、ディスク書き込みの例外がある、アプリがシャットダウンされるOS ....その後、ユーザーに再度ログインするように要求する必要があり、ユーザーはアプリ開発者を非難することになります。
これは、アプリを使用するユーザーが十分にいる場合に発生します。おそらく時間の経過とともに2〜5%だけになるかもしれませんが、それは私の意見では依然として大きな問題です.
少なくとも更新トークンが (半) 永続的である場合は、認証プロセスが完了するまで再試行できます。次に、トークンが保存されていることがわかり、上記のシナリオが発生したときに再試行のためにトークンを引き続き使用できますが、ローテーション スキームではそうではありません。
この問題が発生したユーザー向けに、この質問にリンクする標準のサポート メールを作成することを既に考えています。