内部邀请码:C8E245J (不写邀请码,没有现金送)
国内私募机构九鼎控股打造,九鼎投资是在全国股份转让系统挂牌的公众公司,股票代码为430719,为“中国PE第一股”,市值超1000亿元。
原文地址:https://zhongxiao37s-wiki.readthedocs.org/en/latest/network/OAuthSSO.html#id4
Introduction
周五的技术沙龙,Rain和Joey讲了关于Cookie + Session + OAuth + SSO的一些知识。觉得很是有用,所以又从网上翻资料出来,做个记录。
HTTP协议
HTTP虽然是基于TCP/IP,但是HTTP本身却是无状态协议。每次HTTP简单的请求和响应是独立事件,事件之间没有状态的联系。而TCP/IP在实现的时候,需要两端维持一个协议状态机,并根据网络事件进行状态的跃迁。
Session
session是一种保存上下文信息的机制,它是针对每一个用户的,变量的值保存在服务器端,通过SessionID来区分不同的客户,session是以Cookie或URL重写为基础。默认使用Cookie来实现,系统会创造一个名为JSESSIONID的输出Cookie,或称为”Session Cookie”.
Session的工作原理
就session的实现而言,好像是这样的
- 当有Session启动时,服务器生成一个唯一值,称为SessionID(好像是通过取进程ID的方式取得的)。
- 然后,服务器开辟一块内存,对应于该SessionID。
- 服务器再将该SessionID写入浏览器的cookie(一些在网页的源代码中有所体现)。
- 服务器内有一进程,监视所有Session的活动状况,如果有Session超时或是主动关闭,服务器就释放该内存块。
- 当浏览器连入IIS(服务器)时并请求的ASP(脚本语言)内用到Session时,IIS(服务器)就读浏览器Cookie中的SessionID。
- 然后,服务检查该SessionID所对应的内存是否有效。
- 如果有效,就读出内存中的值。
- 如果无效,就建立新的Session。
OpenID
OpenID实际上不属于SSO, 只是一种身份的认证而已。解决的问题是你是谁。
OpenID挺NB的,拥有众多大腕粉丝, 例如GOOGLE、YAHOO、Facebook,希望别人的系统使用它们的帐号登陆。他们希望一种足够简单的WEB SSO规范,于是选择一种草根网络协议OpenID。OpenID,名字取得好,顾名思义,一看就知道它是干嘛的。国内也有它的Fans,例如豆瓣网。OpenID的确足够简单,但是协议本身是不完善,可能需要一些补充协议才能够满足业务需求。例如GOOGLE采用OpenID + OAuth。目前支持OpenID有Yahoo、Google、Windows Live,还有号称要支持OpenID的Facebook。目前Yahoo和Google宣称对OpenID的支持,但是其实是有限制的,Yahoo的OpenID只有少数合作伙伴才能获得其属性,Google也只有在其Google Apps中才能获得账号的Attribute。用户账号毕竟是一个互联网公司的最宝贵资源,希望他们完全分享账号是不可能的。OpenID作为一个所谓的“开源项目”,仿佛是人人都在为他服务,但是又好象人人都不给他服务。没有一个机构能够真正的去帮助别人熟悉和使用他。
OAuth
OAuth跟OpenID差不多实际不属于SSO范围.是用户身份权限制认证。解决的问题是授权。比如,以前在twitter的应用需要输入用户名和密码,自从用上OAuth以后,就需要一个授权的过程。
OAuth是由Blaine Cook、Chris Messina、Larry Halff 及David Recordon共同发起的,目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布。
具体每步执行结果如下:
- 使用者(第三方站点)向`OAuth`_服务提供商请求未授权的Request Token。向Request Token URI发起请求,请求需要带上的参数见上图;
- OAuth服务提供商同意使用者的请求,并向其颁发未经用户授权的OAuth_token与对应的OAuth_token_secret,并返回给使用者;
- 使用者向OAuth服务提供商请求用户授权的Request Token,即向User Authorization URI发起请求,请求附带上一步拿到的未授权的token(令牌)与其secret(密钥);
- OAuth服务提供商将引导用户进行授权认证。该过程可能会提示用户,你想将哪些受保护的资源授权给该应用,此步可能会返回授权的Request Token也可能不返回,如Yahoo OAuth就不会返回任何信息给使用者;
- Request Token 授权后,使用者将向Access Token URI发起请求,把上步授权的Request Token换成Access Token;
- OAuth服务提供商同意使用者的请求,并向其颁发Access Token与对应的密钥,最后返回给使用者。
- 使用者以后就可以使用最后获取到的Access Token来访问用户授权的资源。
从上述的步骤中可以看出,用户始终没有将其用户名与密码等信息提供给使用者(第三方站点),从而更安全。
SSO
单点登录(Single Sign On , 简称 SSO )
- SessionID的局限性在于sevice,由于需要在service的上面,但是当service有多个instance并且instance之间不能够共享sessionID的时候,就会导致问题。比如,当某个instance挂掉以后,在该instance上面的用户会话将不能够保存并继续。
- Cookie可以解决以上跨service instance的问题。Cookie是基于DNS domain在进行加密的,能够解决的是在该域名下面所有服务器的会话问题。可以通过memcached来解决Cookie校验的问题。Cookie的局限性: 在于不同domain之间的共享。
- SSO 即为了解决跨Domain之间的用户校验的问题。
SSO流程图
Reference
- http://blog.csdn.net/hongxing4hao/archive/2007/01/24/1492627.aspx
- http://blog.csdn.net/yanbei0391/archive/2010/12/29/6105967.aspx
- http://baike.baidu.com/view/25258.htm
- http://blog.chinaunix.net/space.php?uid=1760882&do=blog&id=93117
- http://www.douban.com/service/apidoc/auth
- http://huoding.com/2010/10/10/8
- http://wiki.dianboom.com/index.php/OAuth%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6
- http://wiki.dianboom.com/images/0/0b/OAuth_diagram.png
- http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html