微信小程序的令牌流程

我们可以自己设计一套账号密码体系。我们可以自己设计一套账号密码体系，然后模拟登陆和获取用户令牌。

但是小程序是构建微信下面的，微信已经有了身份认证体系，我们没有必要自己设计账号密码体系。我们可以借用微信体系来做自己的权限体系。所以不需要传入账号密码了，小程序为每一个登录的用户生成Code，Code就是数字码。我们需要把Code码传向getToken接口。Code码是啥，既然我们没有自己的用户身份体系，那么我们必须有一个凭据去微信微服务，去换取用户身份标识。我们在getToken里得到Code码，我们向微信服务器发送请求，然后把Code码传递给微信服务器，微信服务器在接收到code码之后，她会返回给你两个主要信息openid和session_key。这个openid就是用户身份标识。我们最重要的就是要给每一个用户生成ID号，比如说我们在传入账号密码之后，写数据库的时候，你的数据库就会帮你生成代表用户唯一身份的ID，这个ID我们通常叫做UID。这个ID我们依附微信，所以要微信给我们返回openid，这个openid简单理解就是用户身份标识。这个openid不仅仅是用于用户身份标识，还有别的用处。比如说我们做微信支付，就需要openid。使用code换取的信息除了openid还有session_key。我们简单说下session_key的作用（有些产品用不到），在小程序里可以直接访问服务器拿到加密信息，由于这个信息是加密的，所以你想解密这个信息就需要session_key。之所以要解密信息是因为这个信息包含了一个变量，这个变量 叫做unionid，这个unionid和我们普通ID一样的意义。这个unionid表示的是用户的唯一标识，但是区别在于openid一个用户针对一个小程序是一个openid。但是一个用户在不同的小程序openid是不同的，哪怕小程序是属于同一个账户下的（一个身份申请很多小程序）。那么同一个用户，同一个身份注册小程序，他的openid是不同的，如果让一个身份下面所有小程序他的id是相同的，就是使用unionid。这个unionid不仅在小程序相同的，只要是同一个账号注册的小程序，公众号，服务号，这些体系下面的所有unionid对于同一个用户来说，都是相同的。我们要做不同小程序的用户关联，要保证用户id唯一，这个时候openid就不行了，必须使用unionid，因为unionid是不变的。

openid作用：1代表用户唯一标识，2比如说做微信支付，是需要使用openid的也就是说他除了身份标识之外，还要有一些功能性的作用。

在我们业务层里，我们通过微信服务器拿到openid之后，我们需要把openid存起来，存到数据库里。我们没有自己做用户的身份权限，而是自己做身份权限，最终拿到了用户的唯一标识。并且把唯一标识存储起来了。此时我们用户身份体系就建立完成了。我们要考虑一下，客户端如何访问我们的API，我们需要把openid返回到客户端，让客户端每次访问都携带openid，这样就知道你这个用户身份是否可以访问接口。我们可以不可以 直接把openid返回到小程序里，让小程序在下一次访问我们的下单接口的时候，携带openid？技术上面可以，放到实际情况，我们不能把openid返回到小程序。2个原因，1openid这种用户信息，不应该存储到客户端，出于安全性考虑，不介意把用户ID作为标识，返回到客户端。2 openid固定不变，所以说openid没有失效期。如果这个openid一但传到客户端去，丢失了之后，安全性非常差，一定要是有一个失效期的id。解决方法就是生产令牌，把令牌返回到客户端去，同时令牌是具有一定有效期的。下次访问就需要携带令牌，你通过令牌，再去找到对应令牌的openid 从而，间接拿到openid。

切记openid不要传到客户端去！只能放在服务器。

同时为了减轻数据库压力，比如说有很多HTTP请求，我们需要缓存机制。数据库持久化记录openid，但是令牌，不要存到数据库了。我们验证是为了验证令牌是否合法，所以说我们可以把令牌存储在缓存中。这样的一个是节约了数据库性能压力，另外也可以加快用户的访问速度。因为缓存查询绝对比查询数据库要快的。不过缓存的维护非常麻烦，远远比数据库麻烦。所以不要乱用。

小程序访问接口就很简单了，小程序只需要携带令牌，然后我们的服务器校验令牌，就是他不会直接查数据库了，是和缓存读取相关信息，并且校验，验证之后才会调用下单接口。如果不合法就会像客户端返回异常。

我们在小程序拿到令牌之后，携带令牌就可以访问受保护的接口。小程序携带令牌，在address接口到缓存里面换取UID。这样做的好处是，如果不是这样一种形式，而是小程序是从postbody提交到Address里去的，这就会让A用户和B用户（都是合法用户），他们都有Token令牌，A用户的令牌，但是Body里的Uid传递的是B用户的。如果Address接口使用的Body的Uid，这就会变成A用户修改B用户的用户地址。我们这样获取UID的方法就避免了这个问题，就不要明文传递，你携带你的令牌就好了，我自然有办法得到你的Uid。不过如果B用户令牌丢失了，给A用户拿到了，A用户用B用户的令牌来访问，我们的接口就真的没办法了╮(╯▽╰)╭所以令牌一定要有有效期。不能让令牌永久有效。