@qiany 说个简单的场景，就用户名、密码、JWT 、自动登录这几个元素。
1.1 、第一次登录，客户端发送用户名、密码；
1.2 、服务器根据存储的用户名，密码做比对来验证（密码是散列码或者密文保存，这个不在这里讨论）；
1.3 、验证通过后，服务器生成 JWT 令牌，返回给客户端；
1.4 、客户端保存这个 JWT 令牌；

到此，登录认证阶段结束。

2.1 、所有必须需要先登录的接口，在请求时都要带上这个 JWT 令牌；
2.2 、服务器尝试解码这个 JWT 令牌，如果能解码，就算认证通过，否则返回认证失败；
2.3 、（可选的授权认证，这玩意后台管理系统用得多，普通系统一般不用） JWT 令牌通常都会包含用户主键，服务器那这个主键，去查找这个用户的授权，跟当前的操作需要的授权，做对比，验证当前用户是否允许这个操作；

到此，后续认证及授权阶段结束。因为除了登录、注册以及其他不需要登录就能访问的接口，都要做后续认证，这样自动登录就没必要做了，或者说上面的后续认证，就是自动登录。

上面的过程中，生成和解析 JWT 令牌，需要一个密钥，这个要服务器保存下来。通常（不是超高安全级别要求），整个系统就使用一个密钥，这个密钥直接放配置文件就行，不需要放数据库。服务器不会保存 JWT 令牌，这个客户端自己保存就够了。用户名密码这种验证是一种验证方式，令牌使用的是另外的验证方式，不一样（具体的我也不太清除，有兴趣的话你可以再查查）。


至于额外的控制，还拿上面的场景说。令牌是明文的，如果只是上面的处理，攻击者只要能够截取到这个令牌（或者攻击客户端读取到这个令牌），它就可以用这个令牌模仿对应用户的访问。所以当认证要求高的时候，就不能只认令牌，需要其他信息来辅助认证。对于敏感操作，应当直接不认这个令牌，要让用户重新登录，然后回到传统的 Session 认证。普通访问，也可以检测当前客户端的 IP 所在地，如果不在用户经常登录所在地（这个信息要保存到缓存）当中，就也不认这个令牌，让客户端重新登录。如果客户端是手机 APP ，还可以在令牌中保存 APP 的唯一识别信息，然后每次认证时都对比令牌中的唯一识别信息跟实际的信息是否相符来做辅助认证（不过这个只防君子不防小人，因为能伪造令牌就能伪造唯一识别信息）。