OAuth で異なるトークンタイプが存在する理由

Question 1

なぜこれらすべての異なるコードとトークンが必要なのでしょうか? 有効期間が 90 日間の認証コードを提供してそれで済ませないのはなぜでしょうか?

認証コードは、アクセストークンを配信するいくつかの方法の 1 つです。これは、別の「ステップ」ではなく、初期の「対話型認証」フローの一部です。コードを使用するには、OAuth2 クライアントシークレット (または最初に生成された PKCE チャレンジ) も必要になるという点で、実際のアクセストークンとは異なります。理論上、これは、コード自体が傍受された場合でも (たとえば、クライアント側でリダイレクトが見えるなど)、元のアプリだけがそれを実際のトークンと交換できることを意味します。

トークンを使用しないフローもあります。たとえば、「暗黙の付与」フローを使用してアクセストークンを直接受信したり、OAuth IDP のサポート内容に応じて、証明書を使用して 1 つの手順で認証してトークンを受信したりすることができます。

(たとえば、Google の「サービスアカウント」は、アクセストークンを取得するために RSA キーペアを使用して認証します。対話型認証フローは使用しないため、認証コードはありません。)

リフレッシュトークンの有効期限が切れた場合は、チェーンの最初に戻ってユーザーに再度アクセスを要求する必要があると考えてよいですか?

はい、しかし、そもそもそれを回避することがリフレッシュトークンの目的です。

トークンの種類が1種類（アクセストークン）しかない場合、有効期限が切れるたびにチェーンの先頭に戻る必要があります。これは通常、リフレッシュトークンを使用することで回避できます。リフレッシュトークンには、通常、もっと長く有効期間。たとえば、アクセストークンが数時間または数日間有効な場合、リフレッシュトークンは数か月または数年間有効になるのが一般的です。

リフレッシュトークンの有効期間が 90 日というのは異常に短く、ある意味、リフレッシュトークンを持つ意味を失っていると思います。私の推測では、Azure OAuth2 は、デバイス証明書や「Windows Hello」が使用するカスタム HMAC スキームなど、盗みにくい資格情報を使用して再認証を強制するために、そのように特別に設定されているのだと思います。(対照的に、Google が発行するリフレッシュトークンには、実質的に有効期限がないようです。私は何年も同じトークンを使用して Gmail IMAP にアクセスしています。)

Answer