Token - 服务端身份验证的流行方案

作者: heyikan | 来源:发表于2016-11-02 10:07 被阅读5814次
    token - 令牌

    身份认证


    服务端提供资源给客户端,但是某些资源是有条件的。所以服务端要能够识别请求者的身份,然后再判断所请求的资源是否可以给请求者。

    token是一种身份验证的机制,初始时用户提交账号数据给服务端,服务端采用一定的策略生成一个字符串(token),token字符串中包含了少量的用户信息,并且有一定的期限。服务端会把token字符串传给客户端,客户端保存token字符串,并在接下来的请求中带上这个字符串。

    它的工作流程大概是这样:

    组件图

    Token机制

    在这样的流程下,我们需要考虑下面几个问题:

    1. 服务端如何根据token获取用户的信息?
    2. 如何确保识别伪造的token?
      这里是指token不是经过服务端来生成的。
    3. 如何应付冒充的情况?
      非法客户端拦截了合法客户端的token,然后使用这个token向服务端发送请求,冒充合法客户端。

    用户匹配

    服务端在生成token时,加入少量的用户信息,比如用户的id。服务端接收到token之后,可以解析出这些数据,从而将token和用户关联了起来。

    防伪造

    一般情况下,建议放入token的数据是不敏感的数据,这样只要服务端使用私钥对数据生成签名,然后和数据拼接起来,作为token的一部分即可。比如JWT,参考JSON Web Token - 在Web应用间安全地传递信息

    在我知道JWT之前,我先了解的是另一种模式。基于加密的算法,对数据进行加密,把加密的结果作为token。

    本文主要讨论后一种模式。

    防冒充

    加干扰码

    服务端在生成token时,使用了客户端的UA作为干扰码对数据加密,客户端进行请求时,会同时传入token、UA,服务端使用UA对token解密,从而验证用户的身份。

    如果只是把token拷贝到另一个客户端使用,不同的UA会导致在服务端解析token失败,从而实现了一定程度的防冒充。但是攻击者如果猜到服务端使用UA作为加密钥,他可以修改自己的UA。

    有效期

    给token加上有效期,即使被冒充也只是在一定的时间段内有效。这不是完美的防御措施,只是尽量减少损失。

    服务端在生成token时,加入有效期。每次服务端接收到请求,解析token之后,判断是否已过期,如果过期就拒绝服务。

    token刷新

    如果token过期了,客户端应该对token续期或者重新生成token。这取决于token的过期机制。

    1. 服务器缓存token及对应的过期时间
      这个时候就可以采用续期的方式,服务器更新过期时间,token再次有效。
    2. token中含有过期时间
      这个时候需要重新生成token。

    在token续期或者重新生成token的时候,需要额外加入数据来验证身份。因为token已经过期了,即token已经不能用来验证用户的身份了。这个时候可以请求用户重新输入账号和密码,但是用户体验稍差。

    另一种方式是使用摘要。服务端生成token,同时生成token的摘要,然后一起返回给客户端。客户端保存摘要,一般请求只需要用到token,在刷新token时,才需要用到摘要。服务端验证摘要,来验证用户的身份。因为摘要不会频繁的在客户端和服务端之间传输,所以被截取的概率较小。

    Token工作流程


    生成token

    生成token

    一般在登录的时候生成token。Token管理者负责根据用户的数据生成token和摘要,摘要用来给APP端刷新token用,类似于微信登录中的refresh_token。

    生成token的过程中,ua的充作干扰码。没有相同的ua,就无法解析生成的token字符串。如果客户端是混合开发的模式,生成token和使用token的代理可能不同(比如一个是h5,一个是原生),ua就会不同,token就无法成功的使用。可以选择其他的客户端数据作为干扰码,注意考虑下面的问题:

    1. 不同的客户端,干扰码应该不同
      干扰码的很大一个作用是防冒充,如果选择的充当干扰码的客户端数据没有区分性,就达不到效果。
    2. 选择充当干扰码的数据,在哪些情况下会变化?这些情况是否合理?
      比如干扰码数据中含有app的版本号,那么app版本升级就会导致干扰码变化。服务端根据新的干扰码,无法解析旧的token,此时用户必须重新登录。这种情况是合理的吗?如果不合理,干扰码中就不应该含有app的版本号。

    拦截验证

    拦截验证

    客户端的每一次请求,都必须携带token、ua,拦截器会对敏感资源的访问进行拦截,然后根据ua解析token,解析不成功,表示token和ua不匹配。解析成功之后,判断token是否已过期,如果是,拒绝服务。所有都ok的情况下,拦截器放行,请求传达到业务服务者。

    token刷新

    token刷新

    当token过期,用户需要刷新token。刷新token本质上是这样的:

    服务端:这个token是你的吗?
    客户端:是的。
    服务端:当初我给你token的时候,还给了一个摘要,你把摘要拿过来证明。

    客户端需要把token、摘要、ua都传给服务端,服务端对token重新生成摘要,通过判断两个摘要是否相同来验证这次请求刷新token的客户端,是不是上次请求生成token的客户端。验证通过,服务端需要使用用户数据重新生成token,用户数据则来自用ua解析token的结果。

    相关文章

      网友评论

      • 闲梦清秋:对不起,我没看明白,我的帐号提示token已过期,现在要怎么办呢?谢谢!
      • 喝凉水的男人:请教个问题,token机制如何应对多平台的登录状态,比如App和微信小程序。
        heyikan:@喝凉水的男人 你这个token生成和验证的机制是怎样的?跟我所说的相同吗?
        喝凉水的男人:@金珑 嗯,不好意思,这几天忙其他的了,问题就是小程序登录的情况下,App端再登录,这时返回小程序去进行购物流程,会报出token无效
        heyikan:我没有做过微信小程序,你可以把问题具体描述一下吗?
      • a991b6f98cfa:看了一天的token相关的文章了,有几个问题:

        1。就是【用户id + 用户名 + UserAgent + 过期时间】 这样的MD5加密字符串吧?

        2。服务器保存的token是保存在Cache的缓存里,还是数据库呢?

        3。用户客户端的token到底是保存在Cookie还是local storage、session storage呢?


        4.在有的文章中有提到放在Authorization header里。在每次请求时如何用这header携带token呢?


        实在是看了十多篇文章没搞懂,想向楼主确认下。望楼主指点迷津,感谢!!!
        mmf多多:1->可以这么做,把你需要的信息放在一起,然后加密;
        2->首先服务器是不是需要保存token是一个问题,反向可解密的token可以不用保存,hash加密的token如果没法反向解密需要保存的话理论上存哪儿都可以,一般存cache因为token是会过期的,没必要存db;
        3->客户端把token放哪儿,看客户端token管理的选择;
        4->请求时token放哪儿也是个选择问题,可以放在http协议的header里,也可以拼在url里,也可以放cookie里
      • 云龙789:怎么生成和获取知道吗?我知道laravel自带 但是如果其他框架 需要用
        heyikan:@栾金龙 我用的方式就是自己写算法生产token和解析token的,没有用框架
        云龙789:@守正ing 你只知道原理 不知道怎么用?
        heyikan:@栾金龙 自己加密和解密,框架的我没用过

      本文标题:Token - 服务端身份验证的流行方案

      本文链接:https://www.haomeiwen.com/subject/wvjvuttx.html