单点登陆应该归为架构的部分了,但是通常站点在開始的时候最好有单点登陆的思想。防止后期再作大量的改动。api
而且单点登陆对于开发者来讲并无添加太多额外的工做量,因此提早讲一下对你们都是好的。架构
先说一下单点登陆的机制(摘自百度百科,给我广告费):google
当用户第一次訪问应用系统1的时候。因为尚未登陆。会被引导到认证系统中进行登陆。依据用户提供的登陆信息,认证系统进行身份校验,假设经过校验,应该返回给用户一个认证的凭据--ticket;用户再訪问别的应用的时候,就会将这个ticket带上。做为本身认证的凭据,应用系统接受到请求以后会把ticket送到认证系统进行校验。检查ticket的合法性。spa
假设经过校验,用户就可以在不用再次登陆的状况下訪问应用系统2和应用系统3了。ci
另外单点登陆的优势是不需要每开发一个系统都需要作一套用户管理的功能了。你仅仅需要开发一套用户管理系统,提供sso的sdk,甚至可以再扩展一下提供oauth2的api,这样就可以实现内部的单点登陆及外部的用户认证。开发
详细实现机制我就再也不巴拉巴拉的拷贝粘贴了,请自行google sso单点登陆。oauth2。class
我再说一下咱们血的教训,最先作站点时根本没有使用单点登陆,因为就一个系统,而且也没有想过这个问题。后来系统就渐渐多了起来,每个里面都有一套用户注冊、登陆、管理。登录
但是这几个系统终因而服务同一批用户的,问题就来了。用户不想每个系统都注冊、登陆一次啊,而且每个系统的用户都没有关系。领导对此大发雷霆,仅仅得每个系统进行改造,数据合并最头大,有些用户注冊的username还不同。仅仅得多个帐号都保留。固然改造完以后,神清气爽,为后来和新浪教育及其它教育公司对接提供了有力的支持。百度