客户端
-
任意一个接口A，这个接口模拟用户没有登录（授权）的情况，将用户重定向到OAuth授权服务器，进行登录（授权）。接口A需要记录下自己传递的自身的重定向地址，这个重定向地址就是接口B（如果使用过滤器实现，则为当期请求的地址，因为是Demo性质的，所以只需要知道有这些细节就好了），因为稍后客户端通过授权码获取收取AccessToken的时候，需要再将这个重定向地址传递给OAuth2授权服务器。接口A同时需要传递state值，并记录state值。
-
任意一个接口B，这个接口用来处理授权服务器通过重定向传递的code参数。拿到code参数后，请求授权服务器的AccessToken端点，获取AccessToken时需要传递接口A中记录的重定向地址，这块就是接口B本身。接口B需要验证获取的state值是否正确。
-
任意一个接口C，在这个接口中客户端向资源服务器请求资源，请求的过程中需要带上接口B获取到的AccessToken。
-
任意一个接口D，在这个接口中模拟用户的AccessToken过期了，然后通过刷新令牌重新获取AccessToken。
服务端
资源服务器
- 在过滤器A中，需要通过Authoriztion、表单参数、查询参数完成AccessToken的验证。资源服务器和授权服务器链接的是同一个数据库，所以资源服务器可以直接从数据库中检索出授权服务器插入的AccessToken（这部分不适用于生产）
补充知识
-
另外，为什么在这个请求中包含redirect_uri？毕竟此处是不需要执行重定向的。根据OAuth规范，如果在授权请求中指定了重定向URI，那么令牌请求中也必须包含该重定向URI。这可以防止攻击者使用被篡改的重定向URI获取受害用户的授权码，让并无恶意的客户端将受害用户的资源访问权限关联到攻击者账户。
-
有一点我好像理解错了，客户端指导浏览器重定向到授权服务器授权页面时传递的redirectUrl是不可以随便传递的，因为授权服务器要对比该值与客户端注册时使用的redirectUrl是否一致，从而判断clientId值是否被篡改。那么问题就来了，客户端如何在完成授权后重新访问之前的页面（我觉得我对OAuth使用场景理解的还不够）。
-
OAuth规范允许在一个客户端注册信息中包含多个redirectUri值，这样就可以让客户端在不同场景下使用不同的URL提供服务，有利于功能的聚合。
疑惑
- 假设我访问客户端的A接口，这个接口是获取某个页面的接口，这个接口发现我并未登录，所以将我重定向授权页面，重定向到授权页面时传递的redirectUrl必须是我注册客户端时填写的redirectUrl，这儿我可以理解为一个客户端接受授权码的Url。授权完成后，浏览器将重定向到该redirectUrl，客户端因此接受到授权码完成接下来的一系列工作。再之后，这个接口该怎么做？我觉得应该再次重定向到之前用户访问的Url（我对OAuth研究的还不够，还需要细细的去体会这些细节）。