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