持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第5天，点击查看活动详情
流程分析
今天我们讲讲登录Token的处理。登录Token基于OAuth2协议，有兴趣的可以详细了解下。我们需要关注的有access_token和refresh_token。我们调用login接口，通常会返回access_token、access_token_expire、refresh_token、refresh_token_expire几个字段，我们把这几个字段再加上lastLoginTime使用SharedPreferences缓存到本地，注意区分用户。access_token一般过期时间比较短，而refresh_token过期时间相对长一些，也可以是永久。如果access_token没有过期，我们每次请求数据的时候在请求头里面的Authorization带上access_token，如果access_token过期，我们则需要先调用带上refresh_token的refreshLogin接口，获取新的access_token，并更新access_token和access_token_expire的缓存数据，而refresh_token不变。接下来继续访问我们需要访问的接口。如果refresh_token过期了，则需要用户重新调用login接口，获取新的access_token和refresh_token，即登录令牌掉了。推荐access_token的过期时长为6小时，而refresh_token的过期时长为1个月。
行为验证码
在调用login接口之前，其实还可以加上极验验证geetest，用来检测是否是真人在进行操作。
Token详解
另外，请求头Authorization添加Token也有两种情况。Authorization:[token]或Authorization:Bearer [token]。参考OAuth2.0的RFC6749和 RFC6750。
BEARER类型的Token是在RFC6750中定义的一种Token类型，OAuth2.0协议RFC6749对其也有所提及，算是对RFC6749的一个补充。BEARER类型Token是建立在HTTP/1.1版本之上的Token类型，需要TLS（Transport Layer Security）提供安全支持，该协议主要规定了BEARER类型Token的客户端请求和服务端验证的具体细节。
前面介绍了BEARER类型的Token，RFC6750明确说明该类型Token需要TLS（Transport Layer Security）提供安全支持。虽然现今大部分站点都已经或正在由HTTP向HTTPS迁移，但是仍然会有站点继续在使用HTTP，在这类站点中BEARER类型的Token存在安全隐患，这个时候MAC类型的Token正是用武之地，MAC类型的Token设计的主要目的就是为了应对不可靠的网络环境。MAC类型相对于BEARER类型对于用户资源请求的区别在于，BEARER类型只需要携带授权服务器下发的Token即可，而对于MAC类型来说，除了携带授权服务器下发的Token，客户端还要携带时间戳nonce，以及在客户端计算得到的mac值等信息，并通过这些额外的信息来保证传输的可靠性。
其实很多API服务并没有使用https加密连接（却使用了BEARER类型的Token），所以你可以利用一些抓包工具进行抓包分析，可以看到一些应用请求附带的Token，你拿这个Token也可以访问相应的第三方api，可能有的Token时效比较短，用不了多久就会过期。
