全文小结：
微信小程序token被获取安全吗
安全念银。微信小程序都是经过乱搭官方认证，其范围都在法律范围之内，因此token被获取是安全的，微信是腾讯公司于2011年1月21日推出的一仔陪宴款通过网络快速发送语音短信、视频、图片和文字，支持多人群聊的手机聊天软件。
安卓版的token安全吗
安全
在app开放接口api的设计中，避免不了的就是安全性问题，因为大多数接口涉及到用户的个人信息以及一些敏感的数据，所以对这些接口需要进行身份的认证，那么这就需要用户提供一些信息，比如用户名密码等，但是为了安全起见让用户暴露的明文密码次数越少越好，我们一般在web项目中，大多数采用保存的session中，然后在存一份到cookie中，来保持用户的回话有效性。但是在app提供的开放接口中，后端服务器在用户登录后如何去验证和维护用亏燃户的登陆有效性呢，以下是参考项目中设计的解决方案，其原理和大多数开放接口安全验证一样，如淘宝的开放接口token验证，微信开发平台token验证都是同理。
签名设计
对于敏感唤空伏的api接口，需使用htTps协议
https是在http超文本传输协议加入SSL层，它在网络间通信是加密的，所以需要加密证书。
https协议需要ca证书，一般需要交费。
原理：用户登录后向服务器提供用户认证信息（如账户和密码），服务器认证完后给客户端返回一个Token令牌，用户再次获取信息时，带上此令牌，如果令牌正取，则返回数据。对于获取Token信息后，访问用户相关接口，客户端请求的url需要带上如下参数：
时间戳：timestamp
Token令牌：token
然后将所有用户请求的参数按照字母排序（包括timestamp，token），然后根据MD5加密（可以加点盐），全部大写，生成sign签名，这就是所说的url签名算法。然后登陆后每次调用用户信息时，带上sign，timestamp，token参数。
api请求客户端想服务器端一次发送用用户认证信息（用户名和密码），服务器端请求到改请求后，验证用户信息是否正确。
如果正确：则返回一个唯一不重复的字符串（一般为UUID），然后在Redis（任意缓存服务器）中维护Token—-Uid的用户信息关系，以便其他api对token的校验。如果错误：则返回错误码。
2.服务器设计一个url请求拦截规则
（1）判断是否包含timestamp，token，sign参数，如果不含有返回错误码。
（2）判断服务器接到请求的时间和参数中的时间戳是否相差很长一段时间（时间自定义如半个小时），如果超过和携则说明该url已经过期（如果url被盗，他改变了时间戳，但是会导致sign签名不相等）。
（3）判断token是否有效，根据请求过来的token，查询redis缓存中的uid，如果获取不到这说明该token已过期。
（4）根据用户请求的url参数，服务器端按照同样的规则生成sign签名，对比签名看是否相等，相等则放行。（自然url签名也无法100%保证其安全，也可以通过公钥AES对数据和url加密，但这样如果无法确保公钥丢失，所以签名只是很大程度上保证安全）。
（5）此url拦截只需对获取身份认证的url放行（如登陆url），剩余所有的url都需拦截。
3.Token和Uid关系维护
对于用户登录我们需要创建token–uid的关系，用户退出时需要需删除token–uid的关系
app怎样防止token被盗取？
token是个凭条，简郑不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。\x0d\x0a\x0d\x0a客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。\x0d\x0a解决这个问题的一个简单办法\x0d\x0a1、在存储的时候把token进行对称加密存储，用时解开。\x0d\x0a2、将请求URL、时间戳、token三者进行合并加盐签名，服务端校验有效性。\x0d\x0a这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。然而其实说难也不难，所以终究是防君子不防小人的做法。话说加密存储一个你要是被人扒开客户贺链端看也不会被喷明文存储??\x0d\x0a方法1它拿到存储的密文解不开、方法2它不知道你的签名算法和盐，两者可以结合食用。\x0d\x0a但是如果token被人拷走，他自然也能植入到自己的手机里面，那到时候他的手机也可以以你的身份来用着，这你就瞎了。\x0d\x0a于是可以提供一个让用户可以主动expire一个过去的token类似的机制，在被盗的时候能远程止损。\x0d\x0a话说一个人连自己手机都保护拦拍颂不好还谈什么安全??\x0d\x0a\x0d\x0a在网络层面上token明文传输的话会非常的危险，所以建议一定要使用HTTPS，并且把token放在postbody里。
JWT-token—前后端分离架构的api安全问题
前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。
前后端分离架构现状：
这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。
1.接口公开，谁都可以访问
2.数据请求的参数在传输过程被篡改
3.接口被重复调用
...
session和丛空前cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服渗清务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了
JWT标准的token包含三部分：
头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等
将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header
Payload也是一个JSON对象。包含了一些其他的信息
这里面的前五个字段都是由JWT的标准所定义的。
将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作亏庆JWT的Payload
将上面的两个编码后的字符串都用句号 . 连接在一起（头部在前），就形成了
最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容
这一部分叫做 签名
最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT
签名解决了数据传输过程中参数被篡改的风险
一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。
解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击
比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。
可以在Payload里增加时间戳并且前后端都参与来解决：
