共计 2529 个字符，预计需要花费 7 分钟才能阅读完成。
对于 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 获取更多资讯
集体博客：https://felord.cn
