获得徽章 6
赞了这篇沸点
![[玫瑰]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_103.6c2eed8.png)
![[不看]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_102.b113c42.png)
简单理解OAuth 2.0 ：
以“用户用微信登录掘金”的场景为例，这中间涉及到两个应用，但只需要登录一次微信，用户将在微信的信息，这个过程就是授权，但是用户需要登录一次微信并同意授权给掘金即可，这中间的交互过程和安全问题就是OAuth 2.0所定义的授权标准
。
对于开发者而言，如果你是微信应用的开发者，那么涉及到OAuth 2.0的部分就是提供授权服务。授权服务要做的几个事情：
1.管理第三方应用（掘金），因为不可能把用户的信息授权给任意一个应用。
2.管理访问令牌，用户同意授权且验证第三方应用后，会发放访问令牌。这里要管理令牌的生成、续期、失效、验证等。
3.管理用户数据，要保障用户数据的安全。
如果你是掘金应用的开发者，那么涉及到OAuth 2.0的部分就是提供代理服务。代理服务要做的几个事情：
1.获取授权许可，去微信授权服务注册你的信息，拿到授权许可（appid、appsecret等）。
2.获取访问令牌，引导用户去授权服务获取访问令牌。
3.获取用户数据，带着访问令牌访问授权服务获取用户数据。
可以看到访问令牌其实是OAuth 2.0中的关键，拿到访问令牌也意味着整个授权过程完成。在OAuth 2.0标准中，又因为不同的授权场景存在不同授权类型或者是获取访问令牌的方式，这也是和OAuth 1.0的不同之处。四种授权类型：
1.授权码许可，授权的过程中涉及到第三方应用的前端页面和授权服务的交互，授权码起到重定向和安全的作用。授权服务验证用户密码后先返回授权码，最终通过授权码获取到访问令牌，也是安全性最高的一个。
2.资源拥有者凭据许可，名字有点长，简单理解就是第三方应用和授权服务属于一个主体，授权服务验证用户密码后直接给访问令牌，有点单点登录的意思。
3.客户端凭据许可，名字有点抽象，简单理解就是用户的信息是公开的，虽然是公开的，但还是需要授权码，只不过不需要用户介入，没有登录操作，直接用appid、appsecret获取访问令牌。
4.隐式许可，这个就更简单了，为了安全，appsecret和令牌都是第三方应用通过后端服务访问，不暴露出来，但是遇到那些只有前端的应用，appsecret就没有存在的必要了，直接用appid获取访问令牌。
简而言之，言而总之，OAuth 2.0就是定义了几种授权类型，围绕着用户、第三方应用和授权方展开。
以“用户用微信登录掘金”的场景为例，这中间涉及到两个应用，但只需要登录一次微信，用户将在微信的信息，这个过程就是授权，但是用户需要登录一次微信并同意授权给掘金即可，这中间的交互过程和安全问题就是OAuth 2.0所定义的授权标准
。
对于开发者而言，如果你是微信应用的开发者，那么涉及到OAuth 2.0的部分就是提供授权服务。授权服务要做的几个事情：
1.管理第三方应用（掘金），因为不可能把用户的信息授权给任意一个应用。
2.管理访问令牌，用户同意授权且验证第三方应用后，会发放访问令牌。这里要管理令牌的生成、续期、失效、验证等。
3.管理用户数据，要保障用户数据的安全。
如果你是掘金应用的开发者，那么涉及到OAuth 2.0的部分就是提供代理服务。代理服务要做的几个事情：
1.获取授权许可，去微信授权服务注册你的信息，拿到授权许可（appid、appsecret等）。
2.获取访问令牌，引导用户去授权服务获取访问令牌。
3.获取用户数据，带着访问令牌访问授权服务获取用户数据。
可以看到访问令牌其实是OAuth 2.0中的关键，拿到访问令牌也意味着整个授权过程完成。在OAuth 2.0标准中，又因为不同的授权场景存在不同授权类型或者是获取访问令牌的方式，这也是和OAuth 1.0的不同之处。四种授权类型：
1.授权码许可，授权的过程中涉及到第三方应用的前端页面和授权服务的交互，授权码起到重定向和安全的作用。授权服务验证用户密码后先返回授权码，最终通过授权码获取到访问令牌，也是安全性最高的一个。
2.资源拥有者凭据许可，名字有点长，简单理解就是第三方应用和授权服务属于一个主体，授权服务验证用户密码后直接给访问令牌，有点单点登录的意思。
3.客户端凭据许可，名字有点抽象，简单理解就是用户的信息是公开的，虽然是公开的，但还是需要授权码，只不过不需要用户介入，没有登录操作，直接用appid、appsecret获取访问令牌。
4.隐式许可，这个就更简单了，为了安全，appsecret和令牌都是第三方应用通过后端服务访问，不暴露出来，但是遇到那些只有前端的应用，appsecret就没有存在的必要了，直接用appid获取访问令牌。
简而言之，言而总之，OAuth 2.0就是定义了几种授权类型，围绕着用户、第三方应用和授权方展开。
展开
评论
1
刚才看了下Elasticsearch的原理，感觉分布式系统的思想都大差不差。下面是我对ES的理解：
1. ES基于Lucene，Lucene底层的存储结构通过Segment表达，Segment里面有分词以及出现的次数和所在的文件，通过这样的结构就能实现搜索功能。那么，在ES中的每个分片就是一个Lucene。
2. 在Lucene中，Segment是在内存中，所以，数据的可靠就需要ES去保障。另外，从这一点也可以得知ES是吃内存的，这也是为什么可以做到实时搜索。
- 单机情况下，为了不影响写入效率，通常的解决方案就是日志先行写入磁盘，就像MySQL中的WAL，在ES中叫TransLog。基于日志形式在进行数据更新时，可以通过合并的方式保障同一条数据不重复，很多分布式系统中都有这样的思想，例如HBase中的LSM。
- 在分布式系统中，数据可靠性的保障都是通过副本的形式，就例如redis、Hadoop、Kafka等等。保障副本的一致就离不开paxos、raft这些一致性协议。
3.当然，在分布式系统中的查询，都是先路由到对应的分片，然后再将各分片的数据聚合，例如Hadoop中的shuffle，在ES中同样会有聚合的阶段。
1. ES基于Lucene，Lucene底层的存储结构通过Segment表达，Segment里面有分词以及出现的次数和所在的文件，通过这样的结构就能实现搜索功能。那么，在ES中的每个分片就是一个Lucene。
2. 在Lucene中，Segment是在内存中，所以，数据的可靠就需要ES去保障。另外，从这一点也可以得知ES是吃内存的，这也是为什么可以做到实时搜索。
- 单机情况下，为了不影响写入效率，通常的解决方案就是日志先行写入磁盘，就像MySQL中的WAL，在ES中叫TransLog。基于日志形式在进行数据更新时，可以通过合并的方式保障同一条数据不重复，很多分布式系统中都有这样的思想，例如HBase中的LSM。
- 在分布式系统中，数据可靠性的保障都是通过副本的形式，就例如redis、Hadoop、Kafka等等。保障副本的一致就离不开paxos、raft这些一致性协议。
3.当然，在分布式系统中的查询，都是先路由到对应的分片，然后再将各分片的数据聚合，例如Hadoop中的shuffle，在ES中同样会有聚合的阶段。
展开
评论
5