基于非会话的用户认证模式和服务的方法及系统与流程

文档序号:23664102发布日期:2021-01-15 14:02阅读:73来源:国知局
基于非会话的用户认证模式和服务的方法及系统与流程

本发明涉及用户认证技术领域,具体地说是一种基于非会话的用户认证模式和服务的方法及系统。



背景技术:

大数据和云计算时代,技术中台、业务中台以及大大小小的应用系统被开发出来,一个大型网站的背后其实是由拆分后的一个个服务或者应用系统组成,为了提升用户体验,只需登录一次即可访问整个网站服务的需求被提出,因此单点登录的技术概念也被提出。

同时,如果一个大型企业内部每个系统都开发一套用户认证服务,将会造成巨大的重复性劳动和时间浪费,大量繁杂的应用系统也不便于用户体系的管理,给运营人员造成巨大的维护成本。

而且随着技术的进步,移动端、浏览器端等客户端越来越繁杂,需要对不同客户端进行一个认证模式的统一。之前基于会话的cas方式越来越无力支撑细粒度、集群化、分布式的微服务后台模式。故如何能够实现支持多客户端模式、微服务模式的认证体系是目前亟待解决的技术问题。



技术实现要素:

本发明的技术任务是提供一种基于非会话的用户认证模式和服务的方法及系统,来解决如何能够实现支持多客户端模式、微服务模式的认证体系的问题。

本发明的技术任务是按以下方式实现的,一种基于非会话的用户认证模式和服务的方法,该方法是通过统一认证中心提供javasdk,同时提供restfulapi接口,保证对接的多样性和跨编程语言性,将认证、鉴权的过程基于javaweb的过滤器在javasdk进行实现,并与认证中心服务进行对接;

统一用户认证服务使用java实现,基于oauth2.0协议标准,并采用jsonwebtoken的令牌类型,对用户、角色、菜单权限功能的封装与集成,从而实现对外的用户认证、鉴权功能。

作为优选,基于oauth2.0协议标准是统一认证中心对oauth2.0协议的多种获取令牌方式进行实现,同时对接短信平台,实现通过手机短信验证码来获取令牌的展开方式。

作为优选,获取令牌的展开方式应用在开发过程中时,根据本身的场景进行选择,具体如下:

(一)、使用默认登录页、前后端不分离,后端获取令牌的场景;

(二)、使用默认登录页、前后端分离,前端获取令牌的场景;

(三)、自定义登录页面、通过后台获取令牌的场景;

(四)、短信验证码获取令牌的场景。

更优地,使用默认登录页、前后端不分离,后端获取令牌的场景的过程具体如下:

①、应用客户端根据client_id和redirect_url向认证服务器请求获取code;

②、认证服务器重定向到client_url,携带code到应用客户端;

③、应用客户端根据code向认证服务器换取token;

④、认证服务器响应应用客户端token。

更优地,使用默认登录页、前后端分离,前端获取令牌的场景的过程具体如下:

①、应用客户端调用隐藏式获取令牌的接口:http://ip:port/oauth/authorize?response_type=token&client_id=xxxxxx&scope=all&redirect_uri=callback_url,页面会自动跳转到认证服务器提供的登录页;

②、用户输入账号密码登陆后,页面会自动跳转到callback_url,并且携带#access_token认证服务器重定向到redirect_url,锚点access_token到应用客户端;其中,callback_url是应用客户端前端的一个地址,应用客户端前端需要获取到access_token,此后的请求都携带token即可;

③、应用客户端后台需要添加filter,对应用客户端前端所传过来的token进行校验(令牌校验接口)。

更优地,自定义登录页面、通过后台获取令牌的场景的过程具体如下:

①、应用客户端通过自定义登录页,在应用客户端后台根据用户的用户名和密码,调用密码式获取令牌的接口来获取access_token;

②、获取到token后写到应用客户端前端cookie,此后的请求都携带token进行访问应用客户端后台即可;

更优地,短信验证码获取令牌的场景的过程具体如下:

①、应用客户端根据手机号码向认证服务器请求获取验证码;

②、应用客户端根据短信验证码从认证服务器获取令牌;

③、认证服务器响应应用客户端令牌。

