温馨提示

作者回复: 在授权码模式中，这里的客户是指客户端应用，一般在一个Web服务器上，资源拥有者一般使用自己的设备(PC或笔记本或手机)，通过客户应用（Web服务器设备）去访问自己在其它服务器上资源。

作者回复: 你好，举个例子，你在github上有一些项目，你就是资源（项目）拥有者(resource owner)，你可以利用github提供的开放API开发一个应用，用它可以查看甚至操作你在github上的项目，这个应用叫客户应用(client app)。如果这个应用是一个web应用，它被部署在一个web服务器上，那么它是一个私密应用，在web服务器上可以存储该应用的客户标识+凭证(client id+secret)，你需要使用浏览器(user-agent)访问这个应用，但是客户标识+凭证（包括令牌）不会被浏览器看到，所以叫私密应用。如果你开发的应用不是部署在web服务器上的，而是直接加载到用户端浏览器的单页应用，或者无线原生应用，这些应用会直接操作令牌，那么它们被称为公开应用，公开应用只存储客户标识(client id)，不能存储客户凭证(client secret)，否则会被用户看到可能泄漏，所以叫公开客户应用。另外建议看下OAuth2最简向导ppt:https://github.com/spring2go/oauth2lab/blob/master/ppt/

作者回复: 有两种设计： 一种是用户信息集中存在认证服务器上，其它服务器通过认证服务集中登录，后面需要用户数据的话，则拿令牌集中到认证服务器上去查用户数据。 另外一种做法是认证服务器上只存一个账户id(用户注册时建立)，具体用户信息，各个业务应用根据需要自己存一份，但是表中要记录用户和账户id的关联，这样通过认证服务器登录后，可以获取到账户id，然后通过账户id去查各自的用户数据。

作者回复: 你好，你学习很仔细，有思考，赞！ 关于第1个问题：第一方公开应用，如果使用用户名密码模式，原生APP是可以把clientId/secret编码在代码里头的，最后编译成二进制，一般不易拿到。如果是SPA，对于无线应用，可以考虑hybrid混合模式，clientId/secret也可以考虑编码在代码里头，如果是纯SPA，为安全考虑，可以考虑服务端配合，相当于一种授权码模式变体。 实际很多企业的第一方应用，大都采用用户名密码模式，但不是严格OAuth，也就是说clientId/secret都不传递，或者只传一个应用标识，做统计跟踪用。既然是第一方官方应用，一般和官方域名绑定，或者要经过appstore严格审核，很难伪造获利。 关于问题2：企业分内外客户的话，的确去要考虑部署两套OAuth服务，或者采用支持多租户的OAuth服务(可以参考FusionAuth(fusionauth.io))。

作者回复: 谢谢支持！加油！

作者回复: 单页是指纯静态，js/html/逻辑都跑在客户端agent（如浏览器中），后台服务器只做静态资源的hosting，无逻辑。凡后台服务器端有计算逻辑的，即使前端页面用ajax，也应该考虑走授权码模式。

作者回复: 可以简单认为是一个概念，资源拥有者是OAuth的术语，假设极客时间开发的app可以支持微信联合登录，你在微信上有用户数据（资源），你就是资源拥有者，可以授权极客时间app去访问你在微信上的数据（联合登录）

作者回复: authcode只能用来换取对应的那个token，不能干其它事情，而且有时效性。

作者回复: 谢谢建议🌹已经反馈极客时间

作者回复: 你好，课程推荐的OAuth2选型方式还是比较传统的做法，但是这几年OAuth2选型有了新的发展，考虑到简化模式(Implicit Grant)不安全，所以对于第三方的单页SPA和原生App，都推荐使用带PKCE扩展的授权码模式(Authorization Code Flow with Proof Key for Code Exchange (PKCE))，关于具体选型流程，下面是一些参考： https://auth0.com/docs/authorization/which-oauth-2-0-flow-should-i-use https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce https://dzone.com/articles/what-is-pkce https://blog.postman.com/pkce-oauth-how-to/