本系列文之後也會置於個人網站

終於要來談談OAuth裡定義的細節了～

目前OAuth 2.0 一共定義了7種流程(flow)。在未來本系列可能稱之爲模式，不同模式適用於不同情況、不同環境。就是因爲如此，OAuth才有高彈性的優勢。

OAuth 2.0 的可擴展性和模塊化是其最大的優勢之一,因為這使得該協議適用於各種環境。然而,正是這種靈活性導致不同的實現之間存在基本的相容性問題。當開發人員想在不同的系統上實現 OAuth 時,它提供的眾多自定義選項容易使人困惑。

本系列會介紹的模式包含：

1. Password Grant (密碼模式)
2. Implicit (隱含模式)
3. Authorization Code (Code模式)
4. Refresh Token
5. Client Credentials (特殊密碼模式)
6. PKCE
7. Device Code

儘管 Implicit 和 Password Grant 被標記爲傳奇的(Legacy)，但有時候仍然可能會使用到。重要的是你應該知道什麼情況應該使用什麼模式。同時記住，即使一個系統按照規範正確地實現了 OAuth,也不意味著該系統在實踐中就是安全的。

「OAuth 2.0 實戰」有一章決策圖可以幫助你決定使用什麼模式。但本系列應該不會提供。

參考資料

• OAuth 2.0 實戰
• RFC6749
• RFC7636
• RFC8628