因項(xiàng)目需要关噪，需要和三方的oauth2服務(wù)器進(jìn)行集成署驻。網(wǎng)上關(guān)于spring cloud security oauth2的相關(guān)資料苇侵，一般都是講如何配置站超，而能把這塊原理講透徹的比較少，這邊自己做一下總結(jié)和整理送爸，順帶介紹一下JWT的使用場(chǎng)景铛嘱。

什么是OAuth2？

OAuth2是一個(gè)關(guān)于授權(quán)的開(kāi)放標(biāo)準(zhǔn)袭厂，核心思路是通過(guò)各類認(rèn)證手段（具體什么手段OAuth2不關(guān)心）認(rèn)證用戶身份墨吓，并頒發(fā)token（令牌），使得第三方應(yīng)用可以使用該令牌在限定時(shí)間纹磺、限定范圍訪問(wèn)指定資源帖烘。主要涉及的RFC規(guī)范有RFC6749（整體授權(quán)框架）,RFC6750（令牌使用）,RFC6819（威脅模型）這幾個(gè)，一般我們需要了解的就是RFC6749橄杨。獲取令牌的方式主要有四種秘症，分別是授權(quán)碼模式照卦，簡(jiǎn)單模式，密碼模式和客戶端模式乡摹，如何獲取token不在本篇文章的討論范圍役耕，我們這里假定客戶端已經(jīng)通過(guò)某種方式獲取到了access_token，想了解具體的oauth2授權(quán)步驟可以移步阮一峰老師的理解OAuth 2.0聪廉，里面有非常詳細(xì)的說(shuō)明瞬痘。

這里要先明確幾個(gè)OAuth2中的幾個(gè)重要概念：

• resource owner: 擁有被訪問(wèn)資源的用戶
• user-agent: 一般來(lái)說(shuō)就是瀏覽器
• client: 第三方應(yīng)用
• Authorization server: 認(rèn)證服務(wù)器，用來(lái)進(jìn)行用戶認(rèn)證并頒發(fā)token
• Resource server：資源服務(wù)器板熊，擁有被訪問(wèn)資源的服務(wù)器框全，需要通過(guò)token來(lái)確定是否有權(quán)限訪問(wèn)

明確概念后，就可以看OAuth2的協(xié)議握手流程干签，摘自RFC6749

Abstract Protocol Flow.png

什么是Spring Security津辩？

Spring Security是一套安全框架，可以基于RBAC（基于角色的權(quán)限控制）對(duì)用戶的訪問(wèn)權(quán)限進(jìn)行控制容劳，核心思想是通過(guò)一系列的filter chain來(lái)進(jìn)行攔截過(guò)濾喘沿，以下是ss中默認(rèn)的內(nèi)置過(guò)濾器列表，當(dāng)然你也可以通過(guò)custom-filter來(lái)自定義擴(kuò)展filter chain列表

這里面最核心的就是FILTER_SECURITY_INTERCEPTOR鸭蛙，通過(guò)FilterInvocationSecurityMetadataSource來(lái)進(jìn)行資源權(quán)限的匹配摹恨，AccessDecisionManager來(lái)執(zhí)行訪問(wèn)策略。

認(rèn)證與授權(quán)（Authentication and Authorization）

一般意義來(lái)說(shuō)的應(yīng)用訪問(wèn)安全性娶视，都是圍繞認(rèn)證（Authentication）和授權(quán)（Authorization）這兩個(gè)核心概念來(lái)展開(kāi)的晒哄。即首先需要確定用戶身份，在確定這個(gè)用戶是否有訪問(wèn)指定資源的權(quán)限肪获。認(rèn)證這塊的解決方案很多寝凌，主流的有CAS、SAML2孝赫、OAUTH2等（不巧這幾個(gè)都用過(guò)-_-）较木，我們常說(shuō)的單點(diǎn)登錄方案（SSO）說(shuō)的就是這塊，授權(quán)的話主流的就是spring security和shiro青柄。shiro我沒(méi)用過(guò)伐债，據(jù)說(shuō)是比較輕量級(jí)，相比較而言spring security確實(shí)架構(gòu)比較復(fù)雜致开。

