關於OAuth2相信很多初學者都有一些疑問，胖哥將這些疑問一一收集了起來做成了QA，或許能幫助學習者。
OAuth2相關的QA
Q：OAuth2 的一些常用場景？
A： OAuth2主要用於API授權，是跨API服務之間授權的解決方案。它適用於單點登入（SSO）、微服務之間的授權鑑權、API開放平臺等場景。
Q： 什麼是OAuth2客戶端？
A： 在OAuth2授權伺服器上註冊為客戶端，並獲得專屬client_id標識的才是OAuth2客戶端。安卓應用、IOS應用、Web前端等客戶端應用也要遵循這個原則，它們本身註冊到OAuth2授權伺服器才能成為OAuth2客戶端，否則就不是OAuth2客戶端，必須是它們本身，而不是支撐它們的後端服務。
Q：OAuth2 客戶端為什麼分為public和confidential兩種型別，分別是什麼場景？
A：rfc6749#section-2.1 根據OAuth2客戶端自身是否有能力維護客戶端憑據（client credentials）的私密性，是否能安全地通過授權伺服器對客戶端的資質進行認證將OAuth2客戶端分為機密客戶端和公共客戶端。大部分的後端資料服務都應該被註冊為機密客戶端；無法保障自身憑據安全的都應該被註冊為公共客戶端，公共客戶端是沒有client_sercet的，直接註冊到OAuth2授權伺服器的執行客戶端，不通過後端應用進行訪問令牌中繼的都是公共客戶端，例如在一些特定場景下需要直連授權伺服器的Web應用、移動應用。
Q：OAuth2 的access_token和refresh_token應該直接返回給前端嗎？
A：能不能返回給前端取決於這個前端是不是直接在授權伺服器的OAuth2客戶端，如果不是，就不能持有access_token和refresh_token，access_token和refresh_token的簽發目標只能是OAuth2客戶端。如果暴露面放開，則很容易被盜用。
Q：非OAuth2客戶端的客戶端應用既然不能直接持有access_token和refresh_token的話，應該如何獲取授權狀態？
A：當授權成功後，令牌和使用者客戶端側可以藉助於session或者cookie進行一個對映，當然也可以考慮計算出一個不透明令牌（ Opaque Token ）對映，具體根據業務考量。
Q：OAuth2中的scope是什麼？A：OAuth2是一個授權框架，授權自然要劃定一個範圍（scope），以保證OAuth2客戶端在既定的範圍內行事而不越界。它起到的作用和RBAC中的role其實類似，都是用來限制資源的訪問許可權的。 role針對的是資源擁有者（Resource Owner），而scope針對的是OAuth2客戶端。 當然有一個例外openid，這個是OIDC 1.0的標識，算一個關鍵字。
Q：OAuth2 中的登入頁面和授權確認頁面能不能用前後端分離的方式？
A：很多開發者不希望點選授權的時候被302重定向到授權伺服器提供的登入頁面，但是你得明白一個道理， OAuth2客戶端和授權伺服器之間並不是一個完全信任的關係。外賣小哥給你送外賣，你肯定希望發放給他的是一個臨時門禁通行碼，而不是一個常用通行碼。另外ajax無法安全地處理OAuth2授權流程中的302重定向問題，這也是一個技術問題。
Q：OAuth2 客戶端能否做使用者認證？
A：OAuth2本身並沒有定義使用者如何向OAuth2客戶端認證身份，這裡要和授權伺服器上的使用者認證區別開來。OAuth2客戶端在完成授權時可以拿到授權憑據，但是並不能直接拿到使用者資訊，如果授權伺服器提供了獲取使用者資訊的資源介面，OAuth2客戶端可以通過該介面嘗試獲取使用者資訊用來表明使用者的身份，這取決於使用者是否授權了OAuth2客戶端這樣做。OIDC 1.0補充定義了OAuth2客戶端對使用者進行認證的細節流程。
Q：OAuth2客戶端認證是什麼？
A：confidential型別的OAuth2客戶端雖然在OAuth2授權伺服器註冊，它們要根據一些策略（Client Authentication Method）來向授權伺服器證明自己是合法的客戶端。這樣它們才能呼叫一些OAuth2規定的端點，比如/oauth2/token令牌端點、/oauth2/revoke令牌撤銷端點等等。關於OAuth2客戶端認證的細節可以參考OAuth2客戶端認證過濾器詳解。
Q：OAuth2密碼模式為什麼被廢除了？
A：準確地說目前密碼模式在OAuth2.1中被移除了，包括OAuth0、okta等知名三方授權服務機構都對密碼模式進行了移除處理。
密碼模式誕生的時候，像React、Vue這種單頁應用還沒有興起，甚至連框架都還沒有呢。它更像一種為了解決遺留問題而採用的過渡方案。在傳統應用中，使用者習慣了把密碼直接交給客戶端換取資源訪問許可權，而不是跳來跳去去拉授權、確認授權。OAuth2誕生之時為了讓使用者從傳統思維中慢慢轉變過來就設計了這種模式。 它打破了委託授權的模式，降低了OAuth2的安全性。
更多的細節請參考我往期的相關文章。
Q：OAuth2中的資源伺服器怎麼講？
A：只要包含了需要OAuth2客戶端攜帶access_token訪問的資源介面的伺服器都可以認為是資源伺服器，包括OAuth2客戶端、OAuth2授權伺服器都可以根據業務和架構承擔資源伺服器的功能。從使用者（資源所有者）角度來說，存放使用者可以授權的資源介面的伺服器都可以是資源伺服器。資源伺服器可以對訪問令牌access_token進行解碼、校驗，並確定本次請求是否合規。
Q：微服務是否可以不使用OAuth2？
當然可以，OAuth2只不過是目前微服務訪問控制的解決方案之一，並不是唯一選項。
總結
這就是最近胖哥被問的比較多的一些問題，相信能夠幫助各位。OAuth2的東西並不簡單，經過近三年內斷斷續續的學習，胖哥才完完全全理解這個東西，所以各位學習者不要心急，學的枯燥的時候先晾一時間，學這個最重要的是理解它的概念和流程，這遠比各種框架重要，OAuth2本身和語言是無關的。
關注公眾號：Felordcn 獲取更多資訊