Oauth2.0部分
- AuthorizationServerConfigurerAdapter 授权服务器核心配置类
- @EnableAuthorizationServer 启用授权服务器
- TokenStore 令牌存储
- AuthorizationServerTokenServices 令牌服务
- 为什么授权码模式要通过重定向来的到授权码而不是直接返回授权码
请求授权服务器以后,授权服务器返回一个是否授权的页面,用户点击同意以后才能获取授权码,这个是否同意授权的页面在某些情景是必须的,并且只能是客户端来调起,毕竟权限是客户授予,不能是服务器端调起。也就是授权操作应该由位于客户端的客户发起,并且同意授权,这时候如果直接返回,那么客户端就会直接获取到授权码,服务器拿到的就是二手数据,只能是客户端上报客户服务器,不可靠。所以只能通过重定向到客户服务器,客户服务器就能拿到一手的授权码,然后发起获取token的的操作。 - bearer 是什么
bearer一种access_token类型的类型,适用于https类型的请求,与之对应的还有一种叫做MAC的access_token类型,适用月http协议的请求。和bearer相比MAC 类型的token还要携带时间戳,nonce,以及在客户端计算得到的mac值等信息,并通过这些额外的信息来保证传输的可靠性 - 刷新令牌
- 资源服务器 使用security oauth2授权模式
第1步:引入依赖
第2步:继承AuthorizationServerConfigurerAdapter,并且重写对应的三个配置方法
token服务
授权码模式需要用的的授权码服务的配置
用户名密码模式需要用到的认证服务(WebSecurityConfigurerAdapter中已经初始化了认证管理者,我们直接去这里面拿到放入spring容器中就行了)
配置完成以后就能使用使用授权服务了,需要注意的是使用@EnableAuthorizationServer直接开启授权服务器
- 获取授权的方式
授权码模式,账号密码模式,客户端模式,匿名模式
对应 ClientDetailsServiceConfigurer的authorizedGrantTypes方法设置的授予权限方式,只有这里面配置的授权模式才能用。
- 授权码模式(最安全,但是也是复杂的模式)
第1步:前端get请求向授权服务器请求授权,oauth/authorize?client_id=客户端ID&response_type=code&scope=all&redirect_uri=重定向地址
第2步:授权服务器返回前端是否授权的页面,用户在这个页面可以同意或者拒绝授权
第3步:用户点击同意授权,然后授权服务器从定向到指定地址,并且重定向地址后面带上授权码
授权服务器重定向地址和参数格式类似:重定向地址?code=授权码
第4步:这时候重定向地址一般是客户端对应的三方服务器的一个接口,这接口里面会取出授权码,然后想授权服务器请求token,拿到token以后就可以通过token获取客户在资源服务器中的数据了。 - 授权码简化模式
主要面向没有服务端的三方引用,授权直接拿到的就是token,而不是授权码
请求格式如下: http://127.0.0.1/te/oauth/authorize?client_id=c1&response_type=token&scope=all&redirect_uri=重定向地址,区别在于response_type是token,而不是code 简化模式重定向地址里面直接带有token,而不是code:重定向地址/#access_token=wESGfmOuPinUMfl4G2HY_HII-HA&token_type=bearer&expires_in=2526
指的注意的是简化模式没用用到客户端密钥,为什么可以不用密钥? - 账号密码模式(我们自己的客户端用这种,三方客户端不适合)
这种模式,用户会在客户端输入密码,也就是说客户端是可以获取并记录用户密码的,只能用于我们自己内部开发的客户端 - 客户端认证模式(完全信赖这个客户端的时候才能用)
- 资源服务器配置的适用授权服务器的token
继承ResourceServerConfigurerAdapter并重写关于资源安全配置和http安全配置的2个方法
需要注意的是 @EnableResourceServer 注解回去校验token,
@EnableGlobalMethodSecurity(prePostEnabled=true,securedEnabled=true) 注解才会是方法上面的验证权限注解生效,两个注解都不能少
- oauth2协议规定的鞋带token格式
hearderName为Authorization,headerValue为bearer token的请求头 - 资源ID有什么用
在资源服务器配置的时候,我们给这个资源服务器指定一个资源ID
在授权服务器上,给客户指定资源Ids,用于限制客户可以可以访问的资源服务器
上面设置的 .resourceIds("res1","res1" ) //客户端的资源ID 就是客户可以使用的资源服务,我们可以这样理解,用户拥有的权限是用户能访问的最多资源,但是我们和三方客户合作的时候不会全都允许他们范围所有资源服务器,这时候通过资源ID来对权限分组,和客户签约那些资源服务器就给与那些资源Ids。
- scopes 什么意思
scope 是权限的分级,可以理解成权限的细化,一个权限可以分成读写或者更多的子权限
如下面的配置,我们要求/res/**,都有all的范围,也可以定义成read,write等等
- .allowedTokenEndpointRequestMethods(HttpMethod.POST); 是什么意思?
限制只能post的方式获取token - JwtAccessTokenConverter 作用
提供token和map之间的相互装换,接口定义如下
- 使用jwt 格式的token
在授权服务器端配置jwtTokenStore
在授权服务器端tokenService 上面设置增强
在资源服务器上设置和认证服务相同的密钥的tokenStore
jwt 格式的token 非常适合自己的服务器集群授权,不适合三方服务器授权,因为它可以通过签名验证token的合法性,节省了验证token的网络请求,但是在三方授权的系统只,不可能获取到授权服务器的token生成密钥。
- 关于 客户 用户 资源ID 资源服务器 授权服务 权限 scope 的解释
客户:指的三方机构
用户:就是程序的使用人员
资源服务器:提供资源的服务器器
资源ID:资源服务器的ID,一个资源ID对应着一堆权限
授权服务器:授予用户和客户访问资源服务器里面资源权限的服务器
权限:资源服务器里面的一个接口的使用权限
scope:可以理解成权限范围,或者说一个权限可以分成多个,比如读写 - 关于分布式集群token的校验位置
第一种:是在同一在网关校验,然后别的节点都在网关的内网,不在做权限,有问题网关就返回了,优点校验逻辑统一,缺点,节点没有权限认证,不能对外网开发,并且如果校验token逻辑复杂,有网络请求,会加重网关负载。
第二种:直接在资源服务器上网关只做转发,校验由资源服务器来做,优点,校验压力分散,各节点可以对外提供服务。缺点,校验逻辑需要每个资源服务器都有,即便他们是完全一样的。 - 资源服务器和授权服务器不应该是一个程序,如果只有一个程序那么其实不适合oatuh2的协议,直接用security就行了。甚至如果我们自己的服务器集群也不需要auth2协议,直接使用security+jwt格式的token就行了。