分布式系统认证方式与OAuth2.0概述

Session

分布式session

这个时候,通常的做法有下面几种:
+ Session复制:多台应用服务器之间同步session,使session保持一致,对外透明。
+ Session黏贴:当用户访问集群中某台服务器后,强制指定后续所有请求均落到此机器上。
+ Session集中存储:将Session存入分布式缓存中,所有服务器应用实例统一从分布式缓存中存取Session。

总体来讲,基于session认证的认证方式,可以更好的在服务端对会话进行控制,且安全性较高。但是,session机制方式基于cookie,在复杂多样的移动客户端上不能有效的使用,并且无法跨域,另外随着系统的扩展需提高session的复制、黏贴及存储的容错性。

基于token的认证方式

基于token的认证方式,服务端不用存储认证数据,易维护扩展性强, 客户端可以把token 存在任意地方,并且可以实现web和app统一认证机制。其缺点也很明显,token由于自包含信息,因此一般数据量较大,而且每次请求都需要传递,因此比较占带宽。另外,token的签名验签操作也会给cpu带来额外的处理负担。

分布式系统认证方式与OAuth2.0概述

优点:

  1. 适合统一认证的机制,客户端、一方应用、三方应用都遵循一致的认证机制。
  2. token认证方式对第三方应用接入更适合,因为它更开放,可使用当前有流行的开放协议OAuth2.0JWT等。
  3. 一般情况服务端无需存储会话信息,减轻了服务端的压力

OAuth2.0介绍

OAuth(开放授权)是一个开放标准,允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本,但不向后兼容OAuth 1.0即完全废止了OAuth1.0。很多大公司如Google,Yahoo,Microsoft等都提供了OAUTH认证服务,这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。

Oauth协议目前发展到2.0版本,1.0版本过于复杂,2.0版本已得到广泛应用。

OAauth2.0包括以下角色:

  1. 客户端
    本身不存储资源,需要通过资源拥有者的授权去请求资源服务器的资源,比如:Android客户端、Web客户端(浏览器端)、微信客户端等。
  2. 资源拥有者
    通常为用户,也可以是应用程序,即该资源的拥有者。
  3. 授权服务器(也称认证服务器)
    用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权,认证成功后会给客户端发放令牌(access_token),作为客户端访问资源服务器的凭据。
  4. 资源服务器
    存储资源的服务器。

现在还有一个问题,服务提供商能允许随便一个客户端就接入到它的授权服务器吗?答案是否定的,服务提供商会给准入的接入方一个身份,用于接入时的凭据:

  • client_id:客户端标识
  • client_secret:客户端秘钥

因此,准确来说,授权服务器对两种OAuth2.0中的两个角色进行认证授权,分别是资源拥有者、客户端。

分布式系统认证方式与OAuth2.0概述

  1. 客户端请求第三方授权
  2. 资源拥有者同意给客户端授权
  3. 客户端获取到授权码,请求认证服务器申请令牌
  4. 认证服务器向客户端响应令牌
  5. 客户端携带令牌请求资源服务器的资源
  6. 资源服务器返回受保护资源

原创文章,作者:彭晨涛,如若转载,请注明出处:https://www.codetool.top/article/%e5%88%86%e5%b8%83%e5%bc%8f%e7%b3%bb%e7%bb%9f%e8%ae%a4%e8%af%81%e6%96%b9%e5%bc%8f%e4%b8%8eoauth2-0%e6%a6%82%e8%bf%b0/

(0)
彭晨涛彭晨涛管理者
上一篇 2020年3月27日
下一篇 2020年3月27日

相关推荐

发表回复

登录后才能评论