更新トークンのポイントは何ですか？
私は非常に長い間この質問があったことを告白しなければなりません、本当に理解しません。
認証トークンは金庫の鍵のようなもので、期限が切れるともう使えなくなります。これで、使用可能な別のキーを取得するために使用できるマジックリフレッシュトークンが提供されます。また、マジックキーの有効期限が切れるまで、別のトークンが提供されます。それでは、認証トークンの有効期限を更新トークンと同じに設定しないのはなぜですか？なぜそんなに気にしないの？
それの正当な理由は何ですか、おそらく歴史的な理由ですか？本当に知りたい。ありがとう
参照されている回答（@Andersを介して）は役に立ちます。
侵害の場合、有効期間は限定されますが、トークンはSSLを介して使用されるため、侵害される可能性はほとんどありません。
重要な部分は、アクセストークンがログに記録されることが多いため（特に、クエリパラメーターとして使用される場合、JSONPに役立ちます）、有効期間が短いことが最善です。
サービスプロバイダーによるOAuth 2.0の大規模な実装では、いくつかの追加の理由があります。
APIサーバーは、失効の心配が無ければ、DB検索やRPC呼び出しを行わなくても、アクセストークンを安全に検証できます。これにより、パフォーマンスが大幅に向上し、APIサーバーの複雑さが軽減されます。 30分から60分（またはアクセストークンの長さが何であれ）のトークンの取り消しに問題がない場合に最適です。もちろん、APIサーバーは、過去1時間に取り消されたトークンのメモリ内リストも保持できます。
トークンは複数の異なるAPIサービスにアクセスできる複数のスコープを持つことができるため、存続期間の短いアクセストークンがあると、APIサービスの開発者がAPIサービスBのユーザーのデータに生涯アクセスできるようになります。区分けはセキュリティに適しています。
先日、Taiseer Joudehが 記事 を読んでいて、彼が言った非常に役に立つと思います：
私の意見では、リフレッシュトークンを使用することには、主に次の3つの利点があります。
アクセストークンコンテンツの更新：アクセストークンは自己完結型トークンであることがわかっているため、生成された認証済みユーザーに関するすべてのクレーム（情報）が含まれます。これは、ユーザーに長期間トークン（1か月など）を発行する場合です。 「アレックス」という名前を付け、彼を「ユーザー」ロールに登録すると、この情報は認証サーバーが生成したトークンに含まれます。後で（彼がトークンを取得してから2日後）彼を「管理者」ロールに追加することにした場合、生成されたトークンに含まれるこの情報を更新する方法はありません。もう一度彼に自己認証を依頼する必要があります。そのため、承認サーバーはこの情報をこの新しく生成されたアクセストークンに追加しますが、ほとんどの場合、これは実行できません。長命のアクセストークンを取得したユーザーにアクセスできない可能性があります。したがって、この問題を克服するには、存続期間の短いアクセストークン（たとえば30分）を発行し、更新トークンを使用して新しいアクセストークンを取得する必要があります。新しいアクセストークンを取得すると、承認サーバーはユーザーの新しいクレームを追加できます新しいアクセストークンが生成されると、彼を「管理者」ロールに割り当てる「アレックス」
認証済みユーザーからのアクセスの取り消し：ユーザーが長期間有効なアクセストークンを取得すると、アクセストークンの有効期限が切れていない限り、サーバーリソースにアクセスできます。承認サーバーがカスタムロジックを実装しない限り、アクセストークンを取り消す標準的な方法はありません。これにより、生成されたアクセストークンをデータベースに保存し、リクエストごとにデータベースチェックを行う必要があります。ただし、リフレッシュトークンを使用すると、システム管理者はデータベースからリフレッシュトークン識別子を削除するだけでアクセスを取り消すことができます。システムが削除されたリフレッシュトークンを使用して新しいアクセストークンを要求すると、リフレッシュトークンが使用できなくなるため、Authorization Serverはこの要求を拒否します。 （これについて詳しく説明します）。
ユーザー名とパスワードを保存または要求する必要はありません。リフレッシュトークンを使用すると、ユーザーが初めて認証されたときに一度だけユーザー名とパスワードを要求することができ、Authorization Serverは長期間有効なリフレッシュトークンを発行できます（1年間例）システム管理者が更新トークンを取り消そうとしない限り、ユーザーはこの期間中ログインしたままになります。これはサーバーリソースへのオフラインアクセスを行う方法と考えることができます。これは、ユーザー名/パスワードを頻繁に要求し続けることができないフロントエンドアプリケーションによって消費されるAPIを構築している場合に役立ちます。
これに別の視点を加えたいと思います。
リクエストごとにDBにアクセスしないステートレス認証
認証を行うためにデータベース呼び出しを行わなくても、数百万のユーザーの認証を実行できるステートレス（セッションなし）のセキュリティメカニズムを作成するとします。アプリが取得するすべてのトラフィックで、各リクエストでDB呼び出しを保存することには大きな価値があります。また、ステートレスである必要があり、簡単にクラスタ化して数百または数千のサーバーにまで拡張できます。
昔ながらのセッションでは、ユーザーがログインし、その時点でデータベースからユーザー情報を読み取ります。何度も読み取る必要をなくすために、セッションに保存します（通常はメモリまたはクラスター化されたキャッシュ）。セッションIDは、後続のすべてのリクエストに添付されるCookieでクライアントに送信されます。後続のリクエストでは、セッションIDを使用してセッションを検索します。セッションにはユーザー情報が含まれています。
ユーザー情報を直接アクセストークンに入れます
しかし、セッションは必要ありません。したがって、セッションにユーザー情報を保存する代わりに、アクセストークンに入れてみましょう。トークンに署名して、誰もそれを改ざんしたりプレストしたりできないようにします。セッションがなく、リクエストごとにDBからユーザー情報を検索する必要なく、リクエストを認証できます。
セッションなし...ユーザーを禁止する方法はありませんか？
しかし、セッションがないことには大きなマイナス面があります。たとえば、このユーザーが禁止された場合はどうなりますか？古いシナリオでは、彼のセッションを削除するだけです。その後、再度ログインする必要がありますが、ログインすることはできません。禁止が完了しました。しかし、新しいシナリオではセッションはありません。では、どうすれば彼を禁止できますか？私たちは彼に（非常に丁寧に）アクセストークンを削除するよう依頼する必要があります。各着信要求を禁止リストと照合しますか？はい、動作しますが、今度は必要のないDB呼び出しを再度実行する必要があります。
存続期間の短いトークンによる侵害
たとえば、禁止されてから10分間、ユーザーが自分のアカウントを使用できる可能性がある場合は、リクエストごとにDBをチェックすることと、ログイン時にのみDBをチェックすることの妥協という状況を作り出すことができます。そして、それがリフレッシュトークンの出番です。これにより、存続期間の短いアクセストークンでステートレスメカニズムを使用できます。これらのトークンに対してデータベースチェックが行われないため、これらのトークンを取り消すことはできません。現在の時刻に対してのみ有効期限を確認します。ただし、有効期限が切れると、ユーザーは更新トークンを提供して新しいアクセストークンを取得する必要があります。この時点で、DBをチェックして、ユーザーが禁止されていることを確認します。したがって、アクセストークンの要求を拒否すると、禁止が有効になります。
可能な答えをショーツ：
リフレッシュトークンは、トークンのスコープ付き/異なる減衰時間を可能にします。実際のリソーストークンは短命ですが、リフレッシュトークンは数年間有効です（モバイルアプリ）。これには、より優れたセキュリティ（リソーストークンを保護する必要がない）とパフォーマンス（更新トークンAPIのみがDBに対して有効性をチェックする必要がある）が付属しています。