OAuth2使用心得

一个企业下面如果将来准备做很多的产品,各个产品的用户又是公用的,那么设计一个“用户中心库”是很有必要的,这样一来,一个该企业的用户可以很方便的使用该企业下的所有产品而不需要反复注册。
有了上面这一个“用户中心”,那么很快就会产生一个问题-----相同的用户名和密码在各个产品直接很难维护,如果user1用户登录了A产品,用户想要修改密码那就灾难了,除非一个产品不提供这项功能,但是一个设计好的产品这样子的功能怎么能够不考虑呢!所以修改密码就必须引导用户去到一个统一的帐号管理中心页面去修改。看起来视乎问题解决了,但是当某一天登录A产品的用户user1要掉用B产品的某项涉及到用户user1的服务,那么考虑安全问题,很显然A产品必须提供user1用户名和密码给B产品去用户中心确认,如果产品多了怎么办,想想看就头疼,用户名和密码在产品之间到处飞。
那么这样子普遍的情况下,该怎么办才好呢?
OAUTH2就是专门解决这种问题而诞生的国际共识。


认证中心(AccessToken)<----->用户中心(UserInfo)
^ |
| https |token
| v
短信中心 <---token------- 客服中心(app client_id=xxx client_secret=xxxxxxxxxxx)

仔细研究oauth2会发现,产品之间关键的用户名和密码换成了一个token。那么现在安全了吗?
不过,如果被人获得了token和资源服务器请求接口的时候,不知道该怎么办?看起来如果不是获得用户的银行卡号和密码视乎还可以容忍。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值