OAuth2 vs JWT，到底怎么选？
扫码关注“后端架构师”，选择“星标”公众号
重磅干货，第一时间送达！
责编：架构君 | 来源：乐傻驴
链接：jianshu.com/p/1f2d6e5126cb
责编：架构君 | 来源：乐傻驴
链接：jianshu.com/p/1f2d6e5126cb
上一篇好文：知名国产论坛，凉了！！！！
大家好，我是后端架构师。
本文会详细描述两种通用的保证API安全性的方法：OAuth2和JSON Web Token (JWT)
假设:
你已经或者正在实现API； 你正在考虑选择一个合适的方法保证API的安全性；
JWT和OAuth2比较？
要比较JWT和OAuth2？首先要明白一点就是，这两个根本没有可比性，是两个完全不同的东西。
JWT是一种认证协议 JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。 OAuth2是一种授权框架 另一方面，OAuth2是一种授权框架，提供了一套详细的授权机制（指导）。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。既然JWT和OAuth2没有可比性，为什么还要把这两个放在一起说呢？实际中确实会有很多人拿JWT和OAuth2作比较。标题里把这两个放在一起，确实有误导的意思。很多情况下，在讨论OAuth2的实现时，会把JSON Web Token作为一种认证机制使用。这也是为什么他们会经常一起出现。
JSON Web Token (JWT)
JWT在标准中是这么定义的：
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS). -RFC7519 https://tools.ietf.org/html/rfc7519
JWT是一种安全标准。基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证成功，会产生并返回一个Token（令牌），用户可以使用这个token访问服务器上受保护的资源。
一个token的例子:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
一个token包含三部分：
header.claims.signature
了安全的在url中使用，所有部分都 base64 URL-safe进行编码处理。
Header头部分头部分简单声明了类型(JWT)以及产生签名所使用的算法。
{ "alg" : "AES256", "typ" : "JWT"}
Claims声明
声明部分是整个token的核心，表示要发送的用户详细信息。有些情况下，我们很可能要在一个服务器上实现认证，然后访问另一台服务器上的资源；或者，通过单独的接口来生成token，token被保存在应用程序客户端（比如浏览器）使用。一个简单的声明（claim）的例子：
{ "sub": "1234567890", "name": "John Doe", "admin": true}
Signature签名
签名的目的是为了保证上边两部分信息不被篡改。如果尝试使用Bas64对解码后的token进行修改，签名信息就会失效。一般使用一个私钥（private key）通过特定算法对Header和Claims进行混淆产生签名信息，所以只有原始的token才能于签名信息匹配。
这里有一个重要的实现细节。只有获取了私钥的应用程序（比如服务器端应用）才能完全认证token包含声明信息的合法性。所以，永远不要把私钥信息放在客户端（比如浏览器）。
OAuth2是什么？
相反，OAuth2不是一个标准协议，而是一个安全的授权框架。它详细描述了系统中不同角色、用户、服务前端应用（比如API），以及客户端（比如网站或移动App）之间怎么实现相互认证。
这里简单说一下涉及到的基本概念。
Client Types客户端类型这里的客户端主要指API的使用者。它可以是的类型：
Client Profile客户端描述OAuth2框架也指定了集中客户端描述，用来表示应用程序的类型：
Authorization Grants认证授权认证授权代表资源拥有者授权给客户端应用程序的一组权限，可以是下边几种形式：
从上边这些应该可以看出，OAuth2定义了一组相当复杂的规范。
搜索公众号程序员小乐回复“赚钱”，送你一份惊喜礼包。
使用HTTPS保护用户密码
在进一步讨论OAuth2和JWT的实现之前，有必要说一下，两种方案都需要SSL安全保护，也就是对要传输的数据进行加密编码。
安全地传输用户提供的私密信息，在任何一个安全的系统里都是必要的。否则任何人都可以通过侵入私人wifi，在用户登录的时候窃取用户的用户名和密码等信息。
社交登录的好处在很多情况下,使用用户在大型社交网站的已有账户来认证会方便。如果期望你的用户可以直接使用Facebook或者Gmail之类的账户,使用现有的库会方便得多。
结论
做结论前，我们先来列举一下 JWT和OAuth2的主要使用场景。另外，系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。
JWT使用场景
无状态的分布式API
JWT的主要优势在于使用无状态、可扩展的方式处理应用中的用户会话。服务端可以通过内嵌的声明信息，很容易地获取用户的会话信息，而不需要去访问用户或会话的数据库。
在一个分布式的面向服务的框架中，这一点非常有用。 但是，如果系统中需要使用黑名单实现长期有效的token刷新机制，这种无状态的优势就不明显了。
优势
快速开发 不需要cookie JSON在移动端的广泛应用 不依赖于社交登录 相对简单的概念理解
限制
Token有长度限制 Token不能撤销 需要token有失效时间限制(exp) OAuth2使用场景
在作者看来两种比较有必要使用OAuth2的场景：
外包认证服务器
上边已经讨论过，如果不介意API的使用依赖于外部的第三方认证提供者，你可以简单地把认证工作留给认证服务商去做。 也就是常见的，去认证服务商（比如facebook）那里注册你的应用，然后设置需要访问的用户信息，比如电子邮箱、姓名等。
当用户访问站点的注册页面时，会看到连接到第三方提供商的入口。用户点击以后被重定向到对应的认证服务商网站，获得用户的授权后就可以访问到需要的信息，然后重定向回来。
推荐一个 Spring Boot 基础教程及实战示例：
https://github.com/javastacks/spring-boot-best-practice
优势
快速开发 实施代码量小 维护工作减少
大型企业解决方案
如果设计的API要被不同的App使用，并且每个App使用的方式也不一样，使用OAuth2是个不错的选择。
考虑到工作量，可能需要单独的团队，针对各种应用开发完善、灵活的安全策略。当然需要的工作量也比较大！这一点，OAuth2的作者也指出过：
To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation. However, at the hands of most developers – as has been the experience from the past two years – 2.0 is likely to produce insecure implementations. hueniverse - OAuth 2.0 and the Road to Hell
优势
灵活的实现方式 可以和JWT同时使用 可针对不同应用扩展
参考：http://jwt.io - JWT官方网站，也可以查看到使用不同语言实现的库的状态。 http://oauth.net/2/ OAuth2官方网站, 也也可以查看到使用不同语言实现的库的状态。 OAuth 2 tutorials - Useful overview of how OAuth 2 works Oauth2 Spec issues Eran Hammer’s (推进OAuth标准的作者) views on what went wrong with the OAuth 2 spec process. Whatever your own opinion, good to get some framing by someone who understand’s key aspects of what make a security standard successful. Thoery and implemnetation: with Laravel and Angular Really informative guide to JWT in theory and in practice for Laravel and Angular.
上一篇好文：知名国产论坛，凉了！！！！
大家好，我是后端架构师。
本文会详细描述两种通用的保证API安全性的方法：OAuth2和JSON Web Token (JWT)
假设:
你已经或者正在实现API； 你正在考虑选择一个合适的方法保证API的安全性；
JWT和OAuth2比较？
要比较JWT和OAuth2？首先要明白一点就是，这两个根本没有可比性，是两个完全不同的东西。
JWT是一种认证协议 JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。 OAuth2是一种授权框架 另一方面，OAuth2是一种授权框架，提供了一套详细的授权机制（指导）。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。既然JWT和OAuth2没有可比性，为什么还要把这两个放在一起说呢？实际中确实会有很多人拿JWT和OAuth2作比较。标题里把这两个放在一起，确实有误导的意思。很多情况下，在讨论OAuth2的实现时，会把JSON Web Token作为一种认证机制使用。这也是为什么他们会经常一起出现。
JSON Web Token (JWT)
JWT在标准中是这么定义的：
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS). -RFC7519 https://tools.ietf.org/html/rfc7519
JWT是一种安全标准。基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证成功，会产生并返回一个Token（令牌），用户可以使用这个token访问服务器上受保护的资源。
一个token的例子:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
一个token包含三部分：
header.claims.signature
了安全的在url中使用，所有部分都 base64 URL-safe进行编码处理。
Header头部分头部分简单声明了类型(JWT)以及产生签名所使用的算法。
{ "alg" : "AES256", "typ" : "JWT"}
Claims声明
声明部分是整个token的核心，表示要发送的用户详细信息。有些情况下，我们很可能要在一个服务器上实现认证，然后访问另一台服务器上的资源；或者，通过单独的接口来生成token，token被保存在应用程序客户端（比如浏览器）使用。一个简单的声明（claim）的例子：
{ "sub": "1234567890", "name": "John Doe", "admin": true}
Signature签名
签名的目的是为了保证上边两部分信息不被篡改。如果尝试使用Bas64对解码后的token进行修改，签名信息就会失效。一般使用一个私钥（private key）通过特定算法对Header和Claims进行混淆产生签名信息，所以只有原始的token才能于签名信息匹配。
这里有一个重要的实现细节。只有获取了私钥的应用程序（比如服务器端应用）才能完全认证token包含声明信息的合法性。所以，永远不要把私钥信息放在客户端（比如浏览器）。
OAuth2是什么？
相反，OAuth2不是一个标准协议，而是一个安全的授权框架。它详细描述了系统中不同角色、用户、服务前端应用（比如API），以及客户端（比如网站或移动App）之间怎么实现相互认证。
这里简单说一下涉及到的基本概念。
Client Types客户端类型这里的客户端主要指API的使用者。它可以是的类型：
Client Profile客户端描述OAuth2框架也指定了集中客户端描述，用来表示应用程序的类型：
Authorization Grants认证授权认证授权代表资源拥有者授权给客户端应用程序的一组权限，可以是下边几种形式：
从上边这些应该可以看出，OAuth2定义了一组相当复杂的规范。
搜索公众号程序员小乐回复“赚钱”，送你一份惊喜礼包。
使用HTTPS保护用户密码
在进一步讨论OAuth2和JWT的实现之前，有必要说一下，两种方案都需要SSL安全保护，也就是对要传输的数据进行加密编码。
安全地传输用户提供的私密信息，在任何一个安全的系统里都是必要的。否则任何人都可以通过侵入私人wifi，在用户登录的时候窃取用户的用户名和密码等信息。
社交登录的好处在很多情况下,使用用户在大型社交网站的已有账户来认证会方便。如果期望你的用户可以直接使用Facebook或者Gmail之类的账户,使用现有的库会方便得多。
结论
做结论前，我们先来列举一下 JWT和OAuth2的主要使用场景。另外，系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。
JWT使用场景
无状态的分布式API
JWT的主要优势在于使用无状态、可扩展的方式处理应用中的用户会话。服务端可以通过内嵌的声明信息，很容易地获取用户的会话信息，而不需要去访问用户或会话的数据库。
在一个分布式的面向服务的框架中，这一点非常有用。 但是，如果系统中需要使用黑名单实现长期有效的token刷新机制，这种无状态的优势就不明显了。
优势
快速开发 不需要cookie JSON在移动端的广泛应用 不依赖于社交登录 相对简单的概念理解
限制
Token有长度限制 Token不能撤销 需要token有失效时间限制(exp) OAuth2使用场景
在作者看来两种比较有必要使用OAuth2的场景：
外包认证服务器
上边已经讨论过，如果不介意API的使用依赖于外部的第三方认证提供者，你可以简单地把认证工作留给认证服务商去做。 也就是常见的，去认证服务商（比如facebook）那里注册你的应用，然后设置需要访问的用户信息，比如电子邮箱、姓名等。
当用户访问站点的注册页面时，会看到连接到第三方提供商的入口。用户点击以后被重定向到对应的认证服务商网站，获得用户的授权后就可以访问到需要的信息，然后重定向回来。
推荐一个 Spring Boot 基础教程及实战示例：
https://github.com/javastacks/spring-boot-best-practice
优势
快速开发 实施代码量小 维护工作减少
大型企业解决方案
如果设计的API要被不同的App使用，并且每个App使用的方式也不一样，使用OAuth2是个不错的选择。
考虑到工作量，可能需要单独的团队，针对各种应用开发完善、灵活的安全策略。当然需要的工作量也比较大！这一点，OAuth2的作者也指出过：
To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation. However, at the hands of most developers – as has been the experience from the past two years – 2.0 is likely to produce insecure implementations. hueniverse - OAuth 2.0 and the Road to Hell
优势
灵活的实现方式 可以和JWT同时使用 可针对不同应用扩展
参考：
http://jwt.io - JWT官方网站，也可以查看到使用不同语言实现的库的状态。 http://oauth.net/2/ OAuth2官方网站, 也也可以查看到使用不同语言实现的库的状态。 OAuth 2 tutorials - Useful overview of how OAuth 2 works Oauth2 Spec issues Eran Hammer’s (推进OAuth标准的作者) views on what went wrong with the OAuth 2 spec process. Whatever your own opinion, good to get some framing by someone who understand’s key aspects of what make a security standard successful. Thoery and implemnetation: with Laravel and Angular Really informative guide to JWT in theory and in practice for Laravel and Angular.
最后，整理了100多套项目，赠送读者。扫码下方二维码，后台回复【赚钱】即可获取。
PS：如果觉得我的分享不错，欢迎大家随手点赞、转发、在看。
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
最后，整理了100多套项目，赠送读者。扫码下方二维码，后台回复【赚钱】即可获取。
PS：如果觉得我的分享不错，欢迎大家随手点赞、转发、在看。
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
END
最近面试BAT，整理一份面试资料《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。在这里，我为大家准备了一份2021年最新最全BAT等大厂Java面试经验总结。
别找了，想获取史上最全的Java大厂面试题学习资料
扫下方二维码回复「面试」就好了
历史好文：
扫码关注“后端架构师”，选择“星标”公众号
别找了，想获取史上最全的Java大厂面试题学习资料
扫下方二维码回复「面试」就好了
历史好文：
扫码关注“后端架构师”，选择“星标”公众号