用户中心_单点登录
用户中心概念
一般来说，大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个应用，称为用户中心
用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕后返回凭证，第三方应用验证凭证，通过后就登录用户
主要功能如下
1、用户登录于注册
2、基本信息查询与修改
从功能上看，整个用户中心还是很简单的，不过其中的逻辑还是挺复杂的，比如注册功能，就要分为手机注册和邮箱注册，手机要发送手机验证码，邮箱则需要发送验证邮件，点击邮箱里面的链接跳转并进行后续注册流程，上面每步都需要业务上重新发送机制。
功能介绍
用户登录
在互联网用户中心体系中，一般会支持手机、邮箱、账号、三方登录。其中第三方登录一般是接入微信、qq、微博这三种方式
密码登录
1、用户在浏览器端填写username+password ，然后提交到服务端
2、服务端拿到用户提交的username+password验证
3、验证成功后，服务器返回请求，同时将cookie写到对应的域。
上述流程中，大家肯定会考考虑到密码的安全性，我们到底该怎么做才能防止密码被泄露呢？对称加密还是非对称加密？如果是对称加密，客户端被黑客反编译，就能拿到密钥，那么所用用户的密码就会存在非常大的泄露的风险？如果是非对称加密，私钥要放在那里才能保证安全？
通用简单的解决方案：https+MD5 +随机盐
https基本上谷歌、火狐都对不是https的网站进行安全提醒
如果公司很穷，买不起https证书咋办？只能在前端页面上做文章了。由于前端代码泄露在浏览器上，。我们只能采用不可逆的密码或者摘要算法，类似是与MD5/HASH算法。如果高级的话，就采用随机salt来提高攻击成本，针对不同用户，加入不同的salt，而不是固定盐的方式。使用这种方式的前提：目前对安全的要求不高
那我们该如何验证密码？ 客户端提交MD5（password）密码。服务端通过MD5（salt+MD5（password））的逻辑来计算最终密码，同时salt只会出现在服务端，且每个用户采用不同salt的方式来生成。这一系列过程中，都没有接触到原始的用户密码，而登录操作只是为了认证用户这个过程，无论用本地密码验证还是第三方登录，以上过程本质都是认证的形式。
所以用户的信息与登录的授权其实是独立开来的，即uid与登录方式是一对多的关系。比如：用户A使用微信登录，服务端认证身份后uid=abc。而下一次用户A使用微博登录，同样服务端认证出来的uid=abc
而本地密码验证可以当做一种授权方式，可以称为local_auth表
而通过微博登录就可以视作为另外一种登录方式，称为weibo_auth表
最后，如果还要增加一种登录方式的话，可以直接添加一直xx_auth表来存储用户认证信息，大大提高了我们授权的灵活性。
单点登录概念
单点登录，简称SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有互相信任的引用系统。
概述
很早期的公司，一家公司可能只有一个server，慢慢的server开始变多了。每个server都要进行注册登录，退出的时候又要一个个退出。用户体验很不好！你可以想象一下，上豆瓣要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记等。真的会让人崩溃的。我们想要另一种登录体验，一家企业的服务只要一次注册，登录的时候只要一次登录，退出的时候只要一次退出。怎么做？
一次登录于登出。回头看看发生了什么。
什么东西才是保持登录状态关键的东西？记录器（session）那个叫做cookie的纸张？写在纸张上的ID？是session里面记录的信息跟那个ID，cookie不只是记录ID的工具而已。客户端持有ID，服务端持有session，两者一起用来保持登录状态。客户端需要用ID来作为凭证，而服务端需要用session来验证ID的有效性（ID有可能过期、可能根本就是伪造的找不到对应的信、ID下对应的客户端还没有进行登录验证等）。但是session这个东西一开始是每个server自己独有的，豆瓣FM有自己的session、豆瓣读书有自己的session，而记录ID的cookie又不能跨域的。所以我们要实现一次登录一次退出，只需要想办法让各个server的共用一个session的信息，让客户端在各个域名下都能持有这个ID好了。再进一步讲，只要各个server拿到同一个ID，都能有办法检验出ID的有效性、并且能得到ID对应的用户信息就行了，也就是能检验ID。
server端
以server群如何生成、验证ID的方式大致分为两种：
”共享cookie“这个是上面提到的共享session的方式，我倒觉得叫“共享session”来得好一点，本质上cookie只是存储session-ID的介质，session-id也可以放在每一次请求的URL里。据说这种方式不安全，没去深研究。
SSO-token方式因为共享session的方式不安全，所以我们不再一session-id作为身份的标志。我们另外生成一种标识，把它取名为SSO-token，这种标识是整个server群唯一的，并且所有server群都能验证这个token，同时能拿到token背后代表的用户的信息。我们要讨论的也是这种方式。
浏览器端
单点登录还有非常关键的一步，这一步跟server端验证token的方式无关，用最早的“共享session”的方式还是现在的“token”方式，身份标识到了浏览器端都要面临这样的一个问题：用户登录成功拿到了token（或者session-id）后怎样让浏览器能读取cookie中的token。这就是共享cookie的方式（这才叫共享cookie嘛，上面那个应该叫共享session）
cookie：客户端的钥匙
session：服务端的锁
一个客户端的钥匙对应一个服务端的锁。
企业应用集成
通常情况下运维内审计系统、4A系统都包括此项功能，目的是简化账号登录过程并保护账号和密码安全，对账号进行统一管理
企业应用集成。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等鞥，事实上，还有一个层面上的集成变得越老越重要，那就是“身份认证”，也就是“单点登录”
技术实现机制
当用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统会进行身份校验，如果通过校验，应该返回给用户一个认证的凭据--ticket；用户再访问别的应用的时候，就会将这个ticker带上，作为自己认证的凭据，应用系统接受到请求之后会把ticker送到认证系统进行校验，检查ticker的合法性。如果通过校验，用户就可以不用再次登录的情况下访问应用系统2和应用3了。
实现OSS，需要以下主要的功能
所有应用系统共享一个身份认真系统。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返回给用户。另外，认证系统还应该对ticket进行有效性验证
所有应用系统能够识别和提取ticket信息
要实现OSS的功能，让用户只登陆一次，就必须让应用系统柜能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。
优点
1、提高用户的效率
用户不再被多次登录困扰，也不需要记住多个ID和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。
2、提高开发人员的效率
SSO为开发人员提供了一个通用的身份验证框架，如果SSO机制是独立的，那么开发人员就完全不需要为身份验证操作。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。
3、简化管理
如果应用程序加入了单点登录协议，管理用户账号的负担就会减轻。简化的程度取决于应用程序，因为OSS只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）
缺点
1、不利于重构
因为涉及到的系统很多，要重构必要兼容所有的系统，可能很耗时
2、无人看守桌面
因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。
同事针对业务进行解释
单点登录的原理：用户打开了用户中心的单点登录页面，登录完成后返回一个ticket（存放在cookie中）跳转到子平台的页面，然后子平台的页面把ticket传入到子平台的服务端，然后子平台的服务端去访问用户中心的服务，校验ticket是否合法，合法才算是登入成功。
