访问oauth路径要不要认证

① 新浪OAuth和Basic Auth两种方式的区别

开放平台有两种认证方式，一种是Basic Auth，一种是OAuth。
1、Basic Auth（HTTP Auth）
Basic Auth简单点说明就是每次请求API时都提供用户的username和password。
。这种方式优点和缺点都很明显。
优点：
u 使用非常简单，
u 开发和调试工作简单，
u 没有复杂的页面跳转逻辑和交互过程；
u 更利于发起方控制；
缺点：
u 安全性低，每次都需要传递用户名和密码，用户名和密码很大程度上存在被监听盗取的可能；
u 同时应用本地还需要保存用户名和密码，在应用本身的安全性来说，也存在很大问题；
u 开放平台服务商出于自身安全性的考虑（第三方可以得到该服务商用户的账号密码，对于服务商来说是一种安全隐患），未来也会限制此认证方式（Twitter就计划在6月份停止Basic Auth的支持）
u 用户如果更改了用户名和密码，还需要重新进行密码校验的过程。
2、OAuth
OAuth为用户资源的授权提供了一个安全、开放的标准，将会是以后开发平台普遍遵守的，目前Twitter、Sina微博、豆瓣、Google等都提供对它的支持。它分为几个交互过程：
1）应用用APP KEY和APP SECRET换取OAuth_token；
2）应用将用户引导到服务商的页面对该OAuth_token进行授权（可能需要输入用户名和密码）；
3）服务商的页面跳转回应用，应用再根据参数去服务商获得Access Token；
4）使用这个Access Token就可以访问API了。
上述过程如下图所示：
OAuth认证过程
OAuth的优点：
u 安全性高，用户的账户和密码只需要提供一次，而且是在服务商的页面上提供，防止了Basic Auth反复传输密码带来的安全隐患；
u Access Token访问权限仅限于应用，被窃取不会影响用户在该服务商的其他服务；
u Access Token即使被监听丢失了随时可以撤销，不像密码丢失可能就被别人篡改了；
u 用户修改了密码也不会影响该应用的正常使用。
OAuth和Basic Auth两种方式的区别, OAuth是一种比较通用的，安全的认证方式，不需要用户名密码，只需要用户授权；basic auth是一种基于用户名密码的认证，每次访问都需带上用户的用户名密码。

② OAUTH，OPENID，SAML，CAS做统一认证与授权时有什么区别

OpenID是Authentication
OAuth是Authorization

前者是网站对用户进行认证，让网站知道逗你是你所声称的URL的属主地
后者其实并不包括认证，只不过逗只有认证成功的人才能进行授权地，结果类似于逗认证+授权地了。OAuth相当于：A网站给B网站一个令牌，然后告诉B网站说根据这个令牌你可以获取到某用户在A网站上允许你访问的所有信息

如果A网站需要用B网站的用户系统进行登录（学名好像叫federated login），它可以

选择OpenID认证，然后通过attribute exchange获取用户的昵称或其他通过OpenID暴露出来的用户属性，或者
选择OAuth认证，获取到token后再用token获取用户昵称或其他允许被访问的信息

③ REST API 只给自己的APP提供接口，需要oauth认证吗

1 就算有oauth也不能限定app吧.
oauth的本质上是提供第三方认证服务的.所以如果本来不需要登录的应用,应该就不需要使用oauth.

2如何防止其他app调用, 这里面应该是用一对app id 和secret加密成一个令牌来做验证.从而可以限制api的调用.只要保护好secret,api就应该只能在你自己的应用内访问了.

④ OAuth2.0原理和验证流程分析

第三方授权就是，委托第三方来对既定的用户进行鉴定，鉴定成功之后，下发信任凭证，信任凭证和用户挂钩，同时可以使用此凭证来去第三方平台，获得该用户开放的部分信息.
直白的说，就是将用户授权的工作交给第三方来做，而自己只维护信任凭证，并且获取用户信息。就像我们的QQ和微博一样，你在逛各大论坛的时候，总会有一种途径就是第三方的App登陆。显然这种验证是要在第三方做的，而论坛只需要维护一个token，并且可以获取你的个人信息，然而没什么软用。你如果想用部分功能，还是得注册，因为你相当于论坛只是一个有部分信息的游客，而没有成为它的用户，这种手段可以看成是提高自己访问量或转化率的一种手段吧。其实这种授权方案不一样只用在互联网，部分企业级的网站做资源的共享访问也是这么做的。比如两个网站合作，A站点账户可以登陆B站点，B站点账户可以登陆A站点，这样A站点就能拿到B站点相关资源，反过来也是。就做到了资源共享。
那么这种授权是怎么做的呢？到底安全不安全？那么可能就要引出OAuth协议了。

首先OAuth只是一个授权协议，不是一个实现或是一个中间件。
OAuth1于2007年10月建立，之后又在2009年6月重新修订和发布 http://oauth.net/core/1.0a/
OAuth1.0授权流程是什么？

