上一節介紹過什麼是oauth2，這節準備用生動的事例來告訴大家oauth2執行的流程。
我們來想這樣乙個場景：假設我們有乙個叫做萬方網盤的服務是用來幫助使用者儲存**文件的，我們向外提供了符合oauth2標準的api，可以讓第三方程式獲取到使用者的**。有乙個第三方的程式可以呼叫我們平台的介面獲取使用者**，來幫助使用者投稿。
在oauth中，我們管使用者叫做資源擁有者（resource owner，ro），投稿應用叫做client，萬方網盤叫做資源服務（resource server，rs），昨天我們還提到的乙個發放令牌的角色叫做授權服務（authorization server，as）。
以下是oauth2的基本執行流程：
0、resource owner向cilent發出某個請求，這個請求需要呼叫resource owner的使用者資源。
1、client為了能夠拿到使用者的資源，就要先獲取使用者的授權。
2、client拿著使用者授權向authorization server請求訪問令牌（access token）
3、然後client再拿著訪問令牌去向resource server獲取使用者資源
這就是乙個完整的oauth流程，放一張官方的圖給大家看：
其實當第一次完成a到d的四個步驟之後，client再要去請求資源的時候，就直接拿著access token去請求就可以了，不需要每次都進行a到d四個步驟。因此，我們發現在這個過程中access token會經常的被傳輸，越是經常被網路傳輸的資訊就越容易洩漏，因此access token的有效時間就要設定的短一些。但是如果因為access token的有效期短，導致了頻繁向使用者請求授權，這是一件使用者體驗很差的事情，為了解決這個問題，oauth2引入了refresh token。
當client得到使用者授權之後，向授權伺服器獲取授權的時候，授權伺服器不止會給client乙個access token還會給乙個refresh token用以換取新的access token。當client請求資源伺服器之後，發現原本合法的access token失效之後（步驟e到f），會用refresh token向授權伺服器再請求乙個新的access token，授權伺服器會將新的access token和新的refresh token傳送給client（步驟g到h）。由於有了refresh token，client在向授權伺服器請求access token的時候就可以不需要再次向使用者請求授權了。同樣的，因為refresh token很少用於傳輸，所以它是安全的。
OAuth2認證方式介紹
在任何 oauth 流程中都有三個參與者 客戶端 登入的人員或使用者 使用者 客戶端想要登入的應用程式 在上圖中是 gitlab 服務提供者 使用者通過其進行身份驗證的外部應用程式。上圖中為 github 使用oauth進行認證和授權的過程如下所示 a 使用者開啟客戶端以後，客戶端要求使用者給予授權...
微服務統 認證 案 OAuth2
基於session的認證方式 在分布式的環境下，基於session的認證會出現 個問題，每個應 服務都需要在session中儲存 戶身份資訊，通過負載均衡將本地的請求分配到另 個應 服務需要將session資訊帶過去，否則會重新認證。我們可以使 session共享 session黏貼等 案。sess...
Oauth2 四種模式
1.隱式授權模式 implicit grant 第一步 使用者訪問頁面時，重定向到認證伺服器。第二步 認證伺服器給使用者乙個認證頁面，等待使用者授權。第三步 使用者授權，認證伺服器想應用頁面返回token 第四步 驗證token，訪問真正的資源頁面 授權碼授權模式 authorization cod...