Spring Cloud Security Oauth2認(rèn)證流程

將OAuth2和Spring Security集成峰锁，就可以得到一套完整的安全解決方案。

為了便于理解双戳，現(xiàn)在假設(shè)有一個(gè)名叫“臉盆網(wǎng)”的社交網(wǎng)站虹蒋，用戶在首次登陸時(shí)會(huì)要求導(dǎo)入用戶在facebook的好友列表，以便于快速建立社交關(guān)系。具體的授權(quán)流程如下：

1. 用戶登陸臉盆網(wǎng)魄衅，臉盆網(wǎng)試圖訪問(wèn)facebook上的好友列表
2. 臉盆網(wǎng)發(fā)現(xiàn)該資源是facebook的受保護(hù)資源峭竣，于是返回302將用戶重定向至facebook登陸頁(yè)面
3. 用戶完成認(rèn)證后，facebook提示用戶是否將好友列表資源授權(quán)給臉盆網(wǎng)使用（如果本來(lái)就是已登陸facebook狀態(tài)則直接顯示是否授權(quán)的頁(yè)面）
4. 用戶確認(rèn)后晃虫，臉盆網(wǎng)通過(guò)授權(quán)碼模式獲取了facebook頒發(fā)的access_token
5. 臉盆網(wǎng)攜帶該token訪問(wèn)facebook的獲取用戶接口https://api.facebook.com/user,facebook驗(yàn)證token無(wú)誤后返回了與該token綁定的用戶信息
6. 臉盆網(wǎng)的spring security安全框架根據(jù)返回的用戶信息構(gòu)造出了principal對(duì)象并保存在session中
7. 臉盆網(wǎng)再次攜帶該token訪問(wèn)好友列表皆撩，facebook根據(jù)該token對(duì)應(yīng)的用戶返回該用戶的好友列表信息
8. 該用戶后續(xù)在臉盆網(wǎng)發(fā)起的訪問(wèn)facebook上的資源，只要在token有效期及權(quán)限范圍內(nèi)均可以正常獲劝燎选（比如想訪問(wèn)一下保存在facebook里的相冊(cè)）

不難看出毅访，這個(gè)假設(shè)的場(chǎng)景中，臉盆網(wǎng)就是第三方應(yīng)用（client）盘榨，而facebook既充當(dāng)了認(rèn)證服務(wù)器，又充當(dāng)了資源服務(wù)器蟆融。這個(gè)流程里面有幾個(gè)比較重要的關(guān)鍵點(diǎn)草巡，我需要重點(diǎn)說(shuō)一下，而這也是其他的涉及spring security與OAuth2整合的文章中很少提及的型酥，很容易云里霧里的地方山憨。

