//資源和認證服務器不相同
http://xxxx:8080/flowAuth/oauth/authorize?client_id=jerry&redirect_uri=http%3a%2f%2fxxxx%3a8080%2fAuthProvider%2ftest%2findex.do&response_type=code&scope=read
//資源和認證服務器相同
http://xxxx:8080/flowAuth/oauth/authorize?client_id=fuck&redirect_uri=http%3a%2f%2fxxxx%3a8080%2fflowAuth%2ftest%2fcc.do&response_type=code&scope=read
http://xxxx:8080/flowAuth/oauth/authorize?client_id=fuck&redirect_uri=http%3a%2f%2fxxxx%3a8080%2fflowAuth%2ftest%2findex.do&response_type=code&scope=read
//密碼模式認證
http://xxxx:8080/flowAuth/oauth/authorize?username=Miki&password=123456&grant_type=password&scope=read&client_id=fuck&redirect_uri=http%3a%2f%2fxxxx%3a8080%2fflowAuth%2ftest%2findex.do&response_type=code
//獲取access_token
http://xxxx:8080/flowAuth/oauth/token?client_id=jerry&client_secret=1111&grant_type=authorization_code&code=FlmXb7&redirect_uri=http%3a%2f%2fxxxx%3a8080%2fflowAuth%2ftest%2findex.do
{
"access_token":"3e85af06-245e-433f-a533-400dccba6b12",
"token_type":"bearer",
"refresh_token":"58f4dabb-8c54-4cdd-af36-b87d64eeda94",
"expires_in":43199,
"scope":"read"
}
獲取access_token後訪問資源 [POST]
http://xxxx:8080/flowAuth/test/index.do?access_token=cd105a0e-506f-4696-ab6c-0ad59afe3bfa
Authorities:資源
//刷新access_token
http://xxxx:8080/flowAuth/oauth/token?client_id=fuck&client_secret=2222&grant_type=refresh_token&refresh_token=4f6d41ba-7170-4160-84c9-e59c9210b304
第三方如你需要下載csdn上的資源，不想注冊，那麼可以調用qq oauth接口登錄，此時，csdn是第三方客戶端，qq是服務器，資源的提供端，調用qq ouath接口,服務器端創建token
和相應秘鑰，將用戶重定向到用戶確認界面，詢問是否確認授權，用戶同意，重定向到第三方客戶端，客戶端用返回的token請求服務器端，獲取access_token和秘鑰，及用戶信息。
<!--一個自定義的filter，必須包含 authenticationManager,accessDecisionManager,securityMetadataSource三個屬性-->
客戶端對象重要的屬性有：
clientId：（必須）客戶端id。
secret：（對於可信任的客戶端是必須的）客戶端的私密信息。
scope：客戶端的作用域。如果scope未定義或者為空（默認值），則客戶端作用域不受限制。
authorizedGrantTypes：授權給客戶端使用的權限類型。默認值為空。
authorities：授權給客戶端的權限（Spring普通的安全權限）。
OAuth的參與實體至少有如下三個：
· RO (resource owner): 資源所有者，對資源具有授權能力的人.
· RS (resource server): 資源服務器，它存儲資源，並處理對資源的訪問請求。
· Client: 第三方應用，它獲得RO的授權後便可以去訪問RO的資源。
此外，為了支持開放授權功能以及更好地描述開放授權協議，OAuth引入了第四個參與實體：
· AS (authorization server): 授權服務器，它認證RO的身份，為RO提供授權審批流程，並最終頒發授權令牌(Access Token)。
協議的基本流程如下：
(1) Client請求RO的授權，請求中一般包含：要訪問的資源路徑，操作類型，Client的身份等信息。
(2) RO批准授權，並將“授權證據”發送給Client。至於RO如何批准，這個是協議之外的事情。典型的做法是，AS提供授權審批界面，讓RO顯式批准。這個可以參考下一節實例化分析中的描述。
(3) Client向AS請求“訪問令牌(Access Token)”。此時，Client需向AS提供RO的“授權證據”，以及Client自己身份的憑證。
(4) AS驗證通過後，向Client返回“訪問令牌”。訪問令牌也有多種類型，若為bearer類型，那麼誰持有訪問令牌，誰就能訪問資源。
(5) Client攜帶“訪問令牌”訪問RS上的資源。在令牌的有效期內，Client可以多次攜帶令牌去訪問資源。
(6) RS驗證令牌的有效性，比如是否偽造、是否越權、是否過期，驗證通過後，才能提供服務。
授權碼類型的開放授權協議流程描述如下：
(1) Client初始化協議的執行流程。首先通過HTTP 302來重定向RO用戶代理到AS。Client在redirect_uri中應包含如下參數：client_id, scope (描述被訪問的資源), redirect_uri (即Client的URI), state (用於抵制CSRF攻擊). 此外，請求中還可以包含access_type和approval_prompt參數。當approval_prompt=force時，AS將提供交互 頁面，要求RO必須顯式地批准（或拒絕）Client的此次請求。如果沒有approval_prompt參數，則默認為RO批准此次請求。當 access_type=offline時，AS將在頒發access_token時，同時還會頒發一個refresh_token。因為 access_token的有效期較短（如3600秒），為了優化協議執行流程，offline方式將允許Client直接持refresh_token 來換取一個新的access_token。
(2) AS認證RO身份，並提供頁面供RO決定是否批准或拒絕Client的此次請求（當approval_prompt=force時）。
(3) 若請求被批准，AS使用步驟(1)中Client提供的redirect_uri重定向RO用戶代理到Client。redirect_uri須包含 authorization_code，以及步驟1中Client提供的state。若請求被拒絕，AS將通過redirect_uri返回相應的錯誤信 息。
(4) Client拿authorization_code去訪問AS以交換所需的access_token。Client請求信息中應包含用於認證Client身份所需的認證數據，以及上一步請求authorization_code時所用的redirect_uri。
(5) AS在收到authorization_code時需要驗證Client的身份，並驗證收到的redirect_uri與第3步請求authorization_code時所使用的redirect_uri相匹配。如果驗證通過，AS將返回access_token，以及refresh_token（若access_type=offline）。
多個<intercept-url>元素為不同URL的集合定義不同的訪問需求，它們會被歸入一個有序隊列中，每次取出最先匹配的一個元素使用。
一個http的配置對應一個資源,http可以配置一組action,http標簽的url-pattern屬性配置url資源，也可以使用通配
符配置一組資源
<authentication-manager>
<authentication-provider>
<user-service>
<user name="admin" password="admin" authorities="ROLE_USER, ROLE_ADMIN" />4
<user name="user" password="user" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>
authorities屬性，這裡定義了這個用戶登陸之後將會擁有的權限,它與上面intercept-url中定義的權限內容一一對
應。每個用戶可以同時擁有多個權限
框架自己提供的URL路徑是/oauth/authorize（授權端），/oauth/token (令牌端)，/oauth/confirm_access (用戶發送確認授權到這裡)，還有/oauth/error (用戶呈現授權服務器授權出錯的請求)。
authorizedGrantTypes：授權給客戶端使用的權限類型。默認值為空。
token - tokenService
client - clientDetailService
user - userDetailsService
Spring Security已經定義了一些Filter，不管實際應用中你用到了哪些，它們應當保持如下順序。
（1）ChannelProcessingFilter，如果你訪問的channel錯了，那首先就會在channel之間進行跳轉，如http變為https。
（2）SecurityContextPersistenceFilter，這樣的話在一開始進行request的時候就可以在SecurityContextHolder中建立一個SecurityContext，然後在請求結束的時候，任何對SecurityContext的改變都可以被copy到HttpSession。
（3）ConcurrentSessionFilter，因為它需要使用SecurityContextHolder的功能，而且更新對應session的最後更新時間，以及通過SessionRegistry獲取當前的SessionInformation以檢查當前的session是否已經過期，過期則會調用LogoutHandler。
（4）認證處理機制，如UsernamePasswordAuthenticationFilter，CasAuthenticationFilter，BasicAuthenticationFilter等，以至於SecurityContextHolder可以被更新為包含一個有效的Authentication請求。
（5）SecurityContextHolderAwareRequestFilter，它將會把HttpServletRequest封裝成一個繼承自HttpServletRequestWrapper的SecurityContextHolderAwareRequestWrapper，同時使用SecurityContext實現了HttpServletRequest中與安全相關的方法。
（6）JaasApiIntegrationFilter，如果SecurityContextHolder中擁有的Authentication是一個JaasAuthenticationToken，那麼該Filter將使用包含在JaasAuthenticationToken中的Subject繼續執行FilterChain。
（7）RememberMeAuthenticationFilter，如果之前的認證處理機制沒有更新SecurityContextHolder，並且用戶請求包含了一個Remember-Me對應的cookie，那麼一個對應的Authentication將會設給SecurityContextHolder。
（8）AnonymousAuthenticationFilter，如果之前的認證機制都沒有更新SecurityContextHolder擁有的Authentication，那麼一個AnonymousAuthenticationToken將會設給SecurityContextHolder。
（9）ExceptionTransactionFilter，用於處理在FilterChain范圍內拋出的AccessDeniedException和AuthenticationException，並把它們轉換為對應的Http錯誤碼返回或者對應的頁面。
（10）FilterSecurityInterceptor，保護Web URI，並且在訪問被拒絕時拋出異常。
引到用戶到地址"oauth/authorize" 如果用戶同意 跳轉至回調uri+code=CODE
發起換取access_token的請求
1.獲得授權碼(code/token)
2.獲取accesstoken
3.通過accesstoken,獲取OpenID
4.通過OpenID和accesstoken調用API,獲取獲取用戶信息
OAuth2.0中目前有四種授權類型：Authorization Code,implicit,password,client credentials
oauth2.0的基本流,
1.請求用戶授權,
2.獲取code,
3.獲取token,
4.請求資源驗證token.
因此,只需要關注
WebServerOAuth2Filter,
BasicUserApprovalFilter,
OAuth2AuthorizationFilter,
OAuth2ProtectedResourceFilter,
其中WebServerOAuth2Filter是/oauth/user/authorize入口,驗證code無效,unapprovedAuthenticationHandler跳轉到/oauth/confirm_access,用戶提交之後 BasicUserApprovalFilter攔截之後,獲取授權參數,就交給 WebServerOAuth2Filter獲取code,獲取code返回到client,然後client再次請求 /oauth/authorize,OAuth2AuthorizationFilter獲取token,之後只要請求的時候帶上token由 OAuth2ProtectedResourceFilter負責驗證,是否可獲取用戶資源.
處理認證請求("/aouth/authorize")的類:AuthorizationEndpoint
標簽 <authorization-server></authorization-server> 的屬性名列表
authorization-code
implicit
refresh-token
client-credentials
password
custom-grant
client-details-service-ref
toen-endpoint-url
authorization-endpoint-url
token-granter-ref
token-services-ref
authorization-request-manager-ref
user-approval-handler-ref
user-approval-ref
error-page
approval-parameter-ref
