我目前正在編寫一些程式碼來處理 oAuth（使用 Azure Graph API，但我認為 Google API 是類似的）。
要進行 API 調用，我需要一個存取令牌，該令牌的生命週期約為一小時。要取得存取令牌，我需要先讓使用者授權我的應用程式使用，這會提供一個授權代碼，其生命週期約為十分鐘。在獲得存取令牌的同時，我還可以獲得刷新令牌，其有效期通常為 90 天。儘管如此，我可以在過期之前獲得一個新的刷新令牌，以確保我保留有效的刷新令牌。
因此需要處理三種類型的代碼/令牌。
為什麼需要所有這些不同的代碼和令牌？為什麼不直接提供一個有效期為 90 天的授權碼並使用它呢？
我是否正確地假設，如果我的刷新令牌過期，那麼我必須回到鏈的開頭並再次請求用戶訪問？
答案1
為什麼需要所有這些不同的代碼和令牌？為什麼不直接提供一個有效期為 90 天的授權碼並使用它呢？
授權代碼是提供存取權杖的多種方式之一 - 它不是一個單獨的“步驟”，但仍然是初始“互動式身份驗證”流程的一部分。它與實際存取權杖的不同之處在於，您還需要 OAuth2 用戶端金鑰（或開始時產生的 PKCE 質詢）才能使用代碼。從理論上講，這意味著即使程式碼本身被攔截（例如透過客戶端可見的重定向），也只有原始應用程式可以將其交換為真實令牌。
還有其他流程不使用其中之一 - 例如，您可以使用「隱式授予」流程直接接收存取令牌，或者您可以使用憑證一步進行身份驗證並接收令牌，具體取決於 OAuth 的內容IDP 支援。
（例如，Google 中的「服務帳戶」使用 RSA 金鑰對進行驗證以取得存取權杖 - 它們不使用互動式驗證流程，因此沒有驗證碼。）
我是否正確地假設，如果我的刷新令牌過期，那麼我必須回到鏈的開頭並再次請求用戶訪問？
是的，但避免這種情況實際上是刷新令牌的首要目的。
如果您只有一種類型的令牌（存取權杖），那麼每次它過期時，您都需要回到鏈的開頭。這通常可以透過刷新令牌來避免，刷新令牌通常具有更久，更長生命週期，例如，如果存取令牌的有效期為幾個小時或幾天，那麼刷新令牌的有效期通常為數月或數年。
我想說，刷新令牌的90 天非常短，並且在某種程度上失去了擁有刷新令牌的意義- 我的猜測是Azure OAuth2 是專門以這種方式設置的，以便通過難以竊取的憑據強制重新進行身份驗證，例如作為裝置憑證或自訂 HMAC 方案「Windows Hello」使用。 （相比之下，Google 頒發的刷新令牌似乎幾乎沒有過期時間 - 多年來我一直使用相同的令牌訪問 Gmail IMAP。）
答案2
有不同的類型，因為它們有不同的目的。您擁有它們的一個簡單原因是它們可能會受到損害並用於不同的目的。因此，讓它們短暫存在可以確保不當處理或受損的客戶端雖然仍然很糟糕，但可能會產生較小的影響。
它還有助於區分做什麼。一枚代幣意味著您只需拿到一枚代幣就可以做所有事情。擁有多個代幣會讓你更難獲得執行所有操作的選項。
看RFC 6749有關令牌類型的詳細資訊。