去年年初做项目的时候接触到了OAuth认证，当时是选用了一个opensource的叫做KeyCloak的产品。项目中学到了很多关于认证的知识，之后一直想简单做下总结来着，后来一直拖了快一年。这几天又重新拾起来。可是，等自己查阅了几篇文章开始着手写的时候，才发现我对于OAuth和OpenIdConnect的理解实在是太浅薄了。 我知道想要深入理解和掌握OAuth 和OpenIdConnect自己还有相当大的距离，现在姑且只把我之前学到的东西总结一下，只当是自己的学习笔记了。 提到认证，可能最先想到的就是账号密码的认证方式。例如BASIC认证，在web服务器端设置好账号密码后可以应用到所有的http请求页中。但是，它的缺点非常显而易见： ・每次请求都需要输入账号密码 ・每次通信内容中都有账号密码的信息，信息泄漏的危险性很大 因为传统账号密码认证方式的诸多缺点，web服务大部分都使用了如下方式： 只在第一次登陆的时候提交账号密码，然后把认证完了的状态存放在session里面，client通过把session_id传递给服务器，服务器就可以判定请求来自于谁，以及是不是经过认证了。 这种认证方式里面已经开始出现了认证和认可的概念了。认证是判定请求来自于谁。而认可是判定是不是经过认证了。 (据说认证和认可就是OAuth和OpenIdConnect的区别) 上面的方式基本实现了认证和认可的功能，但是后来出现了稍微复杂的情况：如何能在多个服务器之间共享认证和认可的信息。例如如何用QQ号登陆百度就是一个很典型的例子。 这种情况下就需要用到OAuth认证方式了，先简单概括一下： QQ拥有用户信息，负责认证，拿QQ号登录成功以后，QQ将认可状态交付给百度，百度记录下认证状态，然后就可以访问百度的服务了(也就是说百度负责认可)。 具体的认证过程可以参照下面的图示： ※本图来自于 http://www.atmarkit.co.jp/ 在这个流程中有那么几个关键词需要解释一下： ・client_id、secrect 由调用的service provider(上面例子中的QQ服务器端)发行的用来识别client(百度)的信息。一般来说，secret不用每次都发送。 ・code 认可代码，用户认证完毕以后，由service provider返回的代码，受到认可代码就可以判定认证OK了。 ・access_token 认证完毕以后，如果想要调用service
