jwt oauth2 对接_F5社区好文推荐：NGINX与oAuth2/OIDC系列一

林静

F5软件方向解决方案架构师，历任 F5 Global Service ENE，APAC Professional Service 顾问，技术专家。拥有超过10多年的应用交付领域工作经验，秉承持续学习和反馈的理念，致力于现代应用体系下的应用服务研究。CNCF Kubernetes CKA 664号认证获得者，中国首位F5 Security Solution Expert 认证获得者。

如今的互联网已经渗透了各种各样的生活与业务场景，就像人们在现实生活中从来不是一个简单的个体，我们需要有很多的复杂的关系网络。互联网的应用也是如此，如今很难看到有哪一个应用能做到完全的独立发展而不与其周边发生关系。所以在今天应用都非常讲究自己的生态，合纵连横，彼此之间需要大量的信息共享。这些复杂的关系就带来了一个非常重要的问题：身份认证、资源授权、账号维护。当然还有API的认证访问控制。

举个栗子，在你的日常生活中，你可能需要使用数十个APP, 这些APP各自拥有独立的账号密码，你就需要维护不同的这些账号与密码，你可能为了省事，所有app一套账号密码，于是当应用A被暴库之后，你就被迫把这数十个APP的账号密码全部修改一遍。你也可能会更加在意自己的账号安全，于是你把数十个APP的账号采用一个固定+变化的密码来组合，这很不错，可以帮助缓解很大一部分安全问题，同时又减少自己密码维护的问题（记忆力还好吗），但是这些APP可能不一定如你所愿能够都按照你自己设想的固定+变化的模式，有的可能只支持数字，有的则支持数字加密码，有的则还要求最低长度和更复杂的组合，于是你又开始用小本本记录不同应用的密码格式（嗯，至少曾有那么一阶段我确实是这么干的，用一段描述语言记录在电脑里，当忘记的时候，就去查找电脑里的这个hint）。

►有没有更好的方法？

如果你非常信任一家安全做的好、信誉体系也很好的公司，那么是否可以用这一个账号横行互联网？相信我们已经有了答案，在今天，我们可能很多时候已经在这么用了，当你登录某某应用，你习惯的跳过用户注册而是去点击"使用***登录"，在弹出的界面里非常神圣的点下"同意"。于是你不再需要去记忆那么多的应用账号。这其实就是典型的开放式授权（Open Authorization）简称oAuth（当前版本为2，也称oAuth2)。

额，你好像在骗我，你说了那么多好像都是关于验证，怎么这里又说是授权Authorization。是的，你说的没错，不过我也没有骗你，只是这里有一些傻傻不好分清的问题，这个oAuth设计的本意是用来解决垮利益团体之间的数据访问问题，就像我们开篇说的那样，不同的公司的应用之间有大量数据的相互访问问题，比如 A公司开发了一个在线照片打印应用，可是这个公司并不经营照片存储服务，你的照片可能存在B、C、D这些不同公司的网盘上（是的，早期为了占便宜，我确实占了好多公司的网盘，后来他们有些网盘耍流氓发个通知就说不干了。。，算了反正是白piao，还好我采用的是RAID1), 所以这就带来了问题，你怎么把照片给这个在线打印公司，从BCD网盘下载下来发给他们？把网盘的账号密码给打印公司？显然这些方式都不行，如果靠下载上传，估计你就懒得弄了，如果是给账号密码，除非你不清醒。

而对于打印公司以及网盘服务商来说，他们也有类似的烦恼࿰