Web服務的 SSO 與代理授權的基礎 – OAuth 2.0

Web服務的 SSO 與代理授權的基礎 – OAuth 2.0

這篇文章主要講解 Oauth 2.0

生活中我們常常遇到網頁要求您授權的案例

當使用服務A的時候, 告知您可以用您的Google帳號登入

或是使用服務B的時候, 需要授權存取 Google 相簿等

這些背後的運作就是 Oauth2.0 !

Oauth 2.0 應用場景

服務A 可以用服務B的帳號登入.

這樣一來解決帳號密碼間的問題

服務A 跟服務B 可以不需要同步帳號密碼卻又可以授權存取

這就是 Oauth 的精神, 因此 Oauth 實質上是代理授權不是身任認證

Oauth 實質上是代理授權不是身任認證!

Oauth 實質上是代理授權不是身任認證!

要說三次是因為很多人都認為 Oauth 是身分認證還可以做 SSO

另外一個例子是透過 oauth 2.0讓不同服務之間可以相互存取, 如下

了解幾個 Oauth 的生活案例之後, Oauth 2.0是怎樣實現的呢 ?

Oauth2.0 主要有四種場景

其中以 Authorization Code 與 Implicit Grant 比較常見

場景1: Authorization Code

適用場景: 一般用在兩個 Web 服務間的溝通與授權

Resource owner : 使用者

Client :  Web 服務A (例如 FaceBook)

Authorization Server : Web 服務 B 負責授權 (例如 Google)

Resource Server : Web 服務 B 的相關資源  (例如 Google 相簿)

(通常 Authorization Server = Resource Server)

場景2: Implicit Grant

適用場景: 主要適用在 client 不是 Web 服務形式, 例如 client 端只是簡單的 JAvaScript 使用者使用 Browser 或是 手機 App的方式

主要用在用戶端 client 無法有效保護 Authorization code 的狀況

或是只需要讀取(不需要更新)後端資料的狀況

這個場景可以看得出來少了 Authorization Code直接拿到 Token

另外一個重點是這個模式下 refresh Token 是禁止使用的

場景3: Resource owner Password

適用場景: 這種場景可以猜得出來需要使用者輸入帳號密碼

由於需要透過 Client (或是第三方服務)傳送密碼到另一個服務

因此這個 Client 必須高度可信任

通常來說 Client 與 Authorization/Resource Server

可能是同一家公司的服務, 兩者關係高度可信才會使用這種方式

場景4: Client Credentials

最後一種模式則是不需要使用者介入, 直接透過 client 與後端服務溝通

一般來用在程式本身與後端溝通, 例如統計資訊, 事件日誌, 後台維護等

例如: Google Cloud Storage服務

常見問題

• SAML 2.0 也是 SSO 與 oauth 2.0 是什麼關係?
• SAML 2.0 與 OpenID connect 關係是什麼?
• 哪些是目前與未來的主流?

OAuth2, OpenID, SAML