關於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 獲取更多資訊