ユーザーがユーザー名とパスワードを提示したときに、短命のアクセストークンとより長生きしたリフレッシュトークンを発行する承認サーバーにアクセスしようとしています。リフレッシュトークンをAPIに渡すタイミング
質問1：
クライアントがアクセストークンとともにAPIへのすべての呼び出しでリフレッシュトークンを渡すべきか、彼らは、エラーコードを受け取った後、クライアントは唯一のリフレッシュトークンを渡す必要がありますアクセストークンが期限切れになったことをAPIから確認しますか？
アクセストークンが期限切れになるまで、クライアントはリフレッシュトークンを必要としません。 すべてのコールでアクセストークンが必要ですが、新しいアクセストークンを許可する要求だけが、更新トークンを必要とします。
新しいアクセストークンを取得するには、section 6 of the RFCのようにgrant_typeをrefresh_tokenに設定してリクエストを送信します。
の前に新しいアクセストークンを要求すると、現在のアクセストークンの有効期限が切れているため、サービスが中断されません。
ほとんどの実装私はで新しいリフレッシュトークンを発行すると見てきました。すべてアクセストークンです。任意の有効なリフレッシュトークンを使用して、新しいアクセストークンを取得できます。
質問2：リフレッシュトークンの有効期限が切れた後は、クライアントに戻されたエラーコードのどのような種類
？これは、クライアントがユーザー名とパスワードを再度渡して新しいアクセストークンを要求する必要があることを意味します。
残念ながら、RFCは明示的にエラー応答を定義していません。 RFC：
リソースアクセス要求が失敗した場合、リソースサーバは、クライアントにエラーの を通知すべきです（SHOULD）。このようなエラー応答の詳細はこの仕様の範囲外ですが、このドキュメントでは、OAuthトークン認証方式間で共有するエラー値について、11.4節で共通のレジストリを確立しています。
したがって、正確な応答はサーバーによって異なります。それは問題のサーバーによって定義される必要があります。
サーバーで新しいリフレッシュトークンが提供されている場合は、現在のリフレッシュトークンが期限切れになる前に新しいリフレッシュトークンを取得することをお勧めします。
ユーザーの資格情報を再度送信する必要はありません。あなたはそれらを持っているはずはありません。OAuth 2は、ユーザーの資格情報を見ることなく、第三者がユーザーの保護されたリソースにアクセスできるように設計されています。
通常、新しいアクセストークンを持つ新しいリフレッシュトークンを、password_grantまたはrefresh_tokenコールで取得します。 RFCはこれを保証しません。
サーバーが新しいリフレッシュトークンを与えない場合や、新しいリフレッシュトークンを使用することができない場合は、ユーザーに再度ログインするように要求する必要があります。このログインはAuthorization Serverを介して行われますが、必ずしもアプリケーションである必要はありません。実際、おそらくそうではありません。
アクセストークンの期限切れについてのあなたの声明が表示されますが、最終的にリフレッシュトークンの有効期限が切れます。その時点で、クライアントは資格情報で再認証する必要があります。 – webworm
@webworm私は自分の答えを更新しました。ほとんどの場合、更新トークンの有効期限はセッションよりもはるかに長くなります。このような場合、ユーザーに再度ログインするように依頼することは問題にはなりません。 –