作为优选,jsonwebtoken的令牌类型采用jwt,jwt是一种json格式的token,在payload中携带非敏感信息及令牌超时时间的信息,同时也携带签名校验,实现非会话的、无状态的令牌形式。

一种基于非会话的用户认证模式和服务的系统,该系统包括,

浏览器,用于访问资源服务器的资源以及重定向访问资源,同时用于登陆并授权认证服务器;

资源服务器,用于校验token以及携带token鉴权认证sdk,同时用于响应资源到浏览器;

认证sdk,用于重定向认证中心登录页到浏览器,将token写入set_cookie,并重定向到目标资源,并用于允许访问资源服务器的资源,同时用于校验token,并根据code获取token,携带token鉴权;

认证服务器,用于回调认证sdk的code,并响应token。

作为优选,该系统的工作过程具体如下:

s1、浏览器访问资源服务器的资源;

s2、认证sdk校验资源服务器的token;

s3、认证服务器校验认证sdk的token;

s4、当校验失败时,认证sdk重定向到浏览器的认证中心登录页面;

s5、浏览器登录并授权认证服务器;

s6、认证服务器回调code到认证sdk;

s7、认证sdk根据code从认证服务器获取token;

s8、认证服务器相应token;

s9、认证sdk将token写入set-cookie,并重定向到浏览器的目标资源;

s10、浏览器重定向访问资源服务器的资源;

s11、资源服务器携带token鉴权到认证sdk;

s12、认证sdk携带token鉴权到认证服务器;

s13、认证服务器鉴权成功,并反馈到认证sdk;

s14、认证sdk允许访问资源服务器的资源;

s15、资源服务器响应浏览器的资源。

本发明的基于非会话的用户认证模式和服务的方法及系统具有以下优点:

(一)本发明基于oauth2.0标准进行研发,框架相对成熟稳定,也降低了开发难度;

(二)本发明所研发的服务由插件的形式支持多种数据库,实现了服务的热插拔,降低了重启的风险;

(三)本发明提供对多种开发语言系统的支持,应用更加灵活;

(四)客户端通过jwt实现了非会话、无状态的令牌,服务器端无需存储,大大提升了空间利用率;

(五)本发明支持认证、鉴权等,功能强大且灵活,同时实现,用户体系的统一管理,用户权限的统一管理,租户信息的统一管理;还提供租户分配、租户下用户的隔离模式、提供基于rbac的角色-权限控制、提供获取菜单树数据结构的接口以及提供授权码式、隐藏式、密码式等多种获取令牌的认证、鉴权接口;

(六)本发明对用户、角色、菜单权限功能的封装与集成,从而实现对外的用户认证、鉴权功能的统一用户认证中心,其特征是面向租户的、用户的、角色和权限的维度。

附图说明

下面结合附图对本发明进一步说明。

附图1为服务项目模块图;

附图2为基于非会话的用户认证模式和服务的系统的交互流程图;

附图3为使用默认登录页、前后端不分离,后端获取令牌场景的流程图;

附图4为使用默认登录页、前后端分离,前端获取令牌的场景的流程框图;

附图5为自定义登录页面、通过后台获取令牌的场景的流程框图;

附图6为短信验证码获取令牌的场景的流程框图;

附图7为业务应用对接到统一认证云服务的示意图;

附图8为租户体系的示意图。

具体实施方式

参照说明书附图和具体实施例对本发明的基于非会话的用户认证模式和服务的方法及系统作以下详细地说明。

实施例1:

本发明的基于非会话的用户认证模式和服务的方法,该方法是通过统一认证中心提供javasdk,同时提供restfulapi接口,保证对接的多样性和跨编程语言性,将认证、鉴权的过程基于javaweb的过滤器在javasdk进行实现,并与认证中心服务进行对接;

统一用户认证服务使用java实现,基于oauth2.0协议标准,并采用jsonwebtoken的令牌类型,对用户、角色、菜单权限功能的封装与集成,从而实现对外的用户认证、鉴权功能。

本发明实现了用户体系的统一管理、用户权限的统一管理及租户信息的统一管理;同时还提供租户分配、租户下用户的隔离模式、基于rbac的角色-权限控制及获取菜单树数据结构的接口,提供授权码式、隐藏式、密码式等多种获取令牌的认证、鉴权接口,如附图1所示。

