收藏备用 | 关于OAuth2的一些常见问题总结

收藏备用 | 关于OAuth2的一些常见问题总结

关于OAuth2相信很多初学者都有一些疑问，胖哥趁着Spring Security OAuth2专栏写完的间隙将这些疑问一一收集了起来做成了QA，或许能帮助OAuth2学习者，这个必须收藏备用。

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 中的登录页面和授权确认页面能不能用前后端分离的方式？

**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？

A：当然是可以的，OAuth2只不过是目前微服务访问控制的解决方案之一，并不是唯一选项。

总结

这就是最近胖哥被提问得比较频繁的一些问题，相信能够帮助各位。OAuth2的东西并不简单，经过近三年内断断续续的学习，胖哥才完完全全理解这个东西，所以各位学习者不要心急，学的枯燥的时候先晾一时间，学这个最重要的是理解它的概念和流程，这远比各种框架重要，OAuth2本身和语言是无关的。

如果你还有其它的疑问，可以留言

更好的办法是加入学习交流群一起交流

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。