流程很复杂，因为OAuth需要保证授权码和Token在传输的时候不被截取和篡改，所以使用了很多签名反复的验证。
OAuth1.0的问题：
反复的签名，开放平台本来就面对开发者，但是反复的签名导致开发的流程太过于复杂。
没有引入回跳地址的判断，导致会跳可能会篡改，这样授权码和Token会被Hack掉（1.0a的时候修复了这个漏洞）。
授权流程过于单一化。

OAuth2.0的引入：
抽象验证流程
由于OAuth1过于复杂，之后对OAuth进行了改造引入了Oauth2.0。OAuth的授权过程如下：

(A) 客户端从资源拥有者那里请求授权。授权请求能够直接发送给资源拥有者，或者间接地通过授权服务器这样的中介，而后者更为可取。

(B) 客户端收到一个访问许可，它代表由资源服务器提供的授权。

(C) 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。

(D) 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。

(E) 客户端通过出示访问令牌向资源服务器请求受保护资源。

(F) 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。

上面只是一个抽象的验证流程，根据上面的抽象流程演化出四种验证模式：
授权码模式
授权码模式和上述的 抽象验证模式流程比较相似：

(A) web客户端通过将终端用户的user-agent重定向到授权服务器来发起这个流程。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（借助于user-agent），并确定终端用户是否许可客户端的访问请求。

(C) 假定终端用户许可了这次访问，授权服务器会将user-agent重定向到之前提供的重定向URI上去。授权服务器为客户端传回一个授权码做获取访问令牌之用。

(D) 客户端通过验证并传入上一步取得的授权码从授权服务器请求一个访问令牌。（需要带上ClientId和Secret，ClientId和Secret是通过平台授予）

(E) 授权服务器验证客户端私有证书和授权码的有效性并返回访问令牌。

授权码模式（implicit grant type）
User-Agent子态适用于客户端不能保存客户端私有证书的App（纯客户端App，无Server参与）。因为可纯客户端的程序不能保存密钥

(A) 客户端将user-agent引导到终端用户授权endpoint。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（通过user-agent）并确认终端用户是许可还是拒绝了客户端的访问请求。

(C) 如果终端用户许可了这次访问，那么授权服务器会将user-agent引导到之前提供的重定向URI。重定向URI会在URI片断{译者注：URI片断是指URI中#号之后的内容}中包含访问令牌。

(D) user-agent响应重定向指令，向web服务器发送不包含URI片断的请求。user-agent在本地保存URI片断。

(E) web服务器返回一个web页面（通常是嵌入了脚本的HTML网页），这个页面能够访问完整的重定向URI，它包含了由user-agent保存的URI片断，同时这个页面能够将包含在URI片断中的访问令牌（和其它参数）提取出来。

(F) user-agent在本地执行由web服务器提供的脚本，该脚本提取出访问令牌并将它传递给客户端。

密码模式
密码模式就是将密码托管给第三方App，但是必须要保证第三方App高度可信。

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

客户端模式
这种模式不需要终端用户的参与，只是Client和Server端的交互。通常只用于Client状态的获取。

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

（B）认证服务器确认无误后，向客户端提供访问令牌。

授权流程
这里以授权码方式流程说明，主要流程分为两步，获取授权码和通过授权码获取资源票据：

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

A步骤中，客户端申请认证的URI，包含以下参数：

response_type：表示授权类型，必选项，此处的值固定为"code"
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

C步骤中，服务器回应客户端的URI，包含以下参数：
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：
grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
code：表示上一步获得的授权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示客户端ID，必选项。

E步骤中，认证服务器发送的HTTP回复，包含以下参数：
access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

资源访问过程：
http://localhost:8082/oauth/server/resource/uname.do?access_token=
此处主要由资源服务方实现，对于access_token进行校验。

token过期刷新过程：
客户端使用“refresh_token”访问许可类型和下列参数传入刷新令牌：
refresh_token：
必需参数。与待刷新的访问令牌相关联的刷新令牌。
grant_type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&refresh_token=n4E9O119d
授权服务器必须验证客户端私有证书（如果存在），验证刷新令牌是否有效，以及验证资源拥有者的授权是否仍然有效。如果请求有效，授权服务器则发布一个访问令牌响应，原来的Token失效。以后访问必须使用新Token。

OAuth2看上去很美好，但是细心观察其实还是有一些漏洞的。

参考资料：
http://blog.csdn.net/seccloud/article/details/8192707
http://www.justwinit.cn/post/8138/
https://blog.yorkxin.org/2013/09/30/oauth2-1-introction
人人网OAuth历程: http://www.infoq.com/cn/presentations/dx-renren-authentication-authorization/

⑤ oauth2下第一方为什么需要用户授权

用户使用oauth2授权登录绑定手机号后，下次登录时可以直接用oauth2登录，这样用户操作更方便一些。
oauth的设计是用户不向第三方暴露自己的登陆信息的情况下，授权第三方以自己的身份访问一些资源。
oauth2的设计初衷是源于oauth1计算签名的复杂度，希望进一步降低第三方开发者的开发门槛。