网络安全水很深，零碎的也看了不少资料，但是总觉得很飘渺，可能是平时主要是做应用开发，而真正实践密码设计（cryptography）和安全设计（security）的机会比较少.
刚刚看了几篇文章 listed as following，有一些A-Ha moment，也能把我现有的关于web安全的知识窜起来，故记录在此：
http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s02.html
http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s03.html
http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s04.html
一，怎样保证通信安全？
这是个古老的问题，而且古人的经验告诉我们，暗号能够确保通信安全，与似乎，什么“天王盖地虎、宝塔镇河妖”开始登上了历史舞台，其实暗号也就是加密，是对原始信息的隐藏，到近代，加密发展成了一门科学，
也演绎了很多关于加密/解密 攻防大战的经典故事。
所以通过加密来保证通信安全是经过历史考验的可行方法。
二、加密学在网络的延伸
传统的加密大多都是对称加密（symmetric），也就是上锁和开锁都用同一把钥匙，但是internet是个天生就不安全的环境，一窜“my credit card num is 110945110945”从上海跑到北京，不知要经历多少个路由器，交换机，在通信期间，如果有坏人(man
in the middle)要窃取你的数据，更是如囊中取物。那就加密吧，不过如果采用对称加密，而且这把钥匙每个人都有的话，那就跟没有加密是一样的。
解决方法是不对称加密（Asymmetric Encryption)，详细请参考上面的reference.
三、怎样保证数据的完整性？
OK, 采用不对称加密后，我们的通信数据不再担心被middle man窃听了，但是新的问题来了（人类总是有追求卓越和完美的本能），我怎么知道这个信息没有被篡改过并且是真实有效的呢？
判断有没有被篡改过，我们有数字签名(Digital Signature)， 很简单，sender用一套单向的哈希算法，生成源数据的摘要，此算法保证对源数据的任何更改都会产生不同的摘要，sender将源数据和摘要一起发给receiver，receiver收到数据后，用同样的算法再生成一次摘要，并将其与sender发过来的进行比对，如果一样，那么就可以断言信息没有被更改过。
四、怎样确保通信方身份真实有效？
数字签名解决了数据完整性问题，那么怎样保证和你通信的人是真实有效的呢，这个身份认证的事情，必须通过第三方来做，因为自己不能为自己做证啊，你说你就是“招商银行”，我凭什么要相信你呢，任何人都可以说自己是招行。如果银监会说，他确实是招商银行，你可以放心把银行密码告诉他，你才敢放心，是不是。这一套解决信任问题的方案就是数字证书(Digital
Certificate)，这个第三方，我们管它叫CA（Certificate Authority), Authority应该是很有权威的，虽然不是银监会，但也是绝对可靠可信的，比较知名的有VeriSign，被Symantec收购了，我们公司就在用这个。
五、认证（Authentication），授权（Authorization），访问（Access）
输入用户名，密码，登陆系统，哦，还有验证码
，早期的internet，包括现在的大部分应用，都是这种模式。但随着internet
发展，越来越多的service provider，要开放自己的service给第三方应用访问，特别是social network的兴起，这种需求变得越来越强烈，几乎变成大型网站的标配。
怎样让第三方应用访问用户资源，同时又不接触到用户的敏感信息呢？
如果传统的用户名，密码登陆验证，就以为着第三方必须知道user的用户名，密码，显然不满足我们的需求，怎么办呢？ 一帮聪明的人仔细研究了整个验证过程，然后将其分解、抽象成三个步骤，即认证（Authentication），授权（Authorization），访问（Access）。这让我不禁想起那句老话
“在计算机世界，任何问题都可以通过加一层来解决”，是的，加了Access Layer之后，前面的要求就能满足了，具体是怎样实现的，参看下文。
分解后，将访问资源同认证、授权解耦。也就是说认证、授权在一个地方先做，完成后获得一个Access
Token， 然后利用这个Access Token去访问resource， 当然resource server要负责验证这个token的有效性，怎么验证呢？ 方法有多种，利用token作为reference id去Authorization server获取相关信息是常见的方式。
通过此方式，第三方只要引导user去完成Authentication
和 Authorization， 而不用touch到user credential information (username, password)， 利用上面步骤获得的Access Token 再去访问Resource server。 也就是OAuth的工作流程了。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
参考：http://tools.ietf.org/html/rfc6749