細(xì)心的同學(xué)應(yīng)該發(fā)現(xiàn)了，其實(shí)在標(biāo)準(zhǔn)的OAuth2授權(quán)過(guò)程中弥喉，5郁竟、6、8這幾步都不是必須的由境，從上面貼的RFC6749規(guī)范來(lái)看棚亩，只要有1、2虏杰、3讥蟆、4、7這幾步纺阔，就完成了被保護(hù)資源訪問(wèn)的整個(gè)過(guò)程瘸彤。事實(shí)上，RFC6749協(xié)議規(guī)范本身也并不關(guān)心用戶身份的部分笛钝，它只關(guān)心token如何頒發(fā)质况，如何續(xù)簽，如何用token訪問(wèn)被保護(hù)資源（facebook只要保證返回給臉盆網(wǎng)的就是當(dāng)前用戶的好友玻靡，至于當(dāng)前用戶是誰(shuí)臉盆網(wǎng)不需要關(guān)心）结榄。那為什么spring security還要做5、6這兩步呢啃奴？這是因?yàn)閟pring security是一套完整的安全框架潭陪，它必須關(guān)心用戶身份！在實(shí)際的使用場(chǎng)景中，OAuth2一般不僅僅用來(lái)進(jìn)行被保護(hù)資源的訪問(wèn)依溯，還會(huì)被用來(lái)做單點(diǎn)登陸（SSO）老厌。在SSO的場(chǎng)景中，用戶身份無(wú)疑就是核心黎炉，而token本身是不攜帶用戶信息的枝秤，這樣client就沒(méi)法知道認(rèn)證服務(wù)器發(fā)的token到底對(duì)應(yīng)的是哪個(gè)用戶。設(shè)想一下這個(gè)場(chǎng)景慷嗜，臉盆網(wǎng)不想自建用戶體系了淀弹，想直接用facebook的用戶體系，facebook的用戶和臉盆網(wǎng)的用戶一一對(duì)應(yīng)（其實(shí)在很多中小網(wǎng)站現(xiàn)在都是這種模式庆械，可以選擇使用微信薇溃、QQ、微博等網(wǎng)站的用戶直接登陸）缭乘，這種情況下沐序，臉盆網(wǎng)在通過(guò)OAuth2的認(rèn)證后，就希望拿到用戶信息了堕绩。所以現(xiàn)在一般主流的OAuth2認(rèn)證實(shí)現(xiàn)策幼，都會(huì)預(yù)留一個(gè)用戶信息獲取接口，就是上面提到的https://api.facebook.com/user(雖然這不是OAuth2授權(quán)流程中必須的)奴紧，這樣client在拿到token后特姐，就可以攜帶token通過(guò)這個(gè)接口獲取用戶信息，完成SSO的整個(gè)過(guò)程黍氮。另外從用戶體驗(yàn)的角度來(lái)說(shuō)唐含，如果獲取不到用戶信息，則意味者每次要從臉盆網(wǎng)訪問(wèn)facebook的資源滤钱，都需要重定向一次進(jìn)行認(rèn)證觉壶，用戶體驗(yàn)也不好。

OAuth2與SSO

首先要明確一點(diǎn)件缸，OAuth2并不是一個(gè)SSO框架铜靶，但可以實(shí)現(xiàn)SSO功能。以下是一個(gè)使用github作為OAuth2認(rèn)證服務(wù)器的配置文件

server:
  port: 11001
security:
  user:
    password: user  # 直接登錄時(shí)的密碼
  ignored: /
  sessions: never   # session策略
  oauth2:
    sso:
      loginPath: /login   # 登錄路徑
    client:
      clientId: c40fb56cb4sdsdsdsd
      clientSecret: c910ec22981daa28e1b59c778sdfjh73j3
      accessTokenUri: https://github.com/login/oauth/access_token
      userAuthorizationUri: https://github.com/login/oauth/authorize
    resource:
      userInfoUri: https://api.github.com/user
      preferTokenInfo: false

可以看到accessTokenUri和userAuthorizationUri都是為了完成OAuth2的授權(quán)流程所必須的配置他炊，而userInfoUri則是spring security框架為了完成SSO所必須要的争剿。所以總結(jié)一下就是：通過(guò)將用戶信息這個(gè)資源設(shè)置為被保護(hù)資源，可以使用OAuth2技術(shù)實(shí)現(xiàn)單點(diǎn)登陸（SSO）痊末，而Spring Security OAuth2就是這種OAuth2 SSO方案的一個(gè)實(shí)現(xiàn)蚕苇。

Spring Security在調(diào)用user接口成功后，會(huì)構(gòu)造一個(gè)OAuth2Authentication對(duì)象凿叠，這個(gè)對(duì)象是我們通常使用的UsernamePasswordAuthenticationToken對(duì)象的一個(gè)超集涩笤，里面封裝了一個(gè)標(biāo)準(zhǔn)的UsernamePasswordAuthenticationToken嚼吞，同時(shí)在detail中還攜帶了OAuth2認(rèn)證中需要用到的一些關(guān)鍵信息（比如tokenValue，tokenType等）蹬碧，這時(shí)候就完成了SSO的登陸認(rèn)證過(guò)程舱禽。后續(xù)用戶如果再想訪問(wèn)被保護(hù)資源，spring security只需要從principal中取出這個(gè)用戶的token恩沽，再去訪問(wèn)資源服務(wù)器就行了誊稚，而不需要每次進(jìn)行用戶授權(quán)。這里要注意的一點(diǎn)是此時(shí)瀏覽器與client之間仍然是通過(guò)傳統(tǒng)的cookie-session機(jī)制來(lái)保持會(huì)話罗心，而非通過(guò)token里伯。實(shí)際上在SSO的過(guò)程中，使用到token訪問(wèn)的只有client與resource server之間獲取user信息那一次渤闷，token的信息是保存在client的session中的疾瓮，而不是在用戶本地。這也是之前我沒(méi)搞清楚的地方飒箭，以為瀏覽器和client之間也是使用token爷贫，繞了不少?gòu)澛罚瑢?duì)于Spring Security來(lái)說(shuō)补憾，不管是用cas、saml2還是Oauth2來(lái)實(shí)現(xiàn)SSO卷员，最后和用戶建立會(huì)話保持的方式都是一樣的盈匾。

