单点登录和普通登录的区别，来自百度AI的解释

注意，以下回答均是百度AI伙伴回答，非博主的回答，仅供参考。

1，什么是单点登录

单点登录（Single Sign On，简称SSO）是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现不需要管理员对用户的登录状态或其他信息进行修改。

2，单点登录有哪些实现方式?

SSO的实现方式有以下几种：

使用Cookie作为凭证媒介。用户登录父应用之后，应用返回一个加密的Cookie，当用户访问子应用的时候，携带上这个Cookie，授权应用解密Cookie并进行校验，校验通过则登录当前用户。

通过JSONP实现。用户在父应用中登录后，跟Session匹配的Cookie会存到客户端中，当用户需要登录子应用的时候，授权应用访问父应用提供的JSONP接口，并在请求中带上父应用域名下的Cookie，父应用接收到请求，验证用户的登录状态，返回加密的信息，子应用通过解析返回来的加密信息来验证用户，如果通过验证则登录用户。

通过页面重定向的方式实现。

3，与ticket有什么关联？

单点登录中的ticket是用户登录后由认证系统返回的一个认证凭据。

当用户第一次访问应用系统时，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，认证系统返回给用户一个ticket；用户再访问别的应用的时候就会将这个ticket带上，应用系统接受到请求之后会把ticket送到认证系统进行效验，如果通过效验，用户就可以在不用再次登录的情况下访问应用系统。

4，单点登录和普通的系统登录有什么区别？

单点登录和普通的系统登录的区别如下：

登录方式不同。单点登录是用户在多个应用系统中，只需要登录一次就可以访问所有相互信任的应用系统；普通的系统登录是用户通过登录页面根据用户名查询用户信息，判断密码是否正确，正确则将用户信息写到session，访问的时候通过从session中获取用户信息，判断是否已登录，登录则允许访问。

适用场景不同。单点登录适用于多个应用系统独立部署和使用，需要通过单点登录实现仅在某系统中进行一次登录即可免登录进入其它应用系统；普通的系统登录适用于单个应用系统的登录。

存在的问题不同。单点登录由于session不能共享，服务越来越多，并且还服务还搭建集群，导致每访问另外一个服务都需要重新登录；普通的系统登录由于session不能共享，服务越来越多，并且还服务还搭建集群，导致每访问另外一个服务都需要重新登录。

5，单点登录和普通系统登录是不是都是通过token判断是否运行访问？

单点登录和普通的系统登录不是都是通过token判断是否允许访问。

单点登录和普通的系统登录的区别如下：

登录方式不同。单点登录是用户在多个应用系统中，只需要登录一次就可以访问所有相互信任的应用系统；普通的系统登录是用户通过登录页面根据用户名查询用户信息，判断密码是否正确，正确则将用户信息写到session，访问的时候通过从session中获取用户信息，判断是否已登录，登录则允许访问。

适用场景不同。单点登录适用于多个应用系统独立部署和使用，需要通过单点登录实现仅在某系统中进行一次登录即可免登录进入其它应用系统；普通的系统登录适用于单个应用系统的登录。

存在的问题不同。单点登录由于session不能共享，服务越来越多，并且还服务还搭建集群，导致每访问另外一个服务都需要重新登录；普通的系统登录由于session不能共享，服务越来越多，并且还服务还搭建集群，导致每访问另外一个服务都需要重新登录。

6，通过token访问的登录是单点登录，还是普通登录？

通过token访问的登录是单点登录。

单点登录是指在一个大型分布式系统中，用户只需要登录一次就可以访问其授权的所有应用系统，而无需再次进行登录操作。在单点登录系统中，token是用户进行一些权限操作时的许可凭证，是在前端进行登录之后，由服务器分发给前端，然后前端进行权限操作时，再将token发送给服务器，由服务器来验证。

7，普通登录是没有token的吗，那通过什么进行前后端验证的？

普通登录是没有token的，普通登录前后端验证是通过用户名和密码来进行的。

在登录时，用户输入的用户名和密码会被前端发送给后端，后端会进行验证。如果用户名和密码正确，则后端会返回一个登录成功的响应，否则会返回一个登录失败的响应。在用户访问其他应用系统时，需要再次进行用户名和密码的验证，才能进行访问。

8，那如何验证访问权限呢？

在普通登录中，用户登录成功后，服务器会返回一个sessionID，并将此sessionID存储在客户端（如浏览器）中。当用户访问应用系统时，客户端会将此sessionID发送给服务器，服务器通过查询session来验证用户是否有访问权限。

在单点登录中，用户登录后，服务器会返回一个token，并将此token存储在客户端（如浏览器）中。当用户访问应用系统时，客户端会将此token发送给服务器，服务器通过验证token来验证用户是否有访问权限。

9，那token和session的方式原理不一样吗？

token和session的方式原理不一样。

session是服务端存储的一个对象，主要用来存储所有访问过该服务端的客户端的用户信息，从而实现保持用户会话状态。但是服务器重启时，内存会被销毁，存储的用户信息也就消失了。不同的用户访问服务端的时候会在session对象中存储键值对，“键"用来存储开启这个用户信息的"钥匙”，在登录成功后，"钥匙"通过cookie返回给客户端，客户端存储为sessionId记录在cookie中。当客户端再次访问时，会默认携带cookie中的sessionId来实现会话机制。

token是完全由应用管理，所以它可以避开同源策略（同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源）。Token可以在cookie或者header中，不依赖cookie。

10，同一用户的session对象在不同登录状态下是不一样的吗？

同一用户的session对象在不同登录状态下是一样的。在用户登录后，服务器会创建一个session对象，并返回一个sessionID给客户端。客户端在后续的请求中，会将此sessionID发送给服务器，服务器会根据sessionID来获取对应的session对象。因此，同一用户的session对象在相同登录状态下是相同的，不会因为登录状态的改变而改变。

11，如果一样，是不是有安全风险？

如果同一用户的session对象在不同登录状态下是一样的，那么确实存在一定的安全风险。

首先，如果攻击者能够获取到某个用户的sessionID，他们就可以通过模拟该用户的session对象来伪装成该用户进行登录。由于sessionID是相同的，服务器会误认为攻击者是真正的用户，从而向其返回用户的会话信息。

其次，如果攻击者能够获取到某个用户的session对象，他们就可以通过分析该对象中的信息来获取用户的敏感信息，如用户名、密码等。

因此，为了确保安全性，建议在用户登录后生成唯一的sessionID，并使用HTTPS等安全协议来保护通信过程中的session对象和sessionID。同时，对session对象中的数据进行加密和混淆处理，以防止攻击者获取到敏感信息。

12，session是不是不能避开同源策略的问题？

是的，session不能避开同源策略的问题。同源策略是指，如果两个页面处于同一台服务器、同一个域名下，那么这两个页面就被认为是同源的，可以共享session。如果两个页面处于不同的域名或者服务器下，那么它们就被认为是非同源的，无法共享session。因此，session无法解决跨域问题，无法在非同源的情况下共享会话信息。