我眼中的 OAuth2 就是适用于提供一些业务能力给第三方,但又能灵活控制第三方获取的权限,像微信支付宝一键登录那种。
我们的系统中,用户不会出现像提供给第三方登录(类似微信支付宝那种),也不会有与其他系统进行 SSO 的情况。
认证和鉴权分为三个部分:用户,微服务之间,需要对接的第三方服务
说一下我们现在的方式:
- 对接第三方服务:由于对接的不是很多,所以就是简单的协商,共享一个 secret,请求的时候对请求和 secret 做摘要。网关认为此接口是白名单,直接放行到下游服务,直接在业务逻辑做的验证。
- 微服务之间:没有做任何鉴权,因为只有网关的端口对外开放,所以里面就认为是安全的。
- 用户
- 登录流程:登录相关接口网关认作白名单,直接由用户管理服务去做登录逻辑,登录成功后,客户端拿到 token 。
- 业务认证流程:用户管理服务提供给网关一个接口。入参 token 和要访问的 URL,出参是用户信息。网关每收到请求,都会调用这个接口验证权限。验证通过了将用户 ID 等必要信息添加到 Http 头中透传到下游服务。
- 综上所述,我们这个完全就是自己实现的,没有使用任何轮子,像 Spring Security 或者 Shiro 那种,我感觉那种只是适合 Session 的场景(很久没有关注过 Spring Security 了)
看了不少博客或者公众号说,微服务的认证鉴权应该全盘梭哈 OAuth2,我们正要起一个新的项目,所以请问大家,这种情况下应该怎么搞?
- 像前面说的,用户没有 SSO 需求和提供给第三方登录的功能,OAuth2 的授权码模式感觉套不进去哎,如果是 Implicit 或者 Password 模式,这样有感觉跟自己实现的那种逻辑差不多了。而且后面这两种模式,oauth.net 上已经说因为安全问题不推荐使用了。
- 微服务之间需要做鉴权吗?感觉这种跟 OAuth2 的模型完全搭不上边了。
求大佬释疑解惑。