Hydra 是一個 OAuth 2.0 授權服務，同時也是 OpenID Connect 服務提供者。有些人會誤以為這兩個服務的職責，是要保存使用者資料，並讓使用者登入。事實上，它們的任務是把使用者的憑證，轉換成 Access Token 或 ID Token。這有點像在使用 cookie 儲存 session 資訊一樣，但它使用的方法更加有彈性，同時也適合用在第三方應用程式授權與身分驗證。

Login Flow 與 Consent Flow

Hydra 的設計是不存放使用者相關資料，如帳號、密碼、或個人資料等，這些資料是放在其他身分驗證或資料庫服務裡。Hydra 只有存放身分驗證與授權的記錄，並使用 Login Flow 與 Consent Flow 的流程，來跟這些服務整合。這個流程會使用 HTTP 轉導機制將瀏覽器轉導至 Login Provider 與 Consent Provider。這兩個 provider 是可以完全客製化的，它們可以是既有服務也可以是重寫新的程式。

概觀而言，這兩個服務的職責如下：

• Login Provider 對使用者做身分驗證，並驗證使用者輸入的帳號或密碼是否正確。
• Consent Provider 是使用者同意授權，使用者能決定應用程式最終拿到的 Token 具有什麼樣的權限。

OAuth 2.0 Scope 與 Access Control 的誤區

剛學 OAuth 2.0 時，可能會把 Scope 與一般的存取控制，如 RBAC（Role Based Access Control）或 ACL（Access Control Lists）搞混。

系統內部所實作的存取控制，是在限制使用者能夠在系統上做什麼事。比方說系統管理員有所有的權限，而一般使用者只能存取個人資訊。

相對的，Scope 並不是在描述使用者能在系統做什麼事。Scope 在說的是使用者允許應用程式能夠代表使用者的身分存取到哪些資源。比方說，使用者可以授權應用程式讀取使用者的照片，但不允許應用程式代表使用者上傳照片。所以 OAuth 2.0 Scope 表達的並不是使用者權限，它表達的是應用程式可以代表使用者做哪些事。

Login 與 Consent 是 Hydra 兩個最重要的部分。下面將會介紹如何把現有的會員系統跟 Hydra 整合，這樣就能成為 OAuth 2.0 與 OpenID Connect 的服務提供者，就像 Google、Facebook 一樣。

Login Flow 與 Consent Flow 流程

前面已概述了 Hydra 的任務，這裡將會說明 Login Flow 與 Consent Flow 流程的細節。這個流程會執行一連串的轉導，包括 Login Provider 使用者身分驗證，再到 Consent Provider 授權。這兩個 Provider 都將由開發者自由實作。比方說使用 NodeJS 實作可以接 /login 與 /consent 的 HTTP Server，就能當作是 Login Provdier 與 Consent Provider 了。

先來看循序圖：

細節如下：

1. 首先應用程式要啟動 OpenID Connect 流程，實務上的做法是把使用者轉導到 http://hydra/oauth2/auth 這個端點。
2. Hydra 如果發現使用者尚未驗證的話（也就是沒有任何 session 或 cookie），會把使用者轉導到 Login Provider。上面有提過，Login Provider 將由開發者自行實作，這裡的任務就是呈現登入介面給使用者，如帳密輸入的頁面。這時候的 URL 會類似像這樣：http://login-provider/login?login_challenge=1234...。
3. Login Provider 的任務就是處理登入流程。登入成功後，要把使用者的資訊（如 user ID）傳送給 Hydra。接著再轉導回 Hydra：http://hydra/oauth2/auth?client_id=...&...&login_verifier=4321。
4. 回到 Hydra 後，Hydra 確認完請求會再把使用者轉導至 Consent Provider，如：http://consent-service/consent?consent_challenge=4567...。
5. Consent Provider 將會顯示應用程式想要求使用者授權哪些權限（也就是 Scope）的介面。Consent Provider 在使用者完成授權時，會發出另一個請求給 Hydra，讓 Hydra 知道 Scope 有哪些。接著再轉導回 Hydra：http://hydra/oauth2/auth?client_id=...&...&consent_verifier=7654...。
6. 回到 Hydra 後，與 Login 的流程類似，Hydra 會確認請求內容才會進行下一步。
7. 確認接著再依 Hydra 的轉導，回到應用程式。到了這一步，使用者已完成身分驗證與授權，最後應用程式即可從授權回應或身分驗證回應裡取得 token 相關的資訊（如 Authorization Code）。

第 1 步是應用程式發送身分驗證請求，啟動 Hydra 登入與授權流程，第 7 步則是建立身分驗證回應，回傳給應用程式。

中間 Hydra 作為控制流程的核心，它會決定瀏覽器要轉導至 Login Provider 或是 Consent Provide ，或是完成整個流程並導回應用程式。在這個設計下，開發者能夠對身分驗證和授權的行為，有更完整的控制，像身分驗證就能夠輕易的在第 3 步的 Login Provider 上實作多因子驗證。

明天將會來準備這些 Provider，並且跟 Hydra 登入和授權流程整合。