⑴ 一个app项目单点登录，前端要做什么，后端要做什么。
前端需要做你那个用户姓名，密码一些验证什么的，然逗橡野后有山喊前如春端打包数据到后再去处理，进行
逻辑判断
就可以了。
⑵ 请问js如何设置单点登录
你可以将原系统的账号密码做成一个配置的json文件，
然后前端去访问这个文件，账号密码一一对应就可以了。
从第三方系统单点登录到目标系统，
第三方系统会发送token进行验证，通过解析token，
获取相应的用户信息的json串，将其set到自己系统的session中。
⑶ 一个app项目单点登录，前端要做什么，后端要做什么。
前端需要做你那个用户姓名，密码一些验证什么的，然后有前端打包数据到后再去处理，进行逻辑判断就可以了。
⑷ 前端单点登录如何实现
单点登录的思路是这样的，假定有个两个系统，A系统登录一次后，再访问B系统时是不需要登录的，当访问B系统时，就去登录系统判断是否有效，如果登录系统放行了，说明是已经登录过的。所以，需要建一个登录系统，从登录系统引出是否登录的判断，那么不管是哪个系统在访问需要验证是否登录的时候都去验证登录系统。
⑸ 前端登陆实现
四种方式
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 集中管理一些用户信息，你可以方便的拿用户信息。
以微信为例子
⑹ ant design pro对接SSO单点登录
公司的SSO采用CAS机制，机制说明： https://www.jianshu.com/p/083c0597e7e0
ant design pro接入SSO时，也册晌宏踩了一些坑
一谨仔、应用服务端
服务端使用了spring boot，spring boot跟CAS的整合可以参考文档： https://blog.csdn.net/jw314947712/article/details/54236216
二、前端
这里有几个坑需要注意：
1、ajax请求返回SSO登录页面，需要修改跳转模式为手动跳转。
2、由于SSO域名与前端域名不同，ajax请求结果并不会出现302返回码。
修改utils下面的request.js文件，设置跳转模式为手动跳转
然后在response里面拦州册截
⑺ 鉴权必须了解的 5 个兄弟：cookie、session、token、jwt、单点登录
本文你将看到：
**“前端存储”**这就涉及到一发、一存、一带，发好办，登陆接口直接返回给前端，存储就需要前端想办法了。
前端的存储方式有很多。
有，cookie。cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，借助 HTTP 头、浏览器能力，cookie 可以做到前端无感知。一般过程是这样的：
“配置：Domain / Path”
cookie 是要限制::“空间范围”::的，通过 Domain（域）/ Path（路径）两级。
“配置：Expires / Max-Age”
cookie 还可以限制::“时间范围”::，通过 Expires、Max-Age 中的一种。
“配置：Secure / HttpOnly”
cookie 可以限制::“使用方式”::。
**“HTTP 头对 cookie 的读写”**回过头来，HTTP 是如何写入和传递 cookie 及其配置的呢？HTTP 返回的一个 Set-Cookie 头用于向浏览器写入“一条（且只能是一条）”cookie，格式为 cookie 键值 + 配置键值。例如：
那我想一次多 set 几个 cookie 怎么办？多给几个 Set-Cookie 头（一次 HTTP 请求中允许重复）
HTTP 请求的 Cookie 头用于浏览器把符合当前“空间、时间、使用方式”配置的所有 cookie 一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。
**“前端对 cookie 的读写”**前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。调用document.cookie可以创建、修改 cookie，和 HTTP 一样，一次document.cookie能且只能操作一个 cookie。
调用document.cookie也可以读到 cookie，也和 HTTP 一样，能读到所有的非HttpOnly cookie。
现在回想下，你刷卡的时候发生了什么？
这种操作，在前后端鉴权系统中，叫 session。典型的 session 登陆/验证流程：
**“Session 的存储方式”**显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：
“Session 的过期和销毁”**很简单，只要把存储的 session 数据销毁就可以。****“Session 的分布式问题”**通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？这个问题现在有几种解决方式。
但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决“用户请求的机器宕机”的问题。**“node.js 下的 session 处理”**前面的图很清楚了，服务端要实现对 cookie 和 session 的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如 express-session - npm，用法就不贴了。这是它种的 cookie：
express-session - npm 主要实现了：
session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法？
回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的“证件”有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做 token。
token 的流程是这样的：
**“客户端 token 的存储方式” 在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的“无状态性”，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。 “token 的过期”**那我们如何控制 token 的有效期呢？很简单，把“过期时间”和数据一起塞进去，验证时判断就好。
编码的方式丰俭由人。**“base64”**比如 node 端的 cookie-session - npm 库
默认配置下，当我给他一个 userid，他会存成这样：
这里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb”} 的 base64 而已。 “防篡改”
是的。所以看情况，如果 token 涉及到敏感权限，就要想办法避免 token 被篡改。解决方案就是给 token 加签名，来识别 token 是否被篡改过。例如在 cookie-session - npm 库中，增加两项配置：
这样会多种一个 .sig cookie，里面的值就是 {"userid":"abb”} 和 iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256 类 (System.Security.Cryptography) | Microsoft Docs。
好了，现在 cdd 虽然能伪造出eyJ1c2VyaWQiOiJhIn0=，但伪造不出 sig 的内容，因为他不知道 secret。**“JWT”**但上面的做法额外增加了 cookie 数量，数据本身也没有规范的格式，所以 JSON Web Token Introction - jwt.io 横空出世了。
它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：
这串东西是怎么生成的呢？看图：
类型、加密算法的选项，以及 JWT 标准数据字段，可以参考 RFC 7519 - JSON Web Token (JWT)node 上同样有相关的库实现：express-jwt - npm koa-jwt - npm
token，作为权限守护者，最重要的就是“安全”。业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。
有了 refresh token 后，几种情况的请求流程变成这样：
如果 refresh token 也过期了，就只能重新登录了。
session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。狭义上，我们通常认为 session 是“种在 cookie 上、数据存在服务端”的认证方案，token 是“客户端存哪都行、数据存在 token 里”的认证方案。对 session 和 token 的对比本质上是“客户端存 cookie / 存别地儿”、“服务端存数据 / 不存数据”的对比。**“客户端存 cookie / 存别地儿”**存 cookie 固然方便不操心，但问题也很明显：
存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。 “服务端存数据 / 不存数据”
前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要“一次登录，全线通用”的能力，叫做“单点登录”。
简单的，如果业务系统都在同一主域名下，比如wenku..com tieba..com，就好办了。可以直接把 cookie domain 设置为主域名 .com，网络也就是这么干的。
比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。这要能实现“一次登录，全线通用”，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。 “一次“从 A 系统引发登录，到 B 系统不用登录”的完整流程”
**“完整版本：考虑浏览器的场景”**上面的过程看起来没问题，实际上很多 APP 等端上这样就够了。但在浏览器下不见得好用。看这里：
对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：
图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。
谢谢大家哦
⑻ “浙里办“项目单点登录、埋点、二次回退的问题
大家可以看一看语雀 《“浙里办”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中，否则可能会存在埋点不成功的问题
⑼ 单点登录的几种实现方案
用户已经登录企业门户的前提下，单点登录到门户中的应用。门户与应用的域名有一定关系，门户的域名是父级域，比如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）。
⑽ CAS搭建单点登录Web端
①前端vue项目判断如果有token,则说明用户已登录，可以访问客户端A的服务。否则未登陆，未登陆有两种状态：在单点登录服务端已经登录和未在单点登录服务端登陆
判断如果有ticket，则说明已在单点登录服务端登录。调用/cas/client/validateLogin接口验证该ticket是否有效。转②
判断如果无ticket,则说明未在单点登录服务端登录。则定向到单点登录服务端。转③
②/cas/client/validateLogin接口方法，发起http请求到单点登录服务端进行ticket验证，如果验证通过，则登录成功。单点登录客户端A生成token返回给前端，之后前端通过携带token访问客户端A的服务。
③单点登录服务端返回登录表单，用户输入用户名密码确定登录后，单点登录服务端调用用户信息验证端/auth/user/login接口，传递用户名密码参数，将验证委托给用户信息验证端
④登录成功验证通过后，携带ticket返回浏览器，重定向地址如下:
http://localhost:8000/?ticket=ST-6-NqvtyjRhezstXiyyzNNN-C-DiTw-DESKTOP-CVVQ0QK
接入用户信息验证端参考