㈠ 前端单点登录如何实现
单点登录的思路是这样的，假定有个两个系统，A系统登录一次后，再访问B系统时是不需要登录的，当访问B系统时，就去登录系统判断是否有效，如果登录系统放行了，说明是已经登录过的。所以，需要建一个登录系统，从登录系统引出是否登录的判断，那么不管是哪个系统在访问需要验证是否登录的时候都去验证登录系统。
㈡ 不懂前后端分离这篇就够
前后端分离前我们的开发协作模式一般是这样的：
前端写好静态的HTML页面贺扮交付给后端开发。静态页面可以本地开发，也无需考虑业务逻辑只需要实现View即可。
后端使用模板引擎去套模板，同时内嵌一些后端提供的模板变量和一些逻辑操作。
然后前后端集成对接，遇到问题，前台返工，后台返工。
然后在集成，直至集成成功。
这种模式的问题
在前端调试的时候要安装完整的一套后端开发工具，要把后端程序完全启动起来。遇到问题需要后端开发来帮忙调试。我们发现前后端严重耦合，还要要求后端人员会一些HTML，JS等前端语言。前端页面里还嵌入了很多后端的代码。一旦后端换了一种语言开发，简直就要重做。
像这种增加了大量的沟通成本，调试成本等，而且前后端的开发进度相互影响，从而大大降低了开发效率。
前后端分离并不只是开发模式，而是web应用的一种架构模式。在开发阶段，前后端工程师约定好数据交互接口，实现并行开发和测试；在运行阶段前后端分离模式需要对web应用进行分离部署，前后端之前使用HTTP或者其他协议进行交互请求。
1. 客户端和服务端采用RESTFul API的交互方式进行交互
2. 前后端代码库分离
在传统架构模式中，前后端代码存放于同一个代码库中，甚至是同一工程目录下。页面中还夹杂着后端代码。前后端工程师进行开发时，都必须把整个项目导入到开发工具中。
前后端代码库分离，前端代码中有可以消芦进行Mock测试(通过构造虚拟测试对 象以简化测试环境的方法)的伪后端，能支持前端的独立开发和测试。而后端代码中除了功能实现外，还有着详细的测试用例，以保证API的可用性，降低集成风险。
3. 并行开发
在开发期间前后端共同商定好数据接口的交互形式和数据格式。然后实现前后端的并行开发，其中前端工程师在开发完成之后可以独自进行mock测试，而后端也可以使用Postman等接口测试软件进行接口自测，然后前后端一起进行功能联调并校验格式，最终进行自动化测试。
分离后，开发模式是这样的
为优质产品打造精益团队
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。
提升开发效率
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
完美应对复杂多变的前端需求
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。
增强代码可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
使用了前后端分离架构后，除了开发模式的变更，我们在开发的过程中还会遇到哪些问题呢？我们接着往下看。
我们先来看看传统开发，我们是如何进行用户认证的
前端登录，后端根据用户信息生成一个jsessionid，并保存这个 jsessionid 和对应的用户id到Session中，接着把 jsessionid 传给用户，存入浏览器 cookie，之后浏览器请求带上这个cookie，后端根据这个cookie值来查询用户，验证是否过期。
HTTP有一个特性：无状态的，就是前后两个HTTP事务它们并不知道对方的信息。而为了维护会话信息或用户信息，一般可用Cookie和Session技术缓存信息。
- Cookie是存储在客户端的
- Session是存储在服务端的
但这样做问题就很多，拿拍带如果我们的页面出现了 XSS 漏洞，由于 cookie 可以被 JavaScript 读取，XSS 漏洞会导致用户 token 泄露，而作为后端识别用户的标识，cookie 的泄露意味着用户信息不再安全。尽管我们通过转义输出内容，使用 CDN 等可以尽量避免 XSS 注入，但谁也不能保证在大型的项目中不会出现这个问题。
在设置 cookie 的时候，其实你还可以设置 httpOnly 以及 secure 项。设置 httpOnly 后 cookie 将不能被 JS 读取，浏览器会自动的把它加在请求的 header 当中，设置 secure 的话，cookie 就只允许通过 HTTPS 传输。secure 选项可以过滤掉一些使用 HTTP 协议的 XSS 注入，但并不能完全阻止。
httpOnly 选项使得 JS 不能读取到 cookie，那么 XSS 注入的问题也基本不用担心了。但设置 httpOnly 就带来了另一个问题，就是很容易的被 XSRF，即跨站请求伪造。当你浏览器开着这个页面的时候，另一个页面可以很容易的跨站请求这个页面的内容。因为 cookie 默认被发了出去。
解决方案
JWT（Json Web Token）
JWT 是一个开放标准(RFC 7519)，它定义了一种用于简洁，自包含的用于通信双方之间以 JSON 对象的形式安全传递信息的方法。该信息可以被验证和信任，因为它是数字签名的。JWTS可以使用秘密（使用HMAC算法）或公钥/私钥对使用RSA或ECDSA来签名。
- 简洁(Compact)：可以通过URL, POST 参数或者在 HTTP header 发送，因为数据量小，传输速度快。
- 自包含(Self-contained)：负载中包含了所有用户所需要的信息，避免了多次查询数据库。
JWT 组成
JWT由3个子字符串组成，分别为Header，Payload以及Signature，结合JWT的格式即：Header.Payload.Signature。（Claim是描述Json的信息的一个Json，将Claim转码之后生成Payload）。
Header
Header是由下面这个格式的Json通过Base64编码（编码不是加密，是可以通过反编码的方式获取到这个原来的Json，所以JWT中存放的一般是不敏感的信息）生成的字符串，Header中存放的内容是说明编码对象是一个JWT以及使用“SHA-256”的算法进行加密（加密用于生成Signature）
- 头部包含了两部分，token 类型和采用的加密算法
- Base64是一种编码，也就是说，它是可以被翻译回原来的样子来的。它并不是一种加密过程。
Payload
Payload是通过Claim进行Base64转码之后生成的一串字符串，Claim是一个Json，Claim中存放的内容是JWT自身的标准属性，所有的标准属性都是可选的，可以自行添加，比如：JWT的签发者、JWT的接收者、JWT的持续时间等；同时Claim中也可以存放一些自定义的属性，这个自定义的属性就是在用户认证中用于标明用户身份的一个属性，比如用户存放在数据库中的id，为了安全起见，一般不会将用户名及密码这类敏感的信息存放在Claim中。将Claim通过Base64转码之后生成的一串字符串称作 Payload 。
Signature
Signature是由Header和Payload组合而成，将Header和Claim这两个Json分别使用Base64方式进行编码，生成字符串Header和Payload，然后将Header和Payload以Header.Payload的格式组合在一起形成一个字符串，然后使用上面定义好的加密算法和一个密匙（这个密匙存放在服务器上，用于进行验证）对这个字符串进行加密，形成一个新的字符串，这个字符串就是 Signature 。
签名的目的： 最后一步签名的过程，实际上是对头部以及负载内容进行签名，防止内容被窜改。如果有人对头部以及负载的内容解码之后进行修改，再进行编码，最后加上之前的签名组合形成新的JWT的话，那么服务器端会判断出新的头部和负载形成的签名和JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名，在不知道服务器加密时用的密钥的话，得出来的签名也是不一样的。
三个部分通过.连接在一起就是我们的 JWT 了：
JWT认证
服务器在生成一个JWT之后会将这个token发送到客户端机器，在客户端再次访问受到JWT保护的资源URL链接的时候，服务器会获取到这个token信息，首先将Header进行反编码获取到加密的算法，在通过存放在服务器上的密匙对Header.Payload 这个字符串进行加密，比对token中的Signature和实际加密出来的结果是否一致，如果一致那么说明该token是合法有效的，认证成功，否则认证失败。
JWT使用总结
1. 首先，前端通过Web表单将自己的用户名和密码发送到后端的接口。这一过程一般是一个HTTP POST请求。建议的方式是通过SSL加密的传输（https协议），从而避免敏感信息被嗅探。
2. 后端核对用户名和密码成功后，将用户的id等其他信息作为JWT Payload（负载），将其与头部分别进行Base64编码拼接后签名，形成一个JWT。形成的JWT就是一个形同lll.zzz.xxx的字符串。
3. 后端将JWT字符串作为登录成功的返回结果返回给前端。前端可以将返回的结果保存在Cookie或localStorage或sessionStorage上，退出登录时前端删除保存的JWT即可。
4. 前端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)
5. 后端检查是否存在，如存在验证JWT的有效性。例如，检查签名是否正确；检查Token是否过期；检查Token的接收方是否是自己（可选）。
6. 验证通过后后端使用JWT中包含的用户信息进行其他逻辑操作，返回相应结果。
JWT和Session方式存储id的差异
Session方式存储用户id的最大弊病在于Session是存储在服务器端的，所以需要占用大量服务器内存，对于较大型应用而言可能还要保存许多的状态。一般而言，大型应用还需要借助一些KV数据库和一系列缓存机制来实现Session的存储。
而JWT方式将用户状态分散到了客户端中，可以明显减轻服务端的内存压力。除了用户id之外，还可以存储其他的和用户相关的信息，例如该用户是否是管理员、用户所在的分组等。虽说JWT方式让服务器有一些计算压力（例如加密、编码和解码），但是这些压力相比磁盘存储而言可能就不算什么了。
单点登录
Session方式来存储用户id，一开始用户的Session只会存储在一台服务器上。对于有多个子域名的站点，每个子域名至少会对应一台不同的服务器，例如：
www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。所以如果要实现在login.taobao.com登录后，在其他的子域名下依然可以取到Session，这要求我们在多台服务器上同步Session。使用JWT的方式则没有这个问题的存在，因为用户的状态已经被传送到了客户端。
当客户端和服务端分开部署到不同服务器的时候，就会遇到跨域访问的问题，是由浏览器同源策略限制的一类请求场景。
跨域解决方案有很多种，下面使用Nginx反向代理的方案
反向代理
代理访问其实在实际应用中有很多场景，在跨域中应用的原理做法为：通过反向代理服务器监听同端口，同域名的访问，不同路径映射到不同的地址，比如，在nginx服务器中，监听同一个域名和端口，不同路径转发到客户端和服务器，把不同端口和域名的限制通过反向代理，来解决跨域的问题：
㈢ 一个app项目单点登录，前端要做什么，后端要做什么。
前端需要做你那个用户姓名，密码一些验证什么的，然后有前端打包数据到后再去处理，进行逻辑判断就可以了。
㈣ 单点登录的几种实现方案
用户已经登录企业门户的前提下，单点登录到门户中的应用。门户与应用的域名有一定关系，门户的域名是父级域，比如xxx.com，应用的域名为二级域，比如a.xxx.com、b.xxx.com、c.xxx.com
登录掘敬门户后埋扒，颁发一个token用于接口认判液慎证，创建一个key为_a，domain为.xxx.com，path为/，value为token的cookie并set-cookie到前端，访问其他应用时，由于_a的domain为其他应用域名的父级域，会自动带上_a到后端，后端根据_a做接口校验，获取用户信息等资源，实现单点登录。
用户已经登录企业门户的前提下，单点登录到门户中的应用。门户与应用的域名没有关系。
依旧使用上面的方案一，但是token使用header传输，不存在跨域问题
以上方案二，有一些细节需要注意
没有门户，或者用户不提前登录门户的前提下，不同应用实现单点登录。
CAS，网上教程众多，比如 CAS简介和整体流程 。
方案二实际上也是利用了CAS思想实现的，ticket和token，可以类比CAS的ST（Service Ticket）和TGC（Ticket Granted Cookie）。
㈤ 请问js如何设置单点登录
你可以将原系统的账号密码做成一个配置的json文件，
然后前端去访问这个文件，账号密码一一对应就可以了。
从第三方系统单点登录到目标系统，
第三方系统会发送token进行验证，通过解析token，
获取相应的用户信息的json串，将其set到自己系统的session中。
㈥ “浙里办“项目单点登录、埋点、二次回退的问题
大家可以看一看语雀 《“浙里办”h5微应用接入流程》森野 这篇文档。
接下来我将针对大多数人以及我个人遇到的一些问题做本篇文章的核心讲解：
1.单点登录，首先分为个人用户的单点登录和法人用户的单点登录：
个人单点登录分为app登录和支付宝小程序登录：
首先我们要判断当前环境是app环境还是支付宝小程序环境，然后跳转到不同的路径，个人用户登录我们采用的是直接跳转到前端页面，登录成功后会携带ticket等参数跳转到我们提供的路径，
法人的单点登录（app和小程序是一样的）：
由于法人登录跳转到页面时，用的是post请求访问，但是web页面只能通过get访问，所以法人登录我们采用的方法是将提供的跳转路径为后台服务地址，后台服务将登录成功后通过get方式重定向到前端页面并携带前端需要的参数，
2.二次回退的问题：
我发现大多数人都遇到了二次回退的问题，有很多人解决了二次回退的问题后又出现了其它各种奇奇怪怪的问题，以下是我们解决这个问题的办法：
window.performance.navigation.type 包含三个值：
0 : TYPE_NAVIGATE (用户通过常规导航方式访问页面，比如点一个链接，或者一般的get方式)
1 : TYPE_RELOAD (用户通过刷新，包括JS调用刷新接口等方式访问页面)
2 : TYPE_BACK_FORWARD (用户通过后退按钮访问本页面)
首先还是判断是浙里办app还是支付宝小程物春早序,根据不同的环境处理二次回退
解决app的二次回退问题，这个地方的逻辑是监听页面的跳转,判断当前页面是通过刷新或直接访问进入，还是通过返回进入。从而来判断是否是直接跳回app
解决支付宝小程序的二次回退问题，这个地方的逻辑是监听页面的跳转,判断当前页面是通过刷新或直接访问进入，还是通过返回进入。从而来判断是否是直罩雀接跳回浙里办小程序页面。
3.埋点，由于有些埋点是通过JSBridge API 获取的，而JSBridge API 的方法都是异步的，所以可能会存在埋点不成功的问题。：
埋点主要是采集应用app的信息,日志，用户信息和地理位置等信息
web 端通用采集 SDK： https://d.alicdn.com/alilog/mlog/aplus.js?id=202951085
使用vue开发的，这一段要写在埋点页面的script里面，尽量不要放在vue实例中，也不要放在index.html中，否则可能会存在埋点不成功的问题
㈦ java web应用如何实现单点登录
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。实现单点登录需要两个部分的合作：统一的身份认证服务和修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。
㈧ 前端登陆实现
四种方式
Cookie 出现的原因： HTTP 协议是无状态的，每次请求都会建立一个新的链接，请求结束就会断开链接，优点就是可以节省链接资源，缺点就是无法保存用户状态。Cookie 的出现就是为了解决这个问题。
Cookie 是存储在浏览器中的，可以通过 Js 和 set-cookie 这个响应字段来进行设置。
cookie 的限制：
有了 cookie 之后，服务端就可以从客户端获取到信息，如果需要对信息进行验证，那么还需要 session
服务端在收到客户端的请求之后，会在服务器中开辟一片内存空间来存放 session
第一次登陆之后，下次再访问的时候就会携带这个 cookie，服务端就可以根据 sessionId 进行验证用户是否登陆（判断这个 sessionId 和服务端保存的 sessionId 是否一致，是否有这个 sessionId 的记录或者记录是否有效）
客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。
Token 是 服务器 生成的一个字符串，作为客户端请求的一个令牌。第一次登陆之后，服务器会生成一个 Token 返回给客户端，客户端后续访问的时候，只需带上这个 Token 进行身份认证
缺点
JWT（Json Web Token）
服务端不需要存储 Token 那么服务端是怎么验证客户端传递过来的 Token 是否有效的呢？
答案：
Token 并不是杂乱无章的字符串，而是通过多种算法拼接而成的字符串
header 部分指定了这个 Token 所使用的签名算法
payload 部分表明了这个 JWT 的意图
signature 部分为 JWT 的签名，主要是为了让 JWT 不被随意的篡改
签名的部分有两个步骤
一：
二:
最后的 Token 计算如下：
单点登陆指的是公司会搭建一个公共的认证中心，公司里的所有产品的认证都可以在这个认证中心中完成，一个产品在认证中心认证之后，再去访问其他产品时就不需要再次认证
这个时候，由于 a.com 存在已登录的 Cookie 信息，所以服务器端直接认证成功。
这个时候由于认证中心存在之前登陆过的 cookie，所以不需要再输入账号密码，直接从第四步开始执行
目前我们已经完成了单点登录，在同一套认证中心的管理下，多个产品可以共享登录态。现在我们需要考虑退出了，即：在一个产品中退出了登录，怎么让其他的产品也都退出登录？
原理也不难，其实就是在携带 ticket 去请求认证中心的时候，再去请求一下认证中心的退出登陆的 api 即可
当某个产品 c.com 退出登陆时
sso 就是一个集中地验证系统。你项目内请求时，向 sso 发一个请求，他给你个 token 你扔到游览器缓存里，请求的时候放在请求头里带着。和其他验证接口一样。 他好就好在，一个账号在不同系统里都可以登录，因为不同项目可以共用这个 token。并且通过 sso 集中管理一些用户信息，你可以方便的拿用户信息。
以微信为例子
㈨ 一个app项目单点登录，前端要做什么，后端要做什么。
前端需要做你那个用户姓名，密码一些验证什么的，然逗橡野后有山喊前如春端打包数据到后再去处理，进行
逻辑判断
就可以了。