认证和授权(Authentication和Authorization)

什么是OAuth

如今很多网站的功能都强调彼此间的交互，因此我们需要一种简单，标准的解决方案来安全的完成应用的授权，于是，OAuth应运而生，看看官网对其的定义：

An open protocol to allow secure API authorization  in a simple and standard method from desktop and web applications.

一个典型的OAuth应用通常包括三种角色，分别是：

• Consumer：消费方
• Service Provider：服务提供者
• User：用户

用户好理解，不必多言，消费方和服务提供者则需要解释一下，举例来说：假设我们做了一个SNS，它有一个功能，可以让会员把他们在Google上的联系人导入到SNS上，那么此时的消费方就是SNS，而服务提供者则是Google。

注：Google APIs支持OAuth。

消费方如果想使用服务提供者的OAuth功能，通常需要先申请两样东西：

• Consumer Key
• Consumer Secret

当消费方生成签名的时候，会用到它们。

一个典型的OAuth流程通常如下图所示：

OAuth流程图

• A：消费方请求Request Token
• B：服务提供者授权Request Token
• C：消费方定向用户到服务提供者
• D：获得用户授权后，服务提供者定向用户到消费方
• E：消费方请求Access Token
• F：服务提供者授权Access Token
• G：消费方访问受保护的资源

基本就是用Request Token换取Access Token的过程。这里需要注意的是，对服务提供者而言，Request Token和Access Token的生命周期不一样，通常，Request Token的生命周期很短，一般在一个小时以内，这样相对安全一些；而Access Token的生命周期很长，往往是无限，如此一来，消费方就可以把它保存起来，以后的操作就无需用户再授权了，即便用户修改账号密码，也不会受影响，当然，用户可以废除消费方的授权。

有腿的OAuth

我们前面描述的OAuth，被称为三条腿的OAuth（3-Legged OAuth），这也是OAuth的标准版本。这里所谓的“三条腿”，指的是授权过程中涉及三步流程。不过有些情况下，不需要用户的参与，此时就产生了一个变体，被称作两条腿的OAuth（2-Legged OAuth），两条腿的OAuth和三条腿的OAuth相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，而主要是通过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret基本等价于账号和密码的作用。

 

OAuth和OpenID的区别

OAuth关注的是authorization；而OpenID侧重的是authentication。从表面上看，这两个英文单词很容易混淆，但实际上，它们的含义有本质的区别：

• authorization: n. 授权，认可；批准，委任
• authentication: n. 证明；鉴定；证实

OAuth关注的是授权，即：“用户能做什么”；而OpenID关注的是证明，即：“用户是谁”。

如果混淆了OAuth和OpenID的含义，后果很严重。以国内某网站开发的应用为例：它的功能是通过OAuth授权让新浪微博和豆瓣的用户使用各自的身份发表评论，如下图所示：

错误的把OAuth当做OpenID使用

此类应用属于身份证明问题，本应该通过OpenID来实现，但因为错误的使用了OAuth，从而带来安全隐患：设想一下用户只是在网站上发表了评论而已，但却赋予了网站随意操作自己私有数据的权利！

 

客户端的授权模式

客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。

• 授权码模式（authorization code）
• 简化模式（implicit）
• 密码模式（resource owner password credentials）
• 客户端模式（client credentials）

说明:

签名的意义在于防止请求被篡改。如果没有签名，只是简单的使用Consumer Key和Consumer Secret，那和HTTP Basic还有什么区别？！实际使用OAuth的时候，请求中是不包含Consumer Secret的，它只是参与签名的计算，所以，就算请求被别有用心的人截获也是没用的，因为他不知道Consumer Secret，所以算不出正确的签名，也就无法构造出合法的请求。

3-Legged OAuth就是通过User的授权，Consumer可以访问User在Service Provider的数据；至于2-Legged OAuth，没有User的参与，只是Consumer和Service Provider的交互。

摘自:http://huoding.com/page/2,本文只是为了方便温习.