OAuth2.0基础及分布式认证管理系统的分析

本文介绍了OAuth2.0协议的基础知识,包括角色和重要概念,以及在分布式系统下认证系统的分析。讨论了基于Session和Token的认证方式优缺点,并提出了通常选择Token方案的原因,强调了统一认证服务在分布式架构中的重要性。
摘要由CSDN通过智能技术生成

一、介绍

OAuth是开放授权的译文,是一个开放标准,允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息,而不需要将用户的名称、密码等重要信息提供给第三方应用或分享他数据的内容;

OAuth2.0是OAut协议的延续版本,但不向后兼容,即完全废弃了OAuth1.0;很多大公司如Google、Yahoo、Microsoft等都提供了OAuth认证服务;

OAuth2.0是一个开放授权的标准;

参考网站:https://baike.baidu.com/item/oAuth/7153134?fr=aladdin
OAuth协议:https://tools.ietf.org/html/rfc6749 

对OAuth认证简单的理解:允许项目将之前实现的认证与授权的过程叫给第三方来进行保护;而OAuth协议就是用来定义如何让这个第三方的担保有效且双方可信;

二、OAuth2.0协议

2.1)角色

OAuth2.0协议包含以下几个角色

  • 客户端

浏览器、微信、支付宝等用户直接使用的发起载体; 本身补存储资源,需要通过资源拥有者的授权去请求服务器上的资源;

  • 资源拥有者

通常是指用户、应用程序等,即当前访问资源的拥有者;

  • 授权服务

也称为认证服务,用于服务提供者对资源拥有身份认证,对访问资源进行授权,认证成功后会给客户端发放令牌(Access_token),作为客户端访问资源服务器的凭据;

  • 资源服务器

存储资源的服务器;用于提供给资源拥有者对应的资源信息;

2.2)重要的概念

  • clientDetails

client_id,资源端信息;是一个针对资源端的唯一索引标识,用于标识一个资源;即:在微信开发者平台注册的一个账号后就会分配一个唯一的client_id;

  • secret

密钥;是一个加密的字段,这个密钥根自身的加密算法有关;

  • scope

授权作用域;标识当前拥有可访问资源的范围;

  • access_token

授权码;就是我们所说的凭证,在调用服务接口的时候需要提供;

  • grant_type

授权类型;例如微信目前支持基于授权码的authorization_code模式;OAuth2.0还可以有其他授权模式,例如用户名密码模式等;

  • userDetails

授权用户标识;用于标识一个用户的唯一属性;

三、分布式下认证系统的分析

在软件架构由单体架构演变成分布式架构的情况下,每个服务都会有认证、授权的需求;如果每个服务都实现一套认证逻辑是冗余且不现实的;针对分布式系统的特点,一般会需要一套独立的第三方系统来提供统一的认证授权服务,对分布式系统认证的总结如下:

  • 统一认证授权

提供独立的认证服务,进行统一处理认证授权;无论是不同类型的用户还是不同类型的客户端,均采用一致的认证、授权、会话判断机制,实现统一的认证授权服务;

要实现这种统一规则,认证方式必须可扩展、支持各种认证要求;例如:用户名密码、短信验证码、二维码、人脸识别等各种认证方式,并可以灵活的切换;

  • 多样的认证场景

对于不同的应用场景,例如:后台查询、支付等需要不同的安全级别,也需要有对应的认证场景;

  • 应用接入认证

应提供扩展和开放的能力,提供安全的系统对接机制,并可以开放部分API给地三方使用,内部服务与外部第三方服务采用统一的接入机制;

四、分布式认证解决方案

在分布式环境下的认证方案主要有:Session、Token两种方案;

4.1)基于Session的认证方式

Session是由服务端进行管理的,在分布式环境下通常有如下几种做法:

  • Session复制

在多台应用服务器之间同步Session,并使Session保持一致,对外透明;

  • Session黏贴

当用户访问某个服务的时候,通过某种介质(例如:Nginx)强制指定后续所有请求落到此机器上;

  • Session集中存储

将Session存入分布式统一的存储介质中,所有服务应用实例都统一从这个介质中获取;

总结:基于Session认证的方式可以更好的在服务端对会话进行控制,且安全性高;但是Session机制总体是基于Cookie的,客户端奥保存SessionId,在这复杂多样的客户端上不能有效的使用。另外随着系统的扩展需要提高,Session赋值、黏贴、存储的过程中出错率会很高,缺乏容错性;

4.2)基于Token的认证方式

服务端不在存储认证数据,这样容易维护,扩展性强;客户端可以把Token存放到任意地方,并且可以实现多终端统一认证机制;

同时缺点也很明显,客户端容易泄露信息,Token由于包含了大量的信息,因此一般数据较大,而且每次请求都需要传递,占用传输带宽;Token签名、验签的操作也会给系统带来额外的负担;

4.3)方案选型

在通常的情况下,还会选择更加通用的Token方式,这样能保证整个系统更加灵活的扩展性,并减轻服务端的压力,增加容错性及健壮性;

在这种情况下认证服务会独立出来成为一个统一的认证服务,统一认证服务(UAA)和网关两个部分组合起来一起完成认证授权服务;

统一认证服务承载介入方认证、登录、授权以及令牌管理的职责,完成实际的用户认证、授权功能;

而网关作为整个分布式系统的唯一入口,为接入方提供API的结合;其本身还可能具有其他辅助职责,如身份验证、监控、负载均衡、缓存、协议转换等功能; 网关方式的核心要点是:所有接入方及消费方都通过统一的网关接入微服务,在网关层处理所有与业务无关的功能

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值