Heim  >  Artikel  >  Backend-Entwicklung  >  客户端api设计时这个返回的Acess_token是怎么保证验证安全的

客户端api设计时这个返回的Acess_token是怎么保证验证安全的

WBOY
WBOYOriginal
2016-06-06 20:14:221335Durchsuche

刚看了一份api验证流程

  1. 客户端提交账号信息(用户名+密码)到服务端

  2. 服务端验证成功,返回AccessToken给客户端存储
    3.访问受限资源时,客户端带入AccessToken就可访问。

其中第一步如果是被抓包的连接请求是不是也会返回AcessToken
返回的AcessToken被抓包后也被恶意请求的连接带上是不是也会通过验证
主要是不知道被抓包后获得的这个相同的AcessToken也用来请求服务器是怎么样验证的
请大神指点,这个AcessToken是怎么起到作用的,起到了什么作用,给点细节

回复内容:

刚看了一份api验证流程

  1. 客户端提交账号信息(用户名+密码)到服务端

  2. 服务端验证成功,返回AccessToken给客户端存储
    3.访问受限资源时,客户端带入AccessToken就可访问。

其中第一步如果是被抓包的连接请求是不是也会返回AcessToken
返回的AcessToken被抓包后也被恶意请求的连接带上是不是也会通过验证
主要是不知道被抓包后获得的这个相同的AcessToken也用来请求服务器是怎么样验证的
请大神指点,这个AcessToken是怎么起到作用的,起到了什么作用,给点细节

如果传输过程中是明文传输,那么公网上是能劫持到AccessToken的,这个AccessToken在一定时间范围内,不论在谁的手里,都有其对应的用户权限。AccessToken泄露就意味着短时间内用户部分权限泄露。

1、一般API接口都是2小时有效期,APP的则是几天不等。服务器规定。
2、AccessToken可以规定只有部分权限,比如AccessToken1只能查看和编辑用户照片,AccessToken2只能查看和编辑用户好友列表。AccessToken1泄露了顶多把照片丢了,但不会把用户好友信息泄露和破坏。

这个AccessToken你可以认为是为了替换【每次传输账号密码进行验证】这个方法而产生的新方法,因为每次传输账号密码进行验证更不安全,一旦泄露那么就相当于用户所有权限永久泄露(除非用户改密码)。而AccessToken泄露则是仅在AccessToken有效时间内泄露其规定的资源范围内的权限。

服务器端并不验证是好鸟还是坏鸟拿着这个AccessToken使用。退一步讲如果黑客拿着你的账号密码登陆,服务器难道还要给你发一条短信让你输验证码么?(至少现在支付宝连自己APP内部的异常登录提示都不给你发了)

想保证AccessToken的安全,必须由用户侧(这里指服务提供商,比如segmentfault)和Oauth2提供者(比如新浪微博、微信)同时保证,中间数据传输一定要密文的才行。一般都是使用https传输,靠Oauth2提供者的https证书保证安全。如果使用http明文传输,或者https被劫持并被用户侧忽略,则AccessToken被恶意盗取的可能性就陡增。但也由于AccessToken有其权限范围,一般劫到AccessToken也做不了什么,顶多就是改改个人信息,发个垃圾微博啥的?毕竟改密码等高级权限可能这个AccessToken上没有(也不一定,很可能微博很懒根本就没给AccessToken设置权限范围)

没什么作用,只是为了在别人不知道你的accesstoken机制的时候进行一步防范。抓包知道这回事以后,提交是可以自己修改的。进一步是需要加入一些参数签名方法,或者是参数整体加密的方法来防止篡改。

客户端和服务器会约定加密方式,AccessToken也会过期。

https双向加密可以防止别人抓到你网络传输的AcessToken,客户端在保存Token到本地的时候可以加密存储

你可以把 access token 理解为 web 下的 cookie,如果 cookie 被偷走了,其实也是不安全的。
对于中间人来说,用 https 就好。
对于终端上的攻击者,你得从业务流程上做好防范,比如限制接口调用频率,引入合理的加密增加攻击难度。

  1. 你把AcessToken看成一个常规web应用中登录以后session中存储的user_id,就算抓包抓到了,他也只是获得了一个用户的账号密码以及用户的所有信息,类似个人用户密码被盗,不至于拿到整站数据这种风险

  2. AcessToken被抓包后也被恶意请求的连接带上是不是也会通过验证?
    这个要取决于你的AcessToken生成规则,如果是简单的md5(user_id)那肯定不行,这样每个用户每次生成的AcessToken都一样了,所以需要保证每次生成以后响应给客户端的都是不一样的,然后存储在redis这种数据库中key=AccessToken,value=user_id,如果做的极致一点应该是要有失效时间的,失效了就重新发起请求获取AcessToken

  3. 关于验证问题,web客户端存cookie里,APP客户端存本地数据库,每次请求都带上,然后每次比对请求过来的accesstoken在redis中找对应的user_id值,然后服务端取到user_id进行数据获取操作

这个是基本的一个逻辑,其中应该还会牵涉业务,要根据实际情况来进行调整了

  1. OAuth2规定API必须用https,获取到token没那么容易

  2. Token是有过期时间的,通常不会很长

个人喜欢用Json Web Token,楼主可以去查查相关的资料

AccessToken?以前做微博那帮人抓取的经常去找weico的key来用...

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn