使用dba登录。
先创建一个用户:使用命令:create user 用户名 identified by 密码
给该用户解锁:使用命令:用户解锁 alter user 用户名 account unlock(不解锁无法登陆)
给该用户授权:grant create session to 用户名。这里是给的登录权限。如果想把dba的权限授权给该用户。OAuth(开放授权)是一个开放标准,允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容,OAuth20是OAuth协议的延续版本,但不向后兼容OAuth 10即完全废止了OAuth10。
第三方应用授权登录:在APP或者网页接入一些第三方应用时,时长会需要用户登录另一个合作平台,比如QQ,微博,微信的授权登录。
原生app授权:app登录请求后台接口,为了安全认证,所有请求都带token信息,如果登录验证、请求后台数据。
前后端分离单页面应用(spa):前后端分离框架,前端请求后台数据,需要进行oauth2安全认证,比如使用vue、react后者h5开发的app。
OAuth 20的运行流程如下图,摘自RFC 6749。
授权码模式(authorization code)是功能最完整、流程最严密的授权模式。
(1)用户访问客户端,后者将前者导向认证服务器,假设用户给予授权,认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI),同时附上一个授权码。
(2)客户端收到授权码,附上早先的"重定向URI",向认证服务器申请令牌:GET /oauth/tokenresponse_type=code&client_id=test&redirect_uri=重定向页面链接。请求成功返回code授权码,一般有效时间是10分钟。
(3)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。POST /oauth/tokenresponse_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。
简化模式(implicit grant type)不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了"授权码"这个步骤,因此得名。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。
流程步骤:
请求URL:
密码模式(Resource Owner Password Credentials Grant)中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向"服务商提供商"索要授权。在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。一般不支持refresh token。
步骤说明:
(A)用户向客户端提供用户名和密码。
(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。
(C)认证服务器确认无误后,向客户端提供访问令牌。
<article class="hentry">
指客户端以自己的名义,而不是以用户的名义,向"服务提供商"进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求"服务提供商"提供服务,其实不存在授权问题。
它的步骤如下:
(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。
(B)认证服务器确认无误后,向客户端提供访问令牌。
A步骤中,客户端发出的>
一、概述
java应用系统设计过程中,用户认证、用户授权、鉴权是绕不过去的话题。
如果这个权限管理的设计,没有做到与业务系统的隔离,拓展性不够强,很容易就会拖后腿。
这个问题应该做过开发的同学都会有所体会。
现在网络上的各种关于权限管理的框架比较主流的有 Apache Shiro,Spring Security,Sa-Token(新兴起的一个优秀框架)。
这里会有同学说,既然已经有这么多的成熟优秀的权限管理框架,为什么还有再给大家介绍这种实现思路。
在本人工作和学习的过程中,经常会使用这些优秀的权限管理框架。
但是,一旦是这些三方框架出现的异常和问题,想要排查,就比较麻烦。要么就是靠着百度大家的经验。要么就是猛扒代码,一点点去排查。
三方框架对于我们使用者来说,就像是一个黑盒。这一点一直让我觉得有点不顺畅。
同学们,谁不想要一个自己知根知底的的权限管理框架呢。
二、框架使用体验
21 项目初始化配置
Springboot老三样。
引入pom依赖:
修改配置文件:
22 用户登录
自定义一个凭证类
自定义一个凭证类认证器:
这个认证器很简单 就是默认admin 密码 123456 然后给与了固定的角色和全部的资源。实际应用中应该从数据库中获取到用户的权限 并组织返回的securityAuthority。
开放认证接口:
23 权限验证
路由级别鉴权:
不用做其他额外的配置 只需要打上@HasUrl 就会获取到Controller层的当前url地址,并校验用户是否有访问该url的权限。
并将解析后的用户信息放到方法的SecurityAuthority参数中
在第一步用户登录时,默认给了SecurityResallUrlRes() ,则配置了 / 的url访问权限。
方法级别鉴权
验证用户是否登录
三、时间地点人物
想要描述一个事情,都是将时间地点人物介绍完,才能吧事情描述清楚。
介绍这个设计思路也需要介绍前提:
31 什么时候用这个框架
显然,如果系统需要提供用户认证、用户授权、用户鉴权的时候,就需要有一个权限管理的模块。
整个流程应该是:
用户认证 --> 颁发token(用户授权) --> 用户鉴权 --> token回收
32 框架要提供哪些能力
以上能力老生常谈就是最基础的权限管理。
33 框架应该有哪些抽象组件
这个问题是面向对象开发的java程序员必须要好好思考的问题,就是当你接到一个需求时,如何以面向对象的思维来分析和设计程序来完成需求。
331 用户认证
用户认证,最最常见的场景就是用户名密码登录。
在这个场景中可能存在:
用户名+密码、用户名+密码+验证码、手机号+验证码、邮箱+验证码 这么多的登录方式。
而通常来验证这些登录信息是否合法,一般都是要去数据库中读取用户的注册信息来完成认证。
这个场景下可以抽象出来的类有:
1 凭证类:用户名+密码、用户名+密码+验证码、手机号+验证码、邮箱+验证码
2 凭证类验证器:用来验证用户上传的凭证是否是合法的。
332 用户授权
当用户完成认证凭证验证后,服务器应该返回一个用户的口令(token),给用户使用。
并且用户的token应该可以关联并携带出用户绑定的所有资源权限,和角色、部门、岗位等等信息。
用户的资源又分为:
静态资源:
菜单、按钮等静态资源
文档、等静态资源
动态资源:
对某种资源的CURD权限:如 是否可以对 sys_user表数据进行CURD。
这个场景下可以抽象出来的类:
其中的岗位和部门,有些权限管理框架中没有,有的或许有一个,这里不纠结这个问题,无论是部门还是岗位,其实都是提供了一种权限判断的维度,类型给用户打上一种标签。
333 token管理
生成用户token后,所有的token需要管理起来。可以用来统计和维护。
所以需要将上一步获取到的用户权限描述类的信息与token建立一种映射关系。从而可以通过token获取到用户的各种信息。
这个场景可以抽象出来的类:
Token管理类:用来管理所有生成的token。并建立用户信息与token的关联关系。
334 用户鉴权
当用户通过用户认证和用户授权后,就获取到了他的token口令。
每次用户来访问服务资源时,都需要携带token,当服务器收到请求后,需要通过token获取到用户的所有的权限信息,来判断用户是否可以访问当前资源。
这个场景似乎没有可以抽离出来的类,而是我们要找到一种用户鉴权的方案。
这里,根据以往的经验,基于Spring的AOP切面编程应该是对使用者最友好的方式
所以这里总结下我们需要鉴权的类型:
四、小结
上面铺垫了那么些,其实只是想让大家能跟笔者有一个相同的认知。
先梳理下上面总结出来的类。
凭证类、凭证类验证器、token生成器、token管理器。
以及,基于AOP实现的用户鉴权方案。
大致思路:
未完待续。。。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)