OAuth2有三个重要的Endpoint，其中授权Endpoint、Token Endpoint节点在授权服务器中，还有一个可选的重定向Endpoint在客户端中。
- 授权Endpoint：使用授权Endpoint去获取资源Owner的授权
- Token Endpoint：客户端获取token
- 重定向Endpoint：授权服务器使用重顶线Endpoint返回授权相应给客户端（是这样的么，感觉有点奇怪）
20210915后续
经过继续对OAuth2的学习，我对这些Endpoint有稍微深入一点的理解，现整理如下：
-
OAuth2授权服务器一定要提供一个多个用于用户录入自己账号和密码的表单，为什么可能是多个，我觉得在生产环境中，我们可能会提供许多不同样式的页面，这些不同样式的页面最终会将用户录入的数据Post到同一个登录接口。
-
OAuth2授权服务器提供的登录接口，会验证表单中的数据，如果验证通过了，会让浏览器重定向到Client的某个接口（这个接口由Client重定向到OAuth2授权服务器时提供的，具体参考该协议），在这次重定向的过程中，OAuth2授权服务器会将授权码通过code参数告知给Client。
-
Client拿到授权码，访问OAuth2授权服务器的Token结构，获取到AccessToken，所以OAuth2授权服务器还需要提供一个接口，将授权码转换成AccessToken。
截止到目前，我只理清楚了需要的接口，还没有理清楚每个接口背后的逻辑，现在开始理一理每个接口到底该怎么设计和实现。
获取登录界面的接口
这个接口比较简单，客户端服务器指导浏览器重定向到授权服务器的接口，这个接口会返回一个登录页面，用户在这个页面填写用户凭证提交给授权服务器的登录接口。
在具体实现上，我看QQ、微博等都是自己提供了一个登录页面，如果OAuth2仅在企业内部做单点登录用，我觉得可以根据不同的需求返回不同样式的登录页面，比如提供一个A产品线的登录接口、B产品线的登录接口，实际上这两个登录接口都将用户凭证提交到同一个登录接口。
这个获取登录页面的接口还需要其他的逻辑么？我看到一份Demo中将用户提交的RedirectUrl放在了Session中，我猜到了下一步在登录接口中会怎么做，它会从Session中取出这个RedirectUrl，然后指导浏览器重定向到这个RedirectUrl，并带着计算处理的Code码。实际上，我觉得没有必要这么做，完全可以将这些参数放到页面中，然后通过页面一起提交给登录接口，这样还避免了拥有多个授权服务器时需要进行数据的同步等。
如果这个获取登录界面的接口的作用仅仅是返回一个页面，用户用户填写用户凭证，我们一定需要使用模板渲染技术实现么，我其实并不是很喜欢模板渲染技术，因为这个技术会让我不得不再去关注一些页面渲染层面的东西。或许可以直接将这个Url指向一个静态页面，然后在静态页面中获取Url中的请求参数，然后在访问登录接口时，将这些Url中的请求参数传递给登录接口。
上面的想法是肯定可行的，甚至在实践中我们可以有一些更骚的应用，我们直接将A产品线的登录页面的登录接口换成授权服务器的登录接口，然后开始走OAuth的各个流程。
但是现在的问题时，如何实现单点登录？如果使用静态网页，或者直接嵌入到某个产品线的登录页面，我们就没有办法通过登录页面的域名实现单点登录，我们各个产品线每次都需要重新登录，整套系统又退化到了普通的登录系统。
我打算目前就简单化处理这个问题，就使用模板技术渲染技术渲染出登录页面吧。
登录接口
登录接口核心目标是验证用户的用户凭证，生成授权码，并指导浏览器重定向到客户端服务器的某个接口。这个过程中需要明白一个点：客户端服务器稍后的时候会通过授权码获取AccessToken，所以生成的授权码需要被我们缓存起来。