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

    Image result for oauth2 logo

    這篇文章主要講解 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讓不同服務之間可以相互存取, 如下

    Image result for oauth2 應用

    了解幾個 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)

    Authorization Code Grant Flow

    場景2: Implicit Grant

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

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

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

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

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

    Implicit Grant Flow

    場景3: Resource owner Password

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

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

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

    通常來說 Client 與 Authorization/Resource Server

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

    Resource Owner Password Credentials Grant Flow

    場景4: Client Credentials

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

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

    例如: Google Cloud Storage服務

    Client Credentials Grant Flow

    常見問題

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

    OAuth2, OpenID, SAML

    OAuth2
    OpenId
    SAML
    Token (or assertion) format
    JSON or SAML2
    JSON
    XML
    Authorization?
    Yes
    No
    Yes
    Authentication?
    Pseudo-authentication
    Yes
    Yes
    Year created
    2005
    2006
    2001
    Current version
    OAuth2
    OpenID Connect
    SAML 2.0
    Transport
    HTTP
    HTTP GET and HTTP POST
    HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and others
    Security Risks
    Phishing
    OAuth 2.0 does not support signature, encryption, channel binding, or client verification.  Instead, it relies completely on TLS for confidentiality.
    Phishing
    Identity providers have a log of OpenID logins, making a compromised account a bigger privacy breach
    XML Signature Wrapping to impersonate any user
    Best suited for
    API authorization
    Single sign-on for consumer apps
    Single sign-on for enterprise
    Note:  not well suited for mobile

    Posted by Tony @ 8:34 pm

  • Leave a Reply

    Your email address will not be published.