OAuth2 SSO與CAS、SAML2的比較

根據(jù)前面所說(shuō)毕骡，大家不難看出削饵，OAuth2的SSO方案和CAS、SAML2這樣的純SSO框架是有本質(zhì)區(qū)別的未巫。在CAS和SAML2中窿撬，沒(méi)有資源服務(wù)器的概念，只有認(rèn)證客戶端（需要驗(yàn)證客戶信息的應(yīng)用）和認(rèn)證服務(wù)器（提供認(rèn)證服務(wù)的應(yīng)用）的概念叙凡。在CAS中這叫做cas-client和cas-server劈伴，SAML2中這叫做Service Providers和Identity Provider，可以看出CAS握爷、SAML2規(guī)范天生就是為SSO設(shè)計(jì)的跛璧，在報(bào)文結(jié)構(gòu)上都考慮到了用戶信息的問(wèn)題（SAML2規(guī)范甚至還帶了權(quán)限信息），而OAuth2本身不是專門(mén)為SSO設(shè)計(jì)的新啼，主要是為了解決資源第三方授權(quán)訪問(wèn)的問(wèn)題追城，所以在用戶信息方面，還需要額外提供一個(gè)接口燥撞。

Authorization Server與Resource Server分離

臉盆網(wǎng)的這個(gè)例子中座柱，我們看到資源服務(wù)器和認(rèn)證服務(wù)器是在一起的（都是facebook）兔院，在互聯(lián)網(wǎng)場(chǎng)景下一般你很難找到一個(gè)獨(dú)立的、權(quán)威的江锨、第三方的認(rèn)證中心（你很難想像騰訊的QQ空間通過(guò)支付寶的認(rèn)證中心去授權(quán)评也，也很難想像使用谷歌服務(wù)要通過(guò)亞馬遜去授權(quán)）。但是如果是在公司內(nèi)部锋玲，這種場(chǎng)景其實(shí)是很多的景用，尤其在微服務(wù)架構(gòu)下，有大量服務(wù)會(huì)對(duì)外提供資源訪問(wèn)惭蹂，他們都需要做權(quán)限控制伞插。那么最合理的當(dāng)然就是建立一個(gè)統(tǒng)一的認(rèn)證中心，而不是每個(gè)服務(wù)都做一個(gè)認(rèn)證中心盾碗。我們前面也介紹了媚污，token本身是不攜帶用戶信息的，在分離后resouce server在收到請(qǐng)求后廷雅，如何檢驗(yàn)token的真實(shí)性耗美？又如何從token中獲取對(duì)應(yīng)的用戶信息？這部分的介紹網(wǎng)上其實(shí)非常少航缀，幸好我們可以直接從官方文檔獲取相關(guān)的蛛絲馬跡商架，官方文檔對(duì)于resouce server的配置是這樣描述的：

security:
  oauth2:
    resource:
      userInfoUri: https://api.github.com/user
      preferTokenInfo: false

寥寥數(shù)語(yǔ)，但已經(jīng)足夠我們分析了芥玉。從這個(gè)配置可以看出蛇摸，client在訪問(wèn)resource server的被保護(hù)資源時(shí)，如果沒(méi)有攜帶token灿巧，則資源服務(wù)器直接返回一個(gè)401未認(rèn)證的錯(cuò)誤

