JWT和Oauth2的应用场景的区别
jwt应用场景：
无状态的分布式API
JWT的主要优势在于使用无状态、可扩展的方式处理应用中的用户会话。服务端可以通过内嵌的声明信息，很容易地获取用户的会话信息，而不需要去访问用户或会话的数据库。在一个分布式的面向服务的框架中，这一点非常有用。
但是，如果系统中需要使用黑名单实现长期有效的token刷新机制，这种无状态的优势就不明显了（因为还是需要访问数据库，刷新时间啥的）
Oauth2应用场景：
外包认证服务器
如果不介意API的使用依赖于外部的第三方认证提供者，你可以简单地把认证工作留给认证服务商去做。
常见的，去认证服务商（比如facebook）那里注册你的应用，然后设置需要访问的用户信息，比如电子邮箱、姓名等。当用户访问站点的注册页面时，会看到连接到第三方提供商的入口。用户点击以后被重定向到对应的认证服务商网站，获得用户的授权后就可以访问到需要的信息，然后重定向回来。
这种做法的优势：快速开发，实现代码量小，维护工作简单
大型企业解决方案
如果设计的API要被不同的App使用，并且每个App使用的方式也不一样，使用OAuth2是个不错的选择。
优势：灵活的实现方式 ，可以和JWT同时使用，可针对不同应用扩展
ACCESS_TOKEN与FRESH_TOKEN之token的有效期问题
OAuth1.0中的access_token过期时间通常很长，安全性差。于是OAuth2.0推出了refresh_token。
OAuth2.0为了增强安全性,access token的有效期被大大缩短,通常只有几个小时,也可以申请增加到几十天,但是总是会有过期的时候。为此,OAuth2.0增加了一个refresh token的概念,这个token并不能用于请求api.它是用来在access token过期后刷新access token的一个标记.
为什么使用refresh_token而不是直接去获取一个新的access_token呢？
access_token的有效期一般都很短，几个小时到几天不等。如果这个时间已经过了，难道强制要求用户重新登录一次？那是不是体验太糟糕了。这个时候refresh_token就有用武之地了。
这个时候客户端就可以通过refresh_token获得新的access_token，expire_in，与refresh_token。 周而复始，你的token的有效期就能被明显延长了
这里所描述的场景,通常是指那种长周期的应用.也就是需要一直保持用户在线的应用.
在线并不是说用户一直在用这个应用,也可能是用户已经离开,我们在后台仍然可以自动维持用户的状态.例如一个自动发状态的应用.用户并不需要操作这个应用,我们会定时在后台利用用户的accesskey帮助用户发送状态.这也算是用户维持登录状态的一种.
因此如果你的refresh_token有效期是1个月，你只需要每个月帮用户发一条状态的话,走上面的流程,一直下去,这个用户的登录状态一直都不会过期。（App移动端就可以这么来实现）
JWT是怎么解决token过期时间问题的呢？
这篇文章，你值得拥有：
JWT(JSON Web Token)自动延长到期时间
细节：
1、为了不能一个帐号多次登录，因此当别地获取到一个新的token时候，之前的token需要作废，不能够在使用（做得更好一点，可以通知另外一端强制下线。参考QQ俩PC端同时登录的情况）
2、token的过期时间的设置 也一定要谨慎
总结
总而言之，Oauth2和jwt是完全不同的两种东西，一个是授权认证的框架，另一种则是认证验证的方式方法（轻量级概念）。OAuth2不像JWT一样是一个严格的标准协议，因此在实施过程中更容易出错。尽管有很多现有的库，但是每个库的成熟度也不尽相同，同样很容易引入各种错误。在常用的库中也很容易发现一些安全漏洞。
注意：
两种方案都需要SSL安全保护，也就是对要传输的数据进行加密编码。安全地传输用户提供的私密信息，在任何一个安全的系统里都是必要的。否则任何人都可以通过侵入私人wifi，在用户登录的时候窃取用户的用户名和密码等信息。
安全这个概念都是相对的，没有绝对的。比如服务端自己掌握着加密值，但万一这个值被泄漏了呢？别人还是可以破译你的JWT了。但是加上SSL的话，安全性就大大增加了
