转载地址：https://blog.csdn.net/qq_39089301/article/details/80615348
这篇文章前两种方式说的十分清晰，但是第三种方式，基于重定向实现奠定登录，介绍的比较笼统。如下
通过页面重定向的方式
最后一种介绍的方式，是通过父应用和子应用来回重定向中进行通信，实现信息的安全传递。
父应用提供一个GET方式的登录接口，用户通过子应用重定向连接的方式访问这个接口，如果用户还没有登录，则返回一个的登录页面，用户输入账号密码进行登录。如果用户已经登录了，则生成加密的Token，并且重定向到子应用提供的验证Token的接口，通过解密和校验之后，子应用登录当前用户。
这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，但是并没有前面两种方式方便。
其实并没有父子系统的这个概念。校验登录的系统，和客户要访问的系统，并不一定是父子关系，可以是评级关系，甚至两个系统间的token都可以不一样。
而且，在用户已登录的情况下，再次登录校验，是如何把用户信息带到登录校验系统的也没有说清楚。以下是本人自己的理解。
首先假设进行登录校验的系统是A，用户想要访问的系统是B。
一.还没有登陆的情况。
1.用户要访问B系统，然后B系统发现用户没有登录
2.重定向到A系统进行登录校验
3.A系统发现用户没有进行登录，返回A系统的登录页面。
4.用户输入用户信息进行登录。
5.用户在A系统登录成功（注意，此时浏览器就会保存用户在A系统的登录信息）
6.（带着A系统的Token（也可以不是A系统的Token，只要是用户校验后的相关信息就可以））重定向到用户要访问的B系统。（此时B系统可以直接重用A系统的Token，也可以先解析A系统的Token，通过用户信息生成B系统的Token）
二.用户已经在A系统进行过登录
1.用户要访问B系统，然后B系统发现用户没有登录
2.重定向到A系统进行登录校验（因为用户已经在A系统登录过，所以浏览器中肯定存在用户在A系统中的登录信息，Token，或者Cookie等，此时由于重定向，浏览器会自动带上这些信息）
3,A系统校验成功（带着A系统的Token（也可以不是A系统的Token，只要是用户校验后的相关信息就可以））重定向到用户要访问的B系统。（此时B系统可以直接重用A系统的Token，也可以先解析A系统的Token，通过用户信息生成B系统的Token）