? 优质资源分享 ?
学习路线指引(点击解锁) | 知识定位 | 人群定位 |
---|---|---|
? Python实战微信订餐小程序 ? | 进阶级 | 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。 |
?Python量化交易实战? | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
关于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 获取更多资讯
转载请注明:xuhss » OAuth2学习中的一些高频问题的QA