乐趣区

关于架构师:Java架构师成长直通车40周完结无密

download:Java 架构师成长直通车(40 周完结无密)

OAuth2 学习中的一些高频问题的 QA
对于 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 本身和语言是无关的。

退出移动版