其中,基于oauth2.0协议标准是统一认证中心对oauth2.0协议的多种获取令牌方式进行实现,同时对接短信平台,实现通过手机短信验证码来获取令牌的展开方式。获取令牌的展开方式应用在开发过程中时,根据本身的场景进行选择,具体如下:

(一)、使用默认登录页、前后端不分离,后端获取令牌的场景;如附图3所示,具体如下:

①、应用客户端根据client_id和redirect_url向认证服务器请求获取code;

②、认证服务器重定向到client_url,携带code到应用客户端;

③、应用客户端根据code向认证服务器换取token;

④、认证服务器响应应用客户端token。

(二)、使用默认登录页、前后端分离,前端获取令牌的场景;如附图4所示,具体如下:

①、应用客户端调用隐藏式获取令牌的接口:http://ip:port/oauth/authorize?response_type=token&client_id=xxxxxx&scope=all&redirect_uri=callback_url,页面会自动跳转到认证服务器提供的登录页;

②、用户输入账号密码登陆后,页面会自动跳转到callback_url,并且携带#access_token认证服务器重定向到redirect_url,锚点access_token到应用客户端;其中,callback_url是应用客户端前端的一个地址,应用客户端前端需要获取到access_token,此后的请求都携带token即可;

③、应用客户端后台需要添加filter,对应用客户端前端所传过来的token进行校验(令牌校验接口)。

(三)、自定义登录页面、通过后台获取令牌的场景;如附图5所示,具体如下:

①、应用客户端通过自定义登录页,在应用客户端后台根据用户的用户名和密码,调用密码式获取令牌的接口来获取access_token;

②、获取到token后写到应用客户端前端cookie,此后的请求都携带token进行访问应用客户端后台即可;

(四)、短信验证码获取令牌的场景,如附图6所示,具体如下:

①、应用客户端根据手机号码向认证服务器请求获取验证码;

②、应用客户端根据短信验证码从认证服务器获取令牌;

③、认证服务器响应应用客户端令牌。

其中,关于jsonwebtoken的令牌类型说明如下:

http协议本身是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,并不能知道是哪个用户发出的请求,所以为了让应用能识别是哪个用户发出的请求,只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给应用,这样应用就能识别请求来自哪个用户了,这就是传统的基于session认证。而jwt是一种json格式的token,在payload中携带非敏感信息及令牌超时时间的信息,同时也携带签名校验,实现非会话的、无状态的令牌形式。

基于rbac的角色-权限控制的说明如下:

在rbac中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的,权限赋予给角色,而把角色又赋予用户,这样的权限设计很清楚,管理起来很方便。

多租户云模式的说明如下:

提供云租户模式,将租户申请api接口进行开放,通过申请租户来将业务应用对接到统一认证云服务,如附图7所示。

提供完全隔离的租户环境,租户管理自己体系下的用户、角色、菜单、组织等,如附图8所示。

实施例2:

本发明基于非会话的用户认证模式和服务的系统,该系统包括,

浏览器,用于访问资源服务器的资源以及重定向访问资源,同时用于登陆并授权认证服务器;

资源服务器,用于校验token以及携带token鉴权认证sdk,同时用于响应资源到浏览器;

认证sdk,用于重定向认证中心登录页到浏览器,将token写入set_cookie,并重定向到目标资源,并用于允许访问资源服务器的资源,同时用于校验token,并根据code获取token,携带token鉴权;

认证服务器,用于回调认证sdk的code,并响应token。

如附图2所示,该系统的工作过程具体如下:

s1、浏览器访问资源服务器的资源;

s2、认证sdk校验资源服务器的token;

s3、认证服务器校验认证sdk的token;

s4、当校验失败时,认证sdk重定向到浏览器的认证中心登录页面;

s5、浏览器登录并授权认证服务器;

s6、认证服务器回调code到认证sdk;

s7、认证sdk根据code从认证服务器获取token;

s8、认证服务器相应token;

s9、认证sdk将token写入set-cookie,并重定向到浏览器的目标资源;

s10、浏览器重定向访问资源服务器的资源;

s11、资源服务器携带token鉴权到认证sdk;

s12、认证sdk携带token鉴权到认证服务器;

s13、认证服务器鉴权成功,并反馈到认证sdk;

s14、认证sdk允许访问资源服务器的资源;

s15、资源服务器响应浏览器的资源。

最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1