Oauth2详解

做过几次Oauth2的对接，不管是服务端还是客户端都有一些经验，和大家分享。

一、Oauth2的含义

这个百度都有，就不阐述了，前身是Oauth，我的理解呢就是，很简单。一个例子，大家都用过qq或者微信，你登录其他web、客户端或者app的时候，有很多都会提示你是否用微信登录或者qq登录，我理解这个就是oauth2的过程，互信，兼容其他的sso

二、Oauth2的步骤，三次握手，大家应该都知道。

2.1  第一次握手

从A访问B，B发现了请求来源于A，那么通过web端重定向到A的第一次握手地址附上自己的授权码和重定向地址。

A知道了B正在问他，我能用的登录信息登录吗。

A一看，自己已经登录，并且B使用了自己给他的授权码，那ok，于是又给他返回了一个临时授权码，从web端重新定向到B的地址

2.2 第二次握手

B一看A给了自己临时的授权码，那B应该是已经登录了

B按照当时A给的秘钥还有第二次握手地址，通过服务器向A发起了消息请求，一般这个接口都是http的post请求，当时接口和协议都不重要，理念重要

A通过接口知道了，B用了刚才的授权码，秘钥也正确是本人，那么告诉你真实的秘钥吧，于是给B返回了token

2.3 第三次握手

B拿到了真实的token，心里想着，A应该是已经认可我了，那么快告诉我你到底是谁吧

B再次向A发送了请求，附带了自己的token

A接受请求后，返回当前登录的纳税人信息。

三、Oauth实现方案

3.1 服务端

服务端首先要有一张代码表，记录颁发出去的客户端标识和秘钥

然后要提供三个http接口，一个是浏览器的页面接口，两个服务器的http接口或者其他接口

接口一：浏览器访问，便于服务端记录当前会话，知道登录的人是谁，然后存入数据库或者缓存，返回值应该是客户端提供的重定向地址页面和临时授权码

接口二：提供一个临时授权码换取真实token的接口，其实就是校验客户端标识和秘钥是否正确，返回token

接口三：提供token换取真实登录人信息的接口，查询登录人信息。

3.2 客户端

客户端也有有表或者参数记录，标识和秘钥

然后需要一个拦截器，针对于服务端来源的请求，走oauth2校验

然后就是不断的接口交互发送请求，很简单

四、会话一致性

一般都是服务端保持会话一致性，这个看实际要求。

其实就是两种方案，

一种是接口传递，AB互相通知，我这儿已经注销了，你看看你那边需要注销不，这种一般都是存在负载，并且有session共享

一种是页面重定向或者iframe，在服务端的退出页面调用B服务的退出页面

文档就不上传了，有需要的可以给我留言。