<oauth>
   <error_description>
      Full authentication is required to access this resource
   </error_description>
   <error>unauthorized</error>
</oauth>

如果攜帶了token赶袄，則資源服務(wù)器會(huì)使用這個(gè)token向認(rèn)證服務(wù)器發(fā)起一個(gè)用戶查詢的請(qǐng)求，若token錯(cuò)誤或已經(jīng)失效抠藕，則會(huì)返回

<oauth>
  <error_description>49e2c7d8720738cfb75f6b675d62e5ecd66</error_description>
  <error>invalid_token</error>
</oauth>

若token驗(yàn)證成功饿肺，則認(rèn)證服務(wù)器向資源服務(wù)器返回對(duì)應(yīng)的用戶信息，此時(shí)resource server的spring security安全框架就可以按照標(biāo)準(zhǔn)的授權(quán)流程進(jìn)行訪問(wèn)權(quán)限控制了盾似。

認(rèn)證與授權(quán)的解耦

從這個(gè)流程中我們可以看出敬辣，通過(guò)OAuth2進(jìn)行SSO認(rèn)證，有一個(gè)好處是做到了認(rèn)證與授權(quán)的解耦颜说。從日常的使用場(chǎng)景來(lái)說(shuō)购岗，認(rèn)證比較容易做到統(tǒng)一和抽象，畢竟你就是你门粪，走到哪里都是你喊积，但是你在不同系統(tǒng)里面的角色，卻可能千差萬(wàn)別（家里你是父親玄妈，單位里你是員工乾吻，父母那里你是子女）髓梅。同時(shí)角色的設(shè)計(jì)，又是和資源服務(wù)器的設(shè)計(jì)強(qiáng)相關(guān)的绎签。從前面的配置中不難發(fā)現(xiàn)枯饿，如果希望獲得為不同資源服務(wù)器設(shè)計(jì)的角色，你只需要替換https://api.facebook.com/user這個(gè)配置就行了诡必，這為我們的權(quán)限控制帶來(lái)了更大的靈活性奢方，而這是傳統(tǒng)的比如SAML2這樣的SSO框架做不到的。

JWT介紹

終于來(lái)到了著名的JWT部分了爸舒，JWT全稱為Json Web Token蟋字，最近隨著微服務(wù)架構(gòu)的流行而越來(lái)越火，號(hào)稱新一代的認(rèn)證技術(shù)扭勉。今天我們就來(lái)看一下鹊奖，jwt的本質(zhì)到底是什么。

我們先來(lái)看一下OAuth2的token技術(shù)有沒(méi)有什么痛點(diǎn)涂炎，相信從之前的介紹中你也發(fā)現(xiàn)了忠聚，token技術(shù)最大的問(wèn)題是不攜帶用戶信息，且資源服務(wù)器無(wú)法進(jìn)行本地驗(yàn)證唱捣，每次對(duì)于資源的訪問(wèn)两蟀，資源服務(wù)器都需要向認(rèn)證服務(wù)器發(fā)起請(qǐng)求，一是驗(yàn)證token的有效性震缭，二是獲取token對(duì)應(yīng)的用戶信息垫竞。如果有大量的此類請(qǐng)求，無(wú)疑處理效率是很低的蛀序，且認(rèn)證服務(wù)器會(huì)變成一個(gè)中心節(jié)點(diǎn)，對(duì)于SLA和處理性能等均有很高的要求活烙，這在分布式架構(gòu)下是很要命的徐裸。

JWT就是在這樣的背景下誕生的，從本質(zhì)上來(lái)說(shuō)啸盏，jwt就是一種特殊格式的token重贺。普通的oauth2頒發(fā)的就是一串隨機(jī)hash字符串，本身無(wú)意義回懦，而jwt格式的token是有特定含義的气笙，分為三部分：

• 頭部Header
• 載荷Payload
• 簽名Signature

這三部分均用base64進(jìn)行編碼，當(dāng)中用.進(jìn)行分隔怯晕，一個(gè)典型的jwt格式的token類似xxxxx.yyyyy.zzzzz潜圃。關(guān)于jwt格式的更多具體說(shuō)明，不是本文討論的重點(diǎn)舟茶，大家可以直接去官網(wǎng)查看官方文檔谭期，這里不過(guò)多贅述堵第。

