SAML和OAuth2這兩種SSO協議的區別
阿新 • • 發佈：2021-01-03
[toc]
# 簡介
SSO是單點登入的簡稱，常用的SSO的協議有兩種，分別是SAML和OAuth2。本文將會介紹兩種協議的不同之處，從而讓讀者對這兩種協議有更加深入的理解。
# SAML
SAML的全稱是Security Assertion Markup Language， 是由OASIS制定的一套基於XML格式的開放標準，用在身份提供者（IdP）和服務提供者 (SP)之間交換身份驗證和授權資料。
SAML的一個非常重要的應用就是基於Web的單點登入（SSO）。
在SAML協議中定義了三個角色，分別是principal：代表主體通常表示人類使用者。identity provider (IdP)身份提供者和service provider (SP)服務提供者。
IdP的作用就是進行身份認證，並且將使用者的認證資訊和授權資訊傳遞給服務提供者。
SP的作用就是進行使用者認證資訊的驗證，並且授權使用者訪問指定的資源資訊。
接下來，我們通過一個用SAML進行SSO認證的流程圖，來分析一下SAML是怎麼工作的。
上圖中User Agent就是web瀏覽器，我們看一下如果使用者想請求Service Provider的資源的時候，SAML協議是怎麼處理的。
1. 使用者通過User Agent請求Service Provider,比如：
~~~java
http://sp.flydean.com/myresource
~~~
SP將會對該資源進行相應的安全檢查，如果發現已經有一個有效的安全上下文的話，SP將會跳過2-7步，直接進入第8步。
2. 如果在第一步的時候，SP並沒有找到相應的有效安全上下文的話，則會生成對應的SAMLRequest，並將User Agent重定向到IdP：
~~~java
302 Redirect
Location: https://idp.flydean.com/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
~~~
RelayState是SP維護的一個狀態資訊，主要用來防止CSRF攻擊。
其中這個SAMLRequest是用Base64編碼的，下面是一個samlp:AuthnRequest的例子：
~~~xml
https://sp.flydean.com/SAML2
~~~
為了安全起見，SAMLRequest還可以使用SP提供的簽名key來進行簽名。
3. User agent將會發送一個get請求到IdP的SSO server :
~~~shell
GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.flydean.com
~~~
IdP收到這個AuthnRequest請求之後，將會進行安全驗證，如果是合法的AuthnRequest，那麼將會展示登入介面。
4. 使用者可以輸入使用者名稱密碼進行登入。登入成功之後，IdP將會返回一個XHTML form：
~~~xml
...
~~~
這個form中包含了SAMLResponse資訊，SAMLResponse中包含了使用者相關的資訊。
同樣的SAMLResponse也是使用Base64進行編碼過的。
~~~xml
https://idp.flydean.com/SAML2
https://idp.flydean.com/SAML2
...
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
https://sp.flydean.com/SAML2
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
~~~
我們可以看到samlp:Response中包含有saml:Assertion資訊。
5. user agent 收到XHTML form之後將會提交該form給SP。
6. SP中的assertion consumer service將會處理這個請求，建立相關的安全上下文，並將user agent重定向到要訪問的資源頁面。
7. user agent再次請求SP資源。
8. 因為安全上下文已經建立完畢，SP可以直接返回相應的資源，不用再次到IdP進行認證。
我們可以看到上面的所有的資訊交換都是由前端瀏覽器來完成的，在SP和IdP之間不存在直接的通訊。
這種全部由前端來完成資訊交換的方式好處就是協議流非常簡單，所有的訊息都是簡單的GET或者POST請求。
如果為了提高安全性，也可以使用引用訊息。也就是說IdP返回的不是直接的SAML assertion，而是一個SAML assertion的引用。SP收到這個引用之後，可以從後臺再去查詢真實的SAML assertion，從而提高了安全性。
## SAML的缺點
SAML協議是2005年制定的，在制定協議的時候基本上是針對於web應用程式來說的，但是那時候的web應用程式還是比較簡單的，更別提對App的支援。
SAML需要通過HTTP Redect和HTTP POST協議來傳遞使用者資訊，並且通常是通過HTML FORM的格式來進行資料的提交的。如果應用程式並不是web應用，比如說是一個手機App應用。
這個手機APP應用的啟動連結是 my-photos://authenticate ， 但是手機app可能並不能獲取到Http POST的body內容。他們只能夠通過URL來進行引數的傳遞。
這就意味著，在手機APP中不能夠使用SAML。
當然，要想工作也可以，不過需要進行一些改造。比如通過第三方應用對POST訊息進行解析，然後將解析出來的SAMLRequest以URL引數的形式傳遞給APP。
另一種方法就是使用OAuth2.
# OAuth2
因為Oauth2是在2012年才產生的。所以並沒有那麼多的使用限制。我們可以在不同的場合中使用OAuth2。
我們先來看一下OAuth2中授權的流程圖：
一般來說OAuth2中有4個角色。
resource owner： 代表的是資源的所有者，可以通過提供使用者名稱密碼或者其他方式來進行授權。通常來是一個人。
resource server：代表的是最終需要訪問到資源的伺服器。比如github授權之後獲取到的使用者資訊。
client： 用來替代resource owner來進行互動的客戶端。
authorization server： 用來進行授權的伺服器，可以生成相應的Access Token。
整個流程是這樣的：
Client向resource owner發起一個授權請求，resource owner輸入相應的認證資訊，將authorization grant返回給client。
client再將獲取到的authorization grant請求授權伺服器，並返回access token。
client然後就可以拿著這個access token去請求resource server，最後獲取到受限資源。
## OAuth2的缺點
OAuth2並沒有指定Resource Server怎麼和Authorization Server進行互動。也沒有規定返回使用者資訊的內容和格式。這些都需要實現方自己去決定。
OAuth2預設是在HTTPS環境下工作的，所以並沒有約定資訊的加密方式。我們需要自己去實現。
最後，OAuth2是一個授權協議，而不是認證協議。對於這個問題，其實我們可以考慮使用OpenID Connect協議。因為OpenID Connect就是基於OAuth2實現的，並且添加了認證協議。
OpenID Connect簡稱為OIDC，已成為Internet上單點登入和身份管理的通用標準。 它在OAuth2上構建了一個身份層，是一個基於OAuth2協議的身份認證標準協議。
OAuth2實際上只做了授權，而OpenID Connect在授權的基礎上又加上了認證。
OIDC的優點是：簡單的基於JSON的身份令牌（JWT），並且完全相容OAuth2協議。
# 兩者的對比
在SAML協議中，SAML token中已經包含了使用者身份資訊，但是在OAuth2，在拿到token之後，需要額外再做一次對該token的校驗。
但是另一方面，OAuth2因為需要再做一次認證，所以可以在 Authorization Server 端對token進行無效處理。
# CAS簡介
做過SSO的應該都聽說過CAS。CAS的全稱是Central Authentication Service，是一個企業級的開源的SSO認證框架。
CAS內部集成了CAS1,2,3，SAML1,2，OAuth2,OpenID和OpenID Connect協議，非常的強大。我們會在後面的文章中介紹CAS的使用。
>