这边主要是在公司的项目中遇到的问题和一般简单的遇到的哪些问题和解决方式！

（ps：也不知道为什么，从刚踏上it的编程之路无论是大学的项目设计还是职业生涯的web，java，.net,都会设计到登录有关的问题，但是就仅仅这个功能的设计，有浅有深，上下限很大，让我心中一万只草泥马奔过）

一 普通登录

一个登录页面，输入账号密码，提交Form表单，后端查询数据库对应用户名的密码，匹配正确则把用户记录到Session，不正确则返回错误。这种登录，在上学的时候，也许敬爱的老师就已经教过你了。但可能他没有教你的是，密码需要hash加密，session为什么可以记录登录用户的原理。

密码hash： 就是存进数据库中的是一串密文，不是明文，加密的过程是不可逆转的！

在这之前还是需要理解一个概念：那就是session。

那什么是session呢？它的原理是什么样的？它的原理大概是酱紫的：服务器端维护一个session的表，这个表的每一条记录存的就是与某一个客户端的会话，会话会有过期时间，过期的会话会被清理。然后这个会话，会有一个对应的id，一般是一串长长的看不懂的字符串，然后这个字符串会被存储在客户端的cookie中，每一次请求服务器端都会带上这个cookie，服务器端就知道访问的就是哪个客户端了。

二 独立系统的登录

这个一般是后台的登录方式： 一个域名是www.site.com，一个则是passport.site.com了。要在不同的域名下进行登录，一般的方法是www.site.com/login跳转到passport.site.com/login，passport这边是一个登录页面，用户输入账号密码登录成功之后，passport会通过带着一个可逆加密的包含用户信息的token，重定向到www.site.com提供的回调处理地址，然后进行解密，匹配正确，则登录用户。要注意的是，这里的加密的信息需要包含一个时间戳，接收方需要认证这个时间戳，过期登录失败。避免token被窃取，被无限登录site系统。

三  单点登录

单点登录需要实现的需求，说白了就是在站点A的登录了，那么用户就自动在站点B、站点C、站点E、F、G登录。

这又分两种情况，A站点和B站点是否在同一个二级域名下。

假如是在同一个域名下，例如siteA.site.com与siteB.site.com，因为cookie允许设置到二级域名下.site.com，所以siteA和siteB是可以共享cookie的，用户的信息可以通过可逆加密放在二级域名下的cookie，并且设置http only，就可以一站登录，站站登录。

而如果A站点和B站点不在同一二级域名下，例如www.siteA.com与www.siteB.com，他们就无法通过共享cookie的方式共享用户信息，所以需要用到jsonp的方式，用户在siteA登录之后，提供一个jsonp接口获取加密的用户信息，siteB访问这个jsonp获取加密信息。达到共享用户状态的效果。

其实还有一种方式：重定向的方式

四 OAuth2.0登录

第三方登录都是实现了OAuth2.0协议的，流程大概是酱紫的：

第三方提供一个登录入口，也就是第三方域名下的登录页面。主站需要登录的时候，引导用户重定向到第三方的登录页面，用户输入账号密码之后，登录第三方系统，第三方系统匹配帐号成功之后，带上一个code到主站的回调地址，主站接收到code，短时间内拿着code请求第三方提供获取长期凭证的接口(因为code有一个比较短的过期时间)，这个长期凭证叫access_token，获取之后就把这个access_token存到数据库中，请求一些第三方提供的API，需要用到这个access_token，因为这个token就是记录用户在第三方系统的一个身份凭证。一些系统，在获取access_token的时候，还会返回一个副参数refresh_token，因为access_token是有过期时间的，一旦过期了，主站可以使用refresh_token请求第三方提供的接口获取新的access_token以及新的refresh_token。

这里讲一下授权的思路：

1  客户端向资源所有者发送授权请求，客户端的身份信息，请求资源路径，对数据的操作方法

2 资源所有者批准授权，发送给客户端，不批准就拒绝授权信息

3 客户端向授权服务器发送授权认证

4 确认认证后，发送accesstoken

5 客户端在accesstoken有效期间向资源所有者请求有效资源

6 确定accesstoken 有效性和真实性后，提供相应的操作

以下是我自己在xmind中画的大致理解：

未完待续！！！！！！！！！！！！！！！！！！！！！