相信看到簽名大家都很熟悉了，沒(méi)錯(cuò)隧出，jwt其實(shí)并不是什么高深莫測(cè)的技術(shù)踏志，相反非常簡(jiǎn)單。認(rèn)證服務(wù)器通過(guò)對(duì)稱或非對(duì)稱的加密方式利用payload生成signature胀瞪，并在header中申明簽名方式针余，僅此而已。通過(guò)這種本質(zhì)上極其傳統(tǒng)的方式凄诞，jwt可以實(shí)現(xiàn)分布式的token驗(yàn)證功能圆雁，即資源服務(wù)器通過(guò)事先維護(hù)好的對(duì)稱或者非對(duì)稱密鑰（非對(duì)稱的話就是認(rèn)證服務(wù)器提供的公鑰），直接在本地驗(yàn)證token幔摸，這種去中心化的驗(yàn)證機(jī)制無(wú)疑很對(duì)現(xiàn)在分布式架構(gòu)的胃口摸柄。jwt相對(duì)于傳統(tǒng)的token來(lái)說(shuō)，解決以下兩個(gè)痛點(diǎn)：

• 通過(guò)驗(yàn)證簽名既忆，token的驗(yàn)證可以直接在本地完成驱负，不需要連接認(rèn)證服務(wù)器
• 在payload中可以定義用戶相關(guān)信息，這樣就輕松實(shí)現(xiàn)了token和用戶信息的綁定

在上面的那個(gè)資源服務(wù)器和認(rèn)證服務(wù)器分離的例子中患雇，如果認(rèn)證服務(wù)器頒發(fā)的是jwt格式的token跃脊，那么資源服務(wù)器就可以直接自己驗(yàn)證token的有效性并綁定用戶，這無(wú)疑大大提升了處理效率且減少了單點(diǎn)隱患苛吱。

JWT適用場(chǎng)景與不適用場(chǎng)景

就像布魯克斯在《人月神話》中所說(shuō)的名言一樣：“沒(méi)有銀彈”酪术。JWT的使用上現(xiàn)在也有一種誤區(qū)，認(rèn)為傳統(tǒng)的認(rèn)證方式都應(yīng)該被jwt取代翠储。事實(shí)上绘雁，jwt也不能解決一切問(wèn)題，它也有適用場(chǎng)景和不適用場(chǎng)景援所。

適用場(chǎng)景：

• 一次性的身份認(rèn)證
• api的鑒權(quán)

這些場(chǎng)景能充分發(fā)揮jwt無(wú)狀態(tài)以及分布式驗(yàn)證的優(yōu)勢(shì)

不適用的場(chǎng)景：

• 傳統(tǒng)的基于session的用戶會(huì)話保持

不要試圖用jwt去代替session庐舟。這種模式下其實(shí)傳統(tǒng)的session+cookie機(jī)制工作的更好，jwt因?yàn)槠錈o(wú)狀態(tài)和分布式住拭，事實(shí)上只要在有效期內(nèi)挪略，是無(wú)法作廢的，用戶的簽退更多是一個(gè)客戶端的簽退滔岳，服務(wù)端token仍然有效杠娱，你只要使用這個(gè)token，仍然可以登陸系統(tǒng)谱煤。另外一個(gè)問(wèn)題是續(xù)簽問(wèn)題摊求，使用token，無(wú)疑令續(xù)簽變得十分麻煩刘离，當(dāng)然你也可以通過(guò)redis去記錄token狀態(tài)睹簇，并在用戶訪問(wèn)后更新這個(gè)狀態(tài)奏赘，但這就是硬生生把jwt的無(wú)狀態(tài)搞成有狀態(tài)了，而這些在傳統(tǒng)的session+cookie機(jī)制中都是不需要去考慮的太惠。這種場(chǎng)景下磨淌，考慮高可用，我更加推薦采用分布式的session機(jī)制凿渊，現(xiàn)在已經(jīng)有很多的成熟框架可供選擇了（比如spring session）梁只。