アクセス トークンを取得するには 2 つの方法があります。
考えてみてください！
交換とリフレッシュは言葉は違いますが、やっていることは同じです。
両方のアクションで、クライアント ID とクライアント シークレット (または署名) とトークンを解析する必要があります
認証コードをシステムに保存するだけで、認証コードを使用してトークンの更新と同じようにアクセス トークンを更新できます。
認証コードの有効期限が早すぎることを除いて。
ですから、oauth2 の設計者がこれら 2 つの概念を設計したのに、単一の概念だけを使用したり、承認コードを設計して有効期限を長くしたりしないのはなぜだろうかと思います。
残念ながら、あなたは oauth2 の概念を十分に理解していません。アクセス トークンを取得する方法は 2 つだけではなく、他にもあります。それぞれを基本的に「グラントタイプ」と呼びます。以下に展開したもののユースケースについて説明しています。
1- 認証コード : これは、さまざまな Web サイトで表示される「Facebook でログイン」などのボタンの流れに似ており、Facebook などのアカウントを使用して登録/ログインできます。ここで、このボタンをクリックすると、ユーザーがログイン資格情報を入力する Facebook に制御が向けられます。成功すると、Facebook に開発者として登録するときに入力したリダイレクト URL に認証コードが送信されます。次に、この認証コードを使用してアクセス トークン サービスにリクエストし、Facebook Web サービスにアクセスしてユーザーの詳細を取得するたびに使用するアクセス トークンを取得します。
2- クライアント資格情報 : 独自の Web サービスを実行していて、有効なクライアントにのみアクセスを許可する場合は、これが使用する許可タイプです。たとえば、Web サービスを実行していて、アプリ ストアを通じて配布する独自のネイティブ モバイル アプリでそれを使用したいとします。これにより、アプリをインストールした人だけが Web サービスにアクセスできるようになります。
3- ユーザー資格情報 : 上記と同じですが、この場合のみ、登録済みユーザーを認証し、自分のアカウントなどのユーザー制限サービスへのアクセスを許可します。
4- リフレッシュ トークン : 設計上、アクセス トークン サービスはアクセス トークンとリフレッシュ トークンを提供します。ここで取得した更新トークンを使用して、期限切れのアクセス トークンを更新します。基本的に、これは新しいアクセス トークンを生成せず、既存のトークンを「更新」するだけです。これにより、新しいアクセス トークンとリフレッシュ トークンが提供され、有効期限が延長されます。このアクセス トークンが期限切れになると、前回取得したリフレッシュ トークンを使用して再度リフレッシュ トークンを呼び出し、トークンが期限切れになるたびにプロセスを繰り返します。