OAuth2リフレッシュトークンは14日間有効

Question

ボックスコードをOAuth2にアップグレードしました。

Googleでは、Webサーバーとそのボックス（SkyDrive、Dropbox、Googleドライブ）の間でファイルを転送できるようにするコードを実装しています。ユーザーのアクセストークンとリフレッシュトークンは、データベースサーバーに保存されます。 http://developers.box.com/oauth/ 1として

、それは 各リフレッシュトークンは60日

のSkyDriveとドライブの両方がのOAuth2を使用して、リフレッシュトークン有効期限を持っていないために有効であると言います。 期限切れでないリフレッシュトークンを使用することはできますか？

アプリケーションによっては、更新トークンが必要ない場合があります。新しいOAuth2スコープを導入することを検討してください。

1. box.read
2. box.read_write
3. box.offline_access私の理解では、ボックスのOAuth2の実装はオプションリフレッシュトークンローテーション方式を採用しています

Answer 1

、どこ毎回アクセストークンが発行されると、新しいリフレッシュトークンも発行されます。 oauth spec documentの10.4項を参照してください。 OAuth2実装のために永続的なリフレッシュトークンを発行する（または、少なくとも十分な寿命を持つトークンをリフレッシュするので、実際には問題ではない）ため、GoogleとMicrosoftは採用しないオプションの機能です。

これは、私の謙虚な意見では、Boxの一部では非常に不幸な選択です。

アプリケーションで実行する必要があるのは、新しいアクセストークンを要求するたびに、新しいリフレッシュトークンを保存する必要があるため、次に新しいトークンを要求するときに新しいリフレッシュトークンを使用する必要がありますアクセストークン。そうすれば、期限切れのリフレッシュトークンで終わる唯一のシナリオは、ユーザーがBoxログインを60日間使用しない場合です。彼らが積極的にアプリケーションを使用している限り、新しいリフレッシュトークンを取得し、60日間のライフサイクルは問題ではありません。これまでのところ良いですが、それはいつもどのように動作するのではないですか、今ですか？

私の問題は、各要求にリフレッシュトークンを保存する必要がありますが、それが何らかの理由で失敗した場合です：ネットワーク停止、バッテリフラットライン、ディスク書き込み例外、 OSによってシャットダウンされます。ユーザーが再びログインするように要求する必要があり、ユーザーはアプリ開発者を責めるつもりです。

これは、アプリを使用する十分なユーザーがいる場合に起こります。時間の経過とともに2〜5％にすぎないかもしれませんが、それは私の意見では依然として大きな問題です。

リフレッシュトークンが（半）完全である場合は、少なくとも、完了するまでauthプロセスを再試行できます。その後、トークンが保存されていることを知っていましたが、上記のシナリオが発生した場合は再試行でも使用できますが、ローテーションスキームでは使用できません。

この問題が発生したユーザーのための標準サポートメールを作成し、この質問にリンクすることを既に検討しています。

Answer 2

入力いただきありがとうございました。Boxは、このフィードバックに基づいてリフレッシュトークンを処理する方法を変更しました。また、パートナーの開発者や顧客の詳細なディスカッションもありました。

ボックスは14日から60日間に移動しました。それは、ほとんどのアプリケーション開発者がアプリケーションのために望むものを超えて、タイムアウトしたユーザーの数を減らす必要があります。

また、ネットワークエラーが発生したときに新しいトークンを発行するとすぐにリフレッシュトークンを無効にしないようにしました。なんらかの理由で新しいリフレッシュトークンを取得できない場合は、コールバックを実行して古いリフレッシュトークンを使用して新しいトークンを取得するだけです。新しいアクセストークンとリフレッシュトークンが取得されるまで、何度でも何度でも行うことができます。

新しいアクセストークンを使用して正常にコールすると、新しいペアが取得されたことがわかり、古いリフレッシュトークンが無効になります。これはまた、新しいRTを取得する同時リクエストがクラスタ内の複数のサーバから機能するため、マルチサーバ環境の改